[This English version, see Spanish version here / Versión en inglés, véase versión en español aquí] 


At the end of my last blog post I stated that UML was still useful, so long as it’s used to “simplify, communicate, not complicate”. The last word in that trio got me thinking again about what is arguably the architect’s biggest enemy: complexity. However, are we aware of this enemy? As usual with architecture related subjects, there are plenty of opinions around, usually more than people who hold those opinions: here are a few I’ve found useful, plus my own…

The first explicit reference to complexity I’m aware of is Frederick Brooks’ article in the October 1987 issue of IEEE Computer, titled "Conceptual Essence of Software Engineering or There Is No Silver Bullet". Brooks talks of accidental complexity and essential complexity. Accidental complexity is due to the way we go about solving the problem, while essential complexity is inherent to the problem itself. The Brooks’ article is mentioned in Booch et al., Object Oriented Analysis and Design with Applications 3rd Edition Booch et al. naturally prescribe Object Orientation as a way of “Bringing Order to Chaos”; in my opinion it’s one way, but not the only one.

In Software Architect Bootcamp, Second Edition,  Raphael Malveau and Thomas J. Mowbray opine that many of those involved in IT aren’t aware of the dangers of complexity: “Many software practitioners do not appreciate how critically important management of complexity is…” I would agree.

Roger Sessions has written a great book on complexity, titled  Simple Architectures for Complex Enterprises, in which he describes the problem and proposes concrete solutions to it. (I was fortunate enough to meet Roger last February at TechReady in Seattle). Roger blogs regularly about this subject. Roger opines that simplicity, the opposite of complexity, is a system quality attribute that is even more important than the other attributes, such as security, scalability, maintainability, etc.

In The Art of Software Architecture: Design Methods and Techniques, Stephen T. Albin states “Complexity is one of the primary problems that we attempt to address with software development tools and methods” Albin describes complexity in terms of interconnectedness and modularity, a useful way of understanding complexity and using modularity to deal with it.

In Emotional Intelligence for Project Managers: The People Skills You Need to Achieve Outstanding Results, Anthony Mersino asks the poignant question “Are You Ready to Lead Large and Complex Projects?”.


My Conclusion

The most complex thing in IT projects isn’t the architecture, it’s the people. I think many of us aren’t ready for the level of stakeholder complexity and conflict we have to deal with. Architectures become complex because people make them that way, Brooks’ “accidental complexity” is caused by people. If we all assume the mantra of “let’s keep things a simple as possible”, from when we get up in the morning to when we go to sleep at night, we might just create better architectures.

Bye for now.