This article was first published on LinkedIn October 16, 2016.
The “Keep It Simple, Stupid” principle, also known as KISS, is only partly applicable to Enterprise Architecture, or any other architecture discipline actually. A more accurate expression would be MISS, "Make It Simple, Stupid", but then the Stupid does not fit, and the point isn’t really to make things as simple as possible, but rather to make them simple enough.
The far side of complexity
The point is that architecture most often deals with extremely complex structures. It therefore makes no sense to speak about keeping it simple when, in fact, it is already complex and in desperate need of simplification. The American supreme court justice, Oliver Wendell Holmes Jr. once said that:
“I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the far side of complexity”.
In order to arrive at the simplified version of the complexity, the architect will need an appropriate understanding of the complexity at hand, but also an understanding of the frame of reference of the stakeholder. This ability constitutes, in my experience, the core contribution of a skilled Enterprise Architect; being able to understand some complex structure sufficiently to then be able to Make It Simple – enough – to make sense to others.
Architecture vs Design
Let me take the opportunity to point out one common misunderstanding - in my opinion - about architecture. Architecture, and Enterprise Architecture in particular, is not primarily about creating a design for something new. That is design, and different from architecture. Even though building architects admittedly do precisely that – to a certain extent – create designs that is. And so do many hardware and infrastructure architects as well when I think of it, but they are probably also – strictly speaking – doing more design than architecture – I guess.
But now, I am ahead of myself again. Let’s leave the design vs architecture for a later post. The point is that the key value that an IT or Enterprise Architect brings to a project, or an organization, is the ability to structure and communicate complexity. Infrastructure implementations, software integration mechanisms, or business models are generally too complex for stakeholders to grasp, at least in full detail with all interdependencies. The role of the architect is to understand this complexity sufficiently well to be able to make a simplified model or description of it.
Necessary and Sufficient
Architecture itself is also a complex activity and IT and Enterprise Architects work with a large variety of scopes. Architecture is a label that is widely used in the IT industry – it can be argued that it is too widely used – and applied to a number of quite different disciplines and activities. For now I will take the complexity of architecture as a discipline and – as an architect – try to Make It Simple by stating that all architecture is, in essence, always about making complexity appropriately simple as seen from the perspective of some stakeholder. The goal being to provide the stakeholders involved with sufficient information at the necessary level of detail. My ambition, as an architect, is to make the complexities of running a business a little less complex. I do so by providing valuable business decision support and recommendations based on simplified models of the complex reality.
The architect as a pedagogue
Having a degree in pedagogics, I want to point out the importance of having a pedagogical mindset when trying to convey the underlying or embedded structure in a complex situation. Because, boiled down to the core, architecture is about exactly that, communicating the structure of complexity in a sufficiently simple way by use of visual and other representational means. By pedagogical mindset, I mean understanding what is sufficiently simple for whom and what format to use when communicating with different audiences. An architecture description should therefore not be measured by the accuracy or completeness, but on the “fit for purpose”-ness of conveying the relevant level of detail and complexity to the stakeholders in question.
I realise that one can easily argue that I – by writing this – have made the simple message of MISS a lot more complex than it needs to be. On that account, I can only agree and conclude that it is a good thing I work as an architect with power points and whiteboards, and not as a journalist or writer.
