Once upon a time there was a man who wanted to have a new house. Since he wanted the best of the best he scoured the land for the best masons, carpenters, plumbers and roofers. Soon he had gathered a team of construction workers who were all considered to be the best in their field. The next thing he did, was buying his team the best tooling money could buy, and he sent his team to familiarize them with the newest techniques and technologies. Soon, they set to work and lo and behold, their technology and techniques allowed them to work so efficiently, that the new house could be delivered weeks ahead of planning. Full of pride the workers showed the home owner his new house. “Look”, said the mason, “see how every horizontal joint is exactly 11.4 millimeters wide, and every vertical joint exactly 9.8 millimeters”. “And see”, the carpenter added, “the door-frames are perfectly flush, and fit seamlessly into the brickwork”. Each of the workmen explained details about the perfection of their specific workmanship. Finally, the home owner couldn’t stand it any longer. “What have you done?” he cried. “The bathroom can only be accessed from the kitchen! The balcony is on the north side and will never receive any sunshine! The windows look out over the parking lot of the supermarket and the view over the valley is obstructed by a blind wall! I have to cross the room before I can switch on the lights! To get to my car I have to walk all around the house and the garage! You are all sacked!” The workers looked at each other uncomprehendingly. How could the home owner be so ungrateful and say this to them. They had delivered the finest work ever produced! But they shrugged and set off to build an even better house for another customer. And the home owner? He went out to look for even more accomplished workers, even better tooling, and even newer techniques and technologies to try and fix his new home.

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.

Dividing a system into components and subcomponents introduces another phenomenon: dependencies and interdependencies. When not very carefully managed, the increase in (inter)dependencies have the potential to explode the complexity exponentially, resulting in uncontrollable, unpredictable complex systems. This is another key feature in complexity science. The synthetical approach is all about understanding complexity and managing (inter)dependencies, not just in technology aspects, but especially in dynamic processes and data lifecycle aspects.

 

In a world where the speed of change is increasing astronomically (for instance, compare ICT changes that took place between 1968 and 1978 to those that have taken place between 2008 and now!), systems are no longer simple and predictable. In today’s volatility and dynamics, the synthetical approach has become just as important as the analytical approach, and you will need both to address the complexities and uncertainties of today’s IT solutions. The devil lurks in the details, but quality hides in the whole.