Architectural Design

How to make sense of all the views and keep them consistent?

There are many modelling languages for an enterprise architect to master. Often times, they support a specific discipline (e.g. data modelling) or a technology domain (object oriented programming). From these languages, ArchiMate™ stands out, since it is designed as an ‘umbrella language’, to describe the ‘big picture’. One of its core design principles is to abstract from details in order to create overview and, at the same time, leave room to detail the architecture in specialised languages - such as UML for software, BPMN for business processes, SBVR for business rules and ERD for data (I hesitate to call these domain specific languages, as this term seems nowadays tightly linked to software engineering, but they are in fact different architecture domains). And of course, there are many, many more to choose from.

Model language confusion.

The ArchiMate language seems to be built on an implicit presumption, namely the contention that, once the big picture is given, the details can be worked out more or less independently. Or at least, this is what practitioners tend to promote. Unfortunately, in practice, this kind of separation of concerns holds seldom true.

Take for instance the case of UML. Its very name suggests it is universal, to be used to model an entire application in its environment, including its data model and the business services that support business processes. How then, could you model your software independently from your data and your business processes? On the other hand, you can also argue that because business rules are meant to be built on facts, and facts are commonly derived from data, modelling a data model independently from the business rules model is doomed to fail. And because more and more parts of businesses are developing into digital enterprises, the divide between the different architecture models is increasingly becoming painful.

The authors of the SBVR language have tried to mitigate this by designing a common business vocabulary as the foundation of every business model. In a way, this is the opposite to the ArchiMate approach - rather than an umbrella, it provides a common frame of reference. However, as many software engineers have experienced, human language is badly suited to catch the intricacies of technology. Not only is it notoriously inconsistent, imprecise and ambivalent, there is an even deeper problem. Our vocabulary is limited to the concepts we know. Research shows that children learn new concepts through language rather than the other way around. Perhaps counter intuitively, they first learn the words, and than gradually gain understanding of its meaning through observation and communication [Ref. Steven Pinker; The Stuff of Thought: Language as a Window into Human Nature]. As an aside, this explains why people from different language background truly have a different understanding of the world. As an example, people brought up in a language that has no word for the color blue, simply don’t perceive any difference between white and blue. So, in a way, human language can be thought of as a detailed model of reality as we experience it.

Conceptual confusion

Learning new concepts through language has an important limitation. Simply put, for something new, a concept perhaps without a name yet, but at least something you cannot yet experience, something that still has to take shape, this learning strategy will not work. Albert Einstein, for instance, managed to gain a deep understanding of a black hole before the term was even coined, purely through mathematical models. In the world of information technology, new technological concepts arise all the time. And in some cases, these new technologies breed new business concepts. Now, businesses coin new terms for these concepts continuously - and sometimes confusing new terms for existing concepts too. However, the true meaning of these concepts only emerge in time as the concepts gradually take their form and can be experienced. At the end of the hype cycle, at the plateau of productivity, in the Gartner lingo. And not seldom, the vocabulary also evolves until then.  

Models are being used to study and design altogether new concepts, giving insight into the parts that it is built from and into their interrelationships. Architecture models as business mathematics. Much like new molecules can be synthesised out of known atoms, new concepts can be composed out of existing parts - both from the technology and from the business domain - and modeled in relation to their abstractions. Insofar as architecture is used to translate the business strategy into an executable future-state design, this might even be an essential characteristic.

Taming the confusion

Back to the modelling languages confusion. Is there a way to reap the power of the different languages, perhaps even to allow designers to use their language of choice, and still achieve cohesion? Even if the umbrella design ArchiMate provides and the frame of reference approach in SBVR fail to that extent? Of course there is.

The established ISO/IEC/IEEE 42010 framework clearly describes that an architecture description - the expression of an architecture of a system - encapsulates multiple views, each addressing a subset of concerns of its stakeholders. This way, every model that illustrates a view, is embedded in an architecture description, in whichever modelling language it is expressed. In other words, the ArchiMate ‘over-view’ model, is part of the architecture description just as every other model is.

Now this is highly significant, because of one profound implication, being that the entire set of models and views must in fact be managed as a single architecture description. In other words, the alignment of the different views is an essential part of the constitution of an architecture description. One concept, one system; multiple viewpoints, multiple views. Therefore, it is the job of an architect not to describe all the views himself, but to direct a process to produce a complete and consistent set of views of an often complex reality, and have them embraced by the stakeholders. In this process, an ArchiMate view, a common vocabulary, a canonical data model, a reference architecture, and industry standards all can have a place, as do prototypes, executable designs and spikes, but it comes down to the craftsmanship of the architect to put them to good use in order to achieve step-by-step alignment among the members of his team, among the appropriate stakeholders, and, yes, among the models as well. Only then, architecture will become a powerful instrument for business change and even business transformation and the architect will gain the recognition of a job well done.