The IT Complexity Crisis

These are some notes and comments on Roger Sessions’ white paper on complexity.

Whilst I agree with the gist of the paper I have several doubts about details. I will, however, not go into most of those here since they are discussed elsewhere. Those who remain unanswered are listed below and I’d be very interested to hear other people’s thoughts about these.

1. The paper talks a lot about reducing complexity in architecture but the only perspective discussed is business level functionality. I know that Roger has commented elsewhere that this composition of systems/subsystems and services also be used in implementation but that still leaves out many aspects which contain complexity.

As architects we need to look at a system from many different perspectives and produce a solution that solves, or at least addresses, all of our stakeholders’ concerns. In my experience, complexity builds up during this process. I’m not convinced that the simplest possible composition of business capabilities gives the simplest possible overall architecture.

2. The paper fails to talk about how complexity builds up in IT systems over time. I guess activities during maintenance/operations is slightly out of scope since the paper mostly talks about projects. But I wish they weren’t.

They represent one way of how complexity comes into being, and one that can’t be ignored. If everyone wants to work on new projects and all of your best, most skilled and talented resources are busy writing new code it’s no wonder a system usually ends up being a big ball of mud after a couple of years. Regardless of what it looked like to begin with.

To me, the paper gives the illusion that reducing complexity is, more or less, a one time effort and not a continuous battle that spans a system’s whole lifecycle. I’m hoping that this is not what Roger means but it would be nice to have this point clarified as much as possible.