One of the major reasons why so many IT projects fail is complicated architecture. I would even argue, in contrary to so many IT news articles, is that complicated architecture is a bigger problem than bad project management in those failures.

Let me get this very precise: It’s not complexity that we should worry about. Look around you! So many things are very complex. You probably don’t even understand how your fridge, watch or TV works. Still, these are very simple things in usage and they all work and are very predictable. So much in our world is complex and still predictable.

Jurgen Appelo described extensively difference between complex and complicated in his book Management 3.0. As ironic as it seems, I’m giving here oversimplified version of his thorough explanation and seen from perspective of IT system architecture.

In Agile architecting, we constantly strive to create simple systems. At the same time we usually should not simplify complex stuff. Let me explain this with one example. During one of my visits at a large dutch company, group of enterprise architects told me very proud they created “generic business process” which will enable them to deal with any business process in the company. One that rules them all! Standardization gone crazy! This is a typical case of oversimplifying things which are complex by nature. The reason this company has so many different business processes is because they have big diversity of products and services, which are eventually relatively simple for their customers. The worst of all is that they were planning to cram all these processes into generic one, which is rather impossible unless you want to sacrifice the business value from having clearly wanted diversity.

Complexity is everywhere and it is the reason why this life is so interesting. Complex systems bring value. A human being is a very, very complex system with even more complex behavior; although basic components of human body are just cells. Human being itself is capable of delivering even more complex systems. It’s amazing that something as simple as a cell can grow into indefinite complexity.

But, human beings are really bad in dealing with complicated stuff. We can’t even comprehend, without partitioning in our head, a drawing containing more than seven blocks and lines. We also use familiar patterns to understand anything. If we create software structure with no or too many patterns, then it will definitely fail.

This is the main reason why is so important we create simple structures capable of delivering complex behavior. One simplicity litmus test: Is every developer in your team capable of explaining the overall system architecture without using any reference?

Many architects and IT managers are trying to buy simplicity from some vendor. They actually never request this literally, but the main reason why companies buy out-of-box solutions so fast is because the business challenge and question is complex and they don’t feel capable of dealing with it. The challenge is oversimplified or “patternized” too fast by labeling the problem and buying the product with promise of solving it. In other words, they confuse complexity with complicated. The real complexity is not understood because you must have specific business domain knowledge, which vendors lack. Instead, IT landscape gets only complicated with each new expensive IT gadget. The symptoms are statements from business: “Why does it take us to deliver this product in 5 years and not 5 months like competition does?” or “Our problem is still not solved!”

The best architectures are the ones, which deal with huge number of users and structure can be explained to you grandmother. I’ve never said architecting is easy. 🙂

In the following posts, I’ll give many examples how simple enterprise landscapes should look like and practices to achieve this.