IT architects operate in a complex world. I am of the opinion that it should be their mission to decrease this complexity. Or rather: it is OK for architects to dwell in the multi-dimension, model-driven, multi-tier view of the applications, (business-)services and layers of information that surround them, but their deliverables should to a certain extent be readable and understandable by people other than architects.
An IT architect, however, might prefer to present his or her findings as illustrated below:
Image found on https://blogs.msdn.microsoft.com/mikewalker/2009/03/11/mapping-current-state-architectures-across-the-enterprise/
Or like this:
Image found on https://medium.com/@sheldonline/the-government-it-self-harm-playbook-6537d3920f65
Granted, these are overly complicated application diagrams and visions (as the titles tell us – and you do need the title to make sense of the diagram in the first place), but diagrams like these are not all that rare. I have actually seen worse.
Fortunately, the business and information architect are not the only ones able to create complicated drawings. In infrastructure, something similar occurs:
Image found at https://www.cepro.com/images/wide/wiring_mess_w.jpg
Note the similarity between these images, particularly the first and third. Maybe the infrastructure architect has attempted to implement the application diagram in the wiring scheme. It is not that far off.
A New Design Language
In this article, I propose that it is time for a new design language in IT architecture, for the following reasons:
- The IT environment that surrounds the architect is rapidly modernizing its looks which necessitates the architect to follow suit;
- Current architectural modelling languages serve their purpose but produce diagrams, models and schematics that are difficult to read and follow for non-architects;
- The world of the architect does not have to be difficult;
- The architect will be better understood if his products are easier to understand;
- An architect does not solely work for other architects.
With these reasons, I not only touch upon the design language, but also on the field of architecture itself. I will take care to tread lightly. And please do appreciate the tongue-in-cheek-ness of what is written here!
1 Modernize your design language
Everywhere around us, IT systems are updating their design language to incorporate a more modern look. Interface design is becoming increasingly important, in great extent thanks to the ubiquitous mobile phone, its touch interface and necessity to present information clearly and legibly on a small screen. Design frameworks such Twitter’s Bootstrap help standardize and unify the interface of (web)applications and how we – consumers – interface and interact with them. In the example below, the default dashboard theme of Bootstrap is shown:
Image found at https://bootstrapbay.com/blog/bootstrap-panel/
This design language is available for anyone to use in their applications. Even so, corporate applications (and their descriptions in architecture documents) have a hard time catching up. We still see too much of this in our corporate environment (sorry SAP, it could be anyone else):
Image found at https://www.slideshare.net/yarivzur/sap-cross-ui-strategy
And we are not only seeing this, we are still modelling like this as well.
Image found at https://www.slideshare.net/tetradian/ea-roadmapping-businesstransformation-in-a-complex-world
There is some visual progress in the world of process notation, however: The Case Management Modelling Notation specification results in legible models such as depicted below:
Image found at https://methodandstyle.com/bpmn-cmmn-compared/
When combined, CMMN, DMN (Decision Modeling Notation) and BPMN (Business Process Modeling Notation) form a strong trio for process notation, execution and handling. Unfortunately, the experts in the field seem to disagree too much with each other on the best way forward – should CMMN and BPMN be merged, for example?
Even though interface design and case modelling might not be part of the architect’s daily routine, you cannot help but notice that there is progress in these fields of expertise – thanks to a unified design language such as Bootstrap. But I must regress. This article is not about interface design or model notation: it is about architecture.
2 Architectural Design Languages are too difficult to read
Within Enterprise Architecture, an often-used modelling language is ArchiMate. Its specification and core concept is available from the Open Group website and explained for example in the ArchiMate 3 documentation. In the image below, a (small) excerpt of the core concept is visible:
Image found on http://pubs.opengroup.org/architecture/archimate3-doc/apdxb.html#_Toc489946155
To a non-architect (but I must admit, to me as well) this might just as well look like a translation table for the currently undeciphered Pasja1000 Linear-A language. When you need a model to explain the meta-model, something is inherently wrong.
However, in an article on the future of the ArchiMate specification, it is stated that “Architects have a reputation for making complex and unreadable diagrams, which are only understood by a couple of inside architects. Although some of those architects may still be around, most architects today ensure that their visualizations are easy to understand. The ArchiMate modelling language is one of the modelling languages that can support architects in creating straightforward and understandable diagrams. Use of the ArchiMate notation helps architects understand each other’s architectures.”
I beg to differ. Not only is the modelling language not helping in creating straightforward diagrams, I also doubt it is helping architects in mutual understanding. And “easy to understand” is a very subjective remark: it still depends on the reader and – not unimportant – his or her knowledge of the ArchiMate specification in the first place. Which sort of rules out most of the (intended?) audience anyway, apart from the architect who retains his reputation for complicating things.
Next to this, the Open Group concludes that as the specification is complete, it is now time to understand how it is being used. One would assume this is done the other way around, that the object of description is studied before the descriptive language is formalized.
Other architectural modelling languages exist. The Unified Modelling Language (UML) could be used in an enterprise architecture context and there is the Enterprise Architecture Modelling Language (EAML). Their method of representation is not necessarily more easy to understand, however.
Found at http://www.heppnetz.de/ontologies/goodrelations/goodrelations-UML.png
3 Architecture does not have to be difficult
Even though architects are generally considered to be those who make things complicated, there is no reason for this to be so. Of course, architects work at a higher level of abstraction than other people in software development (or other users of an IT system), but this – again – should (must) not automatically imply complexity. Abstraction, as a matter of fact, originally meant leaving out unnecessary information to distill only the most important tidbits or fundamental structures. Somehow, an incredibly complicated application diagram – even though it could be factually correct – does not feel like an abstraction to me. Are architects focusing on the wrong layers? Are they presenting the tidbits, instead of the structures?
4 The architect will be better understood if his products are easier to understand
I think the ICT architect could learn something from building architecture here. From a very simplistic point of view, the “other” architecture (which has been around for some 2.000 years) tries to make sure the drawing represents the end product.
The Roman Vitruvius in 20 BC wrote ten books on architecture. He firmly believed that the architect should focus on firmitas (strength), utilitas (functionality) and venustas (beauty). The latter is a difficult topic and Vitruvius had an interesting view on it: he was convinced that the proportions of the human body provided a perfect model.
Image found at http://www.bl.uk/learning/cult/bodies/vitruvius/proportion.html
I do not know exactly how the dimensions of the human body would translate to a model of ICT architecture, but the point is that in building architecture there is a relation between beauty and function, which translate to both the outside and inside: buildings have an exterior (the expression) and an interior (the experience). At least the exterior should appeal to the average user and the specialist alike. And the model should resemble the end product.
Now let us compare this to ICT architecture. In ICT architecture, the schematic or drawing usually does not resemble the end product – on the contrary. Also, more often than not interior and exterior are not separated. In monolithic applications, they are one and the same. In service oriented architecture, an attempt was made to create a separation based on function, data and logic (all interior) without paying too much attention to the interior. Maybe with microservices a distinction between interior and exterior is possible.
An ICT architect, then, should focus on both interior and exterior. The interior is for him and other specialists to understand. The exterior is for anyone to see (and marvel at). The two are connected and inseperable.
An interesting summary on what makes a good architect – in Vitruvius view – can be found in Book I. This view on the architect is to a certain extent still valid today: a modern architect is engaged in (contemporary) culture and (philosophical) thought, just as much as in construction theory. It would be a good thing if ICT architects followed their lead.
5 Architecture is not for architects
A last remaining question is who should be the recipient of ICT architecture. Do architects create for other architects?
One of the main issues with a statement like the above is that it supposed the existence of “the architect”. Of course, there is the protected title of a building architect, but within ICT there is no such thing. We distinguish a great number of different ICT architects. We call people architect who are consultants, or engineers. I have worked with clients who described me as a data architect because I performed a data quality analysis in that specific assignment. I have seen external consultants fulfill the role of enterprise architect (guilty there), even though this should be an “internal” role. An infrastructure architect and a business architect might both use Visio or ArchiMate, but they will often not be able to fully grasp the work of the other.
The resulting question is twofold. Should architects understand other architects, and should anyone outside the architecture community understand the work that is produced within that community? As you might have guessed by looking at the structure of this article, I sincerely believe both questions should be answered with “yes”. The distinction between interior and exterior that I mentioned before could provide a touchpoint here: interior for those within the specific architecture domain and exterior for everyone else.
Everything is subjective!
As you might have noticed I am carefully avoiding calling specific design “ugly”. Aesthetics are very subjective: a diagram or model may look incredibly beautiful but still be totally illegible. Or worse, a design may work properly from a functional perspective but miss the point completely.
Also, a model may be difficult to understand for an audience, but whether or not that is a problem depends on what audience was intended in the first place. As an example, please consider the image below:
Image found at https://i.stack.imgur.com/6svp7.png
Now I am not an electrical engineer so this image does not make much sense to me. It led to a lively discussion on StackExchange, however.
A solution
A new architecture design language, as the title of this article suggests, should provide an internal and external view (needless to say, I am not referring to the architectural concept of “view”, but rather a design concept) on the specific architecture it describes. The internal view is for the architecture community and may contain as many models, lines, dashes and diamond shapes as fit on the canvas. The external view is for everyone else and contains a simplified, abstracted – but accurate – view on the architecture that can be understood, shared, presented and marvelled at. Ultimately, this will create understanding for the work of the architect and provide the right level of support when necessary. And it will bring re-introduce the core quality of architecture: the abstraction of things. And hopefully, some beautiful work as well.
Disclaimer
- all images were found using Google (images) and – where appropriate – contain a reference to their source and the article they are mentioned in.