We tend to forget that in corporate software the same principles apply. Programmers must realize that they do not produce programs, software designers must understand that they do not produce designs, analysts must understand that the goal of their job is not to analyze; they must know that they perform all these tasks in order to add a fitting contribution to an integrated application network. The individual contributions do not support the business processes, but an integrated application network built upon effective collaboration between applications does. This makes communication, harmonization, coordination and administration in these applications the most important aspects of software development. The quality of the individual applications, and the technology and techniques that have been used, are of no importance if the application network as a whole is not satisfactory.

If we are to create a piece to fit into a puzzle, we need to define how the piece is going to fit into the puzzle before we can start creating the piece. Astonishingly, we all too often forget this principle in corporate IT. We build or buy solutions first, then ask the integration people to fit that piece into the puzzle of existing solutions. It is obvious that this is not way to achieve a quality application network. As the famous Finnish architect Eliel Saarinen taught us over a century ago, the secret to a successful design is: “Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.“ Complexity science was unknown in Saarinen’s time, but the fractalic nature of his remark is one of the keys of complexity.

Our whole education and training has been aimed at an analytical approach: from a high level, dive into details by dividing a complicated problem into less complicated components, divide those into even simpler subcomponents, and so on until your sub-issues become trivial to solve. We have invented nice words for this approach, like ‘componentization’, ‘implementation-hiding’ and ‘black-box architecture’. We hide the difficult stuff behind simple facades. It is an approach that over time has worked very well for mechanistic, predictable systems, and it still does, but it’s no longer enough. What is missing is how we are going to make the subcomponents work together as a whole: the synthetical approach.