Is this Architecture? Where is the sentence?

What is architecture when we are modelling? We might have architecture elements but is this enough? Consider the following thought experiment.

On the first line we have 2 things. We don’t know what type they are. We can’t say anything about them and therefore this cannot be architecture.

On the second line we know that they are both systems and there is some unidentified relationship between them. We know nothing about this relationship in terms of what it is or the direction. This still cannot be architecture.

On the third line we know we have 2 systems and that System A is configured with System B. At last, this is architecture! But why? The fact is that we know how these 2 things relate to each other and this is at the core of architectural modelling. It is about describing relationships between things and placing things in their proper context. In many cases we are probably more concerned with the relationships between architecture elements than the detail of the elements themselves since we can then navigate along these paths or use them in queries to answer questions or discover things. This is one of the key differences in emphasis between an Enterprise Architect using, say, a UML tool, to a Software Designer. It probably also is at the base of a lot of frustration with tools.

At a more general level this is architecture because it provides all the parts of a language to allow us to describe what the situation is - we have 2 nouns and a verb so that we have a proper sentence. Without the verb (the relationship) we do not have a sentence and therefore cannot communicate anything meaningful.

This might sound trivial but it is important. It states that we need 3 things for it to be considered architecture - an object, a verb and the subject of the verb. In other words this looks like a tuple or a triple which is an important construct for an ontology. I suppose I sort of realised this but it was only in trying to define what is mandatory and what is optional for an architecture viewpoint (in ISO 42010 terms) that it became clear that just specifying metamodel elements wasn’t enough - the meaning is in the tuples.

The other advantage of treating it like a natural language is that it makes it easy to communicate with folks who aren’t UML experts. Take for example the following 2 examples.

Reading from left to right we have;

• Whizzo Dynamics (an organisation) plays the role of system authority which extends to Confabulator (a system)
• System Authority (a role) requires competence in architecture modelling in order to conduct Design System (a function)

and as architecture modelling ought to be about communication this is starting to be both useful and effective from a usability perspective.

Comments

Comment on this article

Related Articles

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (10% )
• Definitions - What Exactly is a Risk Part 2? (10% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )
• NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF? (10% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (10% )

External Links