Unravelling the anatomy of Archimate
The Archimate notation aims to be the standard to be used by everyone in enterprise-architecture and related fields. But what exactly is its anatomy – its underlying structure? And if it’s aimed at enterprise-architecture, what is it about that structure that makes it seem only to support IT-architecture, and in such an awkwardly IT-centric way?
(Apologies, folks, because, yes, this is going to be another one of those very long, very technical posts… Skip it if you’re not interested, of course, though I believe this actually is important for anyone involved in enterprise-architecture and the like.)
To anyone working in enterprise-architectures, Archimate ought to be the first point we turn to when starting to model any aspect of the enterprise. Unlike Zachman, for example, it places just as much attention to the ‘lines’, the connections between the ‘boxes’ (the ‘things’) of the architecture as it does to the ‘boxes’ themselves. That’s hugely important – and almost unique in the enterprise-architecture space.
But to me, and to many others, it just… I don’t know… just doesn’t seem to work? Something doesn’t quite gel… something like that, anyway. It gives the sense that it ought to be right, that it ought to work – but somehow it just… doesn’t. And that sense of it not-quite-working gets more and more extreme the more we try to move outward from anything but the most IT-centric of architecture views. Odd. Very odd.
A couple of weeks back I wrote a post on this – ‘Is Archimate too IT-centric for enterprise-architecture?‘ – one outcome of which was a very gentlemanly discussion with one of Archimate’s key originators, Marc Lankhorst. One of the outcomes of that discussion was that Marc very kindly sent me a copy of one of the key formal papers on Archimate, ‘The Anatomy of the Archimate Language’, by Marc Lankhorst, H.A. (Erik) Proper and Henk Jonkers, in International Journal of Information System Modeling and Design, 1(1), 1-32, January-March 2010. (I don’t think it’s available on-line, but it’s worth hunting out from somewhere, anyway.)
What follows is perhaps somewhat unfair to Marc, in a way, because I know he’s away on vacation at the moment, and probably can’t reply for some weeks. Point is that I just wanted to get this down straight away before I forget it… 🙁 – and definitely no slur is intended, though I’ll have to say that I really am worried by what I’ve seen. If Marc won’t be able to reply for a while, perhaps Erik or Henk could join in on this instead?
So I’ve been reading that ‘Anatomy’ paper over the past couple of days – and after doing that, I’d have to say that I’m at the point where I don’t know whether I should just sit down and cry…
Yes, it really is that serious. Sorry, but it is. Yes, I do understand that the organisations who were the main drivers for this were ‘the usual suspects’ – banking, insurance and tax – which would have skewed things anyway quite a long way down the IT-centric path. Even beyond that, though, something went seriously wrong there – and I have no idea why. I don’t know why certain decisions were made, but it’s evident that a number of decisions were made, from about halfway through the metamodel design-process, that completely cripple the whole framework. In effect, they change the underlying structure of Archimate from something that’s clear, simple, yet immensely powerful and usable across the whole enterprise-architecture space, into something that’s so arbitrarily constrained that it’s usable only for a tiny subset of the architecture space, and that it crumples into a tangled, all-but-unusable mess the moment we move outside of that scope.
Those decisions do seem to be described in the ‘Anatomy’ document. But to me they don’t make any sense at all, and to be blunt I can’t see how anyone could make those decisions other than as a temporary kludge to get something just-about-usable out of the door. That happens often enough under real-world pressure, of course. But that ‘temporary’ kludge – if that’s what it was – was somehow allowed to remain unchallenged and unchanged within the structure, such that when it was later taken over as a standard, no further review seems to have taken place, and the kludge itself was mistaken for ‘fact’. Which leaves us with the problems that we’re facing with Archimate right now, where it really isn’t usable for enterprise-architecture.
It is fixable. It’s even fixable in a form that retains backwards-compatibility with the current v1.0 standard. (And probably with the upcoming v2.0 too, but I don’t as yet have access to the information needed to be certain of that.) But the first point is that we need to acknowledge that it doesn’t work at present, and why it doesn’t work at present. Once we’ve done that, I believe it’s actually quite straightforward to show what we need to do to make it work again.
What I’ll do here is go through the underlying structure, step by step, exactly as specified in the ‘Anatomy’ document. (As above, I don’t think that the document is available on-line, so I’ll have to ask you to trust me on this: Erik or Henk or one of the other designers should be able to correct me if I get it wrong, anyway.)
I’ll show the design-decisions at each stage, and make some suggestions [shown in square-braces, like this] as to how ‘defensible’ each of those decisions would be, as measured against the full scope of whole-of-enterprise architecture. (There’s no point in looking at a narrower scope, since anything less would create the kind of arbitrary-subset boundaries that we’re already struggling with at present.)
So, go to it.
The anatomy of Archimate
The Archimate metamodel is defined using Object Role Modelling (ORM2) notation “as graphical representations of underlying logical theory”.
[Agreed: it’s a better choice than, say UML or MOF, in my opinion.]
Level 0: define an entity called ‘Element’, which in essence could be anything at all.
[An obviously necessary first step.]
Level 1: define two types of Element, called ‘Concept’ and ‘Relation’.
[These are core definitions for just about any type of metamodel – though note that these are the only root-Elements defined.]
A Concept represents just about any kind of ‘thing’ – in any sense of ‘thing’ – whereas a Relation is a link between ‘things’.
The definition-term for the relationship implied by a Relation link is described as the ‘fact’ of the relationship.
[May be specific to ORM, but no complaints here, anyway.]
A Relation can be used to link any Concept to any Concept: “A Concept is related to another Concept if and only if the first Concept is source of some Relation which has as destination the second Concept.”
[Again, this is common to most types of metamodel that I’ve seen.]
A Relation can be used to create a link where the same Concept is both ‘source’ and ‘destination’, as in recursion.
[The recursion is a useful design-decision, though note that it is a decision – not an inherent logical corollary of anything else.]
A Relation can only be used to link between Concepts; a Relation cannot be used to link to another Relation.
[Again, this is a useful design-decision, though one that does impose a significant constraint from now on. Within ORM itself, for example, Relations are allowed to link to other Relations.]
Level 2: Because “the domains we are interested in tend to be large and complex”, four specialisations of the default relation-fact ‘is related to‘ are defined. These more-specific relations are ‘is realisation of‘ (the inverse of abstraction); ‘is specialisation of‘ (specialisation), ‘is aggregation of‘ and ‘is composed of‘ (aggregation/composition).
[This again is a design-decision, though one that’s common to many other notations such as UML. These specialisations are additional to rather than substitutes for ‘is related to‘, and other relation-facts remain possible, hence no absolute constraint is passed on here. Note that in the Archimate standard, the default relation ‘is related to‘ is termed an Association.]
Level 3: An either/or specialisation is applied to all Concepts: a Concept may be either an Intentional Concept (subjective, ‘Why’) or an Extensional Concept (objective, usually ‘What’ or ‘How’).
[This is another design-decision that is not an inherent corollary of anything else. No particular complaints here – though as we’ll see, almost all Archimate entities are Extensional Concepts.]
Two additional specialisations of ‘is related to‘ support this separation of concepts: a ‘has‘ relationship may exist between an Intentional Concept and an Extensional Concept; and a ‘uses‘ relationship may exist between two Extensional Concepts.
[Again, this pair of specialisations don’t constrain anything as such, though note that there is no equivalent, for Intentional Concepts, of the Extensional ‘uses‘ relationship.]
Level 4: Specialisations are applied to both Extensional Concepts and Intentional Concepts.
An either/or specialisation is applied to Extensional Concepts: each must be either Passive Structure (e.g. object), Behaviour (e.g. action, verb etc), or Active Structure (e.g. agent, subject etc).
[Because this is a strict either/or, this is probably the first design-decision that really does constrain further development of the metamodel: this is probably the core design-decision that’s visible right the way through the final Archimate notation. I have no particular objection to this, other than to note that it is arbitrarily constrained from now on, because it doesn’t seem to allow for the possibility that something might exist that would not fit into any of those three categories, or might straddle more than one of the categories.]
Two additional specialisations of ‘is related to‘ support this separation of concepts: an ‘is accessed by‘ relationship may exist between a Passive Structure concept and a Behaviour concept; and a ‘has assigned‘ relationship may exist between an Active Structure concept and a Behaviour concept.
[Note that no specific relationship is defined between Active Structure and Passive Structure, though it seems probable that the default ‘is related to‘ could still apply.]
Three specialisations are applied to Intentional Concept, providing the entities Meaning, Value and Reason. These represent single concepts, not categories, and are not specifically aligned to the Passive Structure, Behaviour or Active Structure of the Extensional Concepts. No additional specialisations of relationships are defined between these entities, and since no specific relationships are defined between Intentional Concepts, the only available relationship between them is the default ‘is related to‘.
[It’s at this point that the structural integrity of Archimate starts to break down, because we have clearly-defined and ‘defensible’ specialisations in the Extensional Concepts area, and seemingly arbitrary and ‘indefensible’ specialisations in the Intentional Concepts. It’s actually worse in the final metamodel-definition for Archimate v1.0, because the distinction between Extensional Concept and Intentional Concept disappears from view, and the Meaning and Value entities are then arbitrarily parked under Passive Structure, as if they were Extensional Concepts. And for no clear reason, the Reason entity is arbitrarily dropped from the entire metamodel, with the result that Archimate then has no means to describe requirements, business-rules for processes, or any kind of business-decision or business-reason – placing an absurd constraint on what Archimate is able to model. The upcoming Motivation extension promised for v2.0 may resolve some of this, but only some, because the linkage appears to have been lost right down at this fairly deep level of the metamodel.]
Level 5: An either/or specialisation is applied to Extensional Concepts only, splitting them into two categories: ‘external’ (e.g. Service, Interface), and ‘internal’ (e.g. Object, Function, Role).
[It’s unclear as to whether or not this split applies only to the Behaviour and Active Structure categories: the ‘Anatomy’ document asserts that it does not apply to the Passive Structure category, although in fact an External Passive Structure entity ‘Representation’ is defined in the final metamodel, applying only to the Business layer. Again, this is ‘special case on special case’ without any defensible rationale, leading to even further fragmentation of the core metamodel.]
A mandatory ‘uses‘ relationship applies from an Internal Active Structure entity (e.g. Role) to an External Active Structure entity (e.g. Interface). A mandatory ‘is realised by‘ relation applies from an Internal Behaviour entity (e.g. Function) to an External Behaviour entity (e.g. Service). An Internal Behaviour entity and Internal Active Structure entity may be assigned to each other; likewise External Behaviour and External Active Structure; but not Internal Behaviour to External Active Structure, or External Behaviour to Internal Active Structure. Internal Passive Structure may have an ‘is accessed by‘ relationship with Internal Behaviour or External Behaviour, but not either Internal Active Structure or External Active Structure.
[We’re now starting to drown in special-cases of special-cases of special-cases… Metamodel integrity is seriously falling apart by this stage, especially as none of these design-choices appear to be a required logical corollary of anything else that has gone before.]
Level 6: Another either/or specialisation is applied, to categorise entities into Individual or Collective. In principle this is orthogonal both to the Passive Structure / Behaviour / Active Structure split, and to the Internal / External split. In practice, this seems to apply solely to Internal Behaviour (Collective, as Interaction) and to External Active Structure (Collective, as Collaboration) and Internal Active Structure (Individual, as Actor). The Collaboration entity has a ‘has assigned‘ relationship with Interaction, which seems to break the previous rule that External Active Structure cannot link to Internal Behaviour – though confusingly Collaboration is also shown as an ‘is aggregation of‘ specialisation of the Internal Active Structure entity Role.
[To be blunt, I’m lost here, and I suspect most other people would be lost here, too. There’s almost no metamodel-integrity left in this at all: there is still a nominal structure behind it, but it’s so arbitrarily constrained, without any apparent defence of any of the constraints, that all that remains is yet more special-cases on special-cases on special-cases… However, the relationship between Role and Actor is something that we’ll need to come back to later, because to me it’s a key part of how to restructure this into something that can work.]
Level 7: The architectural space is now split into three layers: Business, Application, and Technology. The metamodel structure as described is replicated in each of these layers.
[The replication of the metamodel in each of the spaces makes sense, but nothing else does. Nothing. Let’s be absolutely blunt about this: there is not the slightest shred of defence as to why the architecture-space should be partitioned in this way. There is no reason given as to why it should be these three layers; there is no reason given as to why there should only be three layers; there is no reason given as to why they should be layers at all, or why these partitions should be in layer-like relationships with each other. This part of the Archimate metamodel is the outcome of a non-defensible set of arbitrary a-priori assertions, based on no logical corollary from anything, nor, it seems, any fundamental facts about the nature of the overall architecture space. This is probably the primary source of the limited usability of Archimate, but compounded with the inconsistencies introduced by all the variously-arbitrary constraints from before, it should be no surprise if the final end-result is a crippled, near-unusable mess. Okay, not actually ‘unusable’: it’s unfair to say that, because it presumably did satisfy the immediate needs of the initial clients, and it does align reasonably well with the inherent IT-centrism of TOGAF 9 and the like. So yes, it does satisfy some needs – but, as evidenced above, at a cost of near-unusability for any other purpose and/or any other architectural scope. I’m sorry, but that is true… and we do need to stop pretending otherwise. 🙁 ]
Given that these partitions are in vertical layered relationships to each other, the External entities in each layer will link ‘upward’ to the Internal entities in the layer ‘above’. Hence a Passive Structure entity may have an ‘is used by‘ relationship with Passive Structure in the layer above (note that there is no distinction between Internal and External for Passive Structure); an External Behaviour entity (e.g. Service) may have a ‘uses‘ relationship with Internal Behaviour (e.g. Function) in the layer above; and likewise an External Active Structure (e.g. Interface) may have a ‘uses‘ relation with Internal Active Structure (e.g. Role) in the layer above. A Passive Structure entity may also have an ‘is realised by‘ relationship with the Individual Internal Active Structure entity Actor.
[These relationships do sort-of make sense – but as such they only make sense within a presumed layered structure, and don’t make sense in any other type of structure. There is, however, another way to look at this, as we’ll see later. Note that the ‘is realised by‘ rather than ‘uses‘ relationship between Passive Structure (Object) and Actor implies that Actor is actually closer in nature to Passive Structure than to Active Structure, where it was somewhat arbitrarily placed before; this too suggests an alternative structural option that we’ll explore later.]
Level 8: Specific entities and relationships are defined for each of the layers, based on the underlying structure of the metamodel.
[I won’t go into this in detail: it’s all in the Archimate formal-standard, anyway. But I’m going to have to be rude here, and describe this part of the metamodel as ‘disaster-area’, because in practice that’s exactly what it is.
I’m struggling to find a kinder way to put this, but I’m sorry, because it really does have to be said. Fact is that by this stage what we have in front of us as the Archimate ‘anatomy’ is little more than a bunch of fairly arbitrary entities with a bunch of fairly arbitrary-seeming relationships, with no real rhyme or reason to any of it. There isn’t any real structure here, because it’s been so fragmented by special-cases and arbitrary inconsistencies and a-priori assertions that it’s lost almost all connection to the work that’s gone before: all that’s left are some incomplete aspects of the original Passive Structure / Behaviour / Active Structure split, and of the Internal / External split, together with a few half-explained fragments of the Individual / Collective split. All of the Intentional entities are arbitrarily shoved into the Passive Structure of the Business Layer, with no reason given as to why this has been done, and with no connection to either of the other layers; the Reason entity has been lost, hence there is no way, for example, to show a requirements-derivation trail for anything. And a few extra entities are added, such as Event and Junction, which, useful though they are, have no explicit linkage back to any of the previously-defined underlying structure – which means we’re forced to treat them as unexplained special-cases too.
As is usual in IT-centrism, the Business layer is clearly used as an arbitrary grab-bag for ‘anything not-IT’; Process appears in this layer only, again with no explanation as to why it is there or even what it is. As in Zachman, the only Passive Structures supported are various manifestations of data – no physical objects, for example. In the ‘lower’ layers, the metamodel is cluttered with arbitrary specialisations of entities, some of which – Network and Node, for example – seemingly appear from nowhere with no apparent explanation other than that someone presumably saw a need for each; and also cluttered with a bewildering variety of special-case relationships or constraints on relationships.
And in essence, human-activities occur only in the Business layer, information-activities only in the Application layer, and (a specific subset of) machine-activities occur only in the Technology layer. There is no means to model anything that does not fit these assumptions, and there is no way to model an end-to-end process without jumping between layers almost at random – a fact which in itself indicates that these should not be viewed as layers.
I could go on, but you’ll see the point already…? And why I said right back at the beginning that I didn’t whether to just give up and cry…?]
And that completes the summary of the current anatomy of Archimate. Sorry again, but ‘ouch…’
Which leads to the obvious question: what the heck can we do to make it right?
Rethinking the anatomy of Archimate
Let’s again go through it step by step, using the same Levels structure from the ‘Anatomy’ document, and again adding comments in indented square-braces.
(For some of the background reasoning that I’ve used here, perhaps take a look at some of the various posts I’ve done on EA-metamodel themes over the past few years, or the more-detailed ‘proposal for an open-source EA-metamodel‘ that I worked on for some while a couple of years ago.)
First, though, we need some clarity on the purpose of this cleaned-up Archimate. Hence start with a few assertions to set the scene:
Assertion 1: Architecture is “the fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution”.
[The quote is from the ISO/IEC 42010 standard. I don’t fully agree with that assertion, but it is the core definition of architecture upon which the existing Archimate standard is based, so we need to keep to it for backwards-compatibility. Note, though, that this definition says nothing whatsoever about the purported centrality of IT, nor does it specify any particular boundaries to ‘the system’ or, for that matter, ‘the environment’ within which ‘the system’ will operate. This is a definition that’s broad enough to support an architecture with a true whole-of-enterprise scope.]
Assertion 2: The primary purpose of the metamodel, and the notation(s) upon which it is based, is to enable modelling of an architectural context in terms of its perceived structural components, their relationships to each other and the context, and to the guiding principles that apply in that context. In short, the relationships between structure and purpose in an architectural context.
[This imposes explicit constraints on the purpose, role and content of the metamodel. However, it is a direct corollary of the previous assertion, and it is the (broader version of) the basis for the current Archimate, so we need it for backwards compatibility. Note, though, that it doesn’t impose any specific constraint or structure on what is to be modelled – it does not force us down the IT-centric path, or even assert that there ‘is’ any content or scope that must be considered as ‘the centre’ for the architecture.
It’s important to note what isn’t covered by or included within this structure-oriented purpose-definition for the metamodel – and perhaps should be. Three key examples are:
– dynamics: flows and sequences, as would be used in simulation
– transitions: changes in the structure, as in the classic notion of ‘as-is’ to ‘to-be’
– governance, especially for transitions: project-management and the like – such as would nominally be covered by the Project extensions apparently proposed for Archimate v2.0
As we go on, I’ll include comments on where support for these requirements could perhaps be added to the metamodel, but the main focus right now is backwards-compatibility with the existing Archimate, to cause the minimum disruption for toolset-vendors and the like.
My own personal aim is that this ‘cleaned-up Archimate’ would be able to support the full expansion of a business-model (e.g. in Business Model Canvas) to a static(ish) structure-description at an enterprise-architecture level, including supply-chains, value-networks, linkage to extended-enterprise (including non-clients and anti-clients), detail-layer modelling, values-mapping, end-to-end process description, customer-journey description, implementation-tradeoff analysis, and business-continuity/disaster-recovery planning. Support for a lot of other requirements – such as the dynamics, transitions and change-governance above – would be a definite bonus, but for Archimate-equivalence I don’t think it’s a central need right now.]
Assertion 3: Consistency in the metamodel is paramount.
[This is essential to avoid the ‘disaster-area’ inconsistency of arbitrary special-cases of special-cases that bedevils the existing Archimate metamodel.]
To support consistency, the following rules will be applied:
Rule A) All entities – including Concepts and Relations – will be defined in terms of ‘inheritance’ from previously-defined entities.
[This is straightforward, but it means that we do need to be careful what kind of partitioning we apply. The ‘inheritance’ concept also makes it possible to create a much simpler yet more versatile metamodel for EA toolsets.]
Rule B) The full inheritance-tree of an entity – including relations and attributes – will be available to all entities derived from or based on that entity, unless explicitly blocked.
[The point of this assertion is that we’re not allowed to simply churn out special-cases, as in the current Archimate. If we want to constrain something, we need to give a reason to do so, and we need to explicitly block something that we don’t want that entity to inherit – which makes it clear that it is constrained.]
Rule C) A limited form of multiple-inheritance is supported, in that attributes derived from partitionings that are described as orthogonal to each other may be combined within any entity-type built upon those orthogonal partitionings. By default, an entity-type would inherit all attributes from the parents, unless one or other of the root-partitions is excluded, in matrix-fashion; individual attributes may also be explicitly blocked, as above. By default, these constraints applied to an entity-type will apply to to any of its derived ‘child’ entity-types.
[In effect, this is what happens with the existing Archimate metamodel, to create entity-types such as Business-layer Internal Collective Extensional Behaviour – otherwise known as ‘Business Process’. But in the existing metamodel, the mapping is not transparent, and is not handled in a consistent way – both of which problems are resolved by this rule.]
Rule D) Entity-types may be categorised as ‘abstract’, in that no displayable instantiation may be made from that specific entity-type (though see the note about ‘null-object’ in Rule F below). The constraint would be applied at the entity-type level, by explicit blocking as above, and would not be automatically inherited in ‘child’ entity-types derived from that entity-type.
[This is mainly about minimising confusion in the modelling process: in most cases we only want a specific sub-set of entities to be available, not every possible parent in every derivation-tree. There are a few special-cases for which it may be useful to permit modelling with instances of abstract-classes, so in EA toolsets it would probably be best to implement this as a default behaviour that can be overridden if required, rather than an absolute constraint.
This also enables us to support valid placeholders for entity-types that ‘should’ exist, according to the metamodel logic, but for which we do not yet have an apparent need. This resolves a consistency-problem seen often in the current Archimate structure, where categories are arbitrarily dropped from the metamodel, and hence seemingly cannot be retrieved in contexts where such entities are then needed – as was the case with the arbitrary abandonment of the External Passive Structure category and the subsequent re-inclusion of the Representation entity for the ‘Business’ layer only.]
Rule E) In notation, the visualisation(s) of each of the parent-entities will be available for display in each derived entity. A default visualisation (notation view) will be required for each entity, whether or not it is usually instantiated or derived-from. It is strongly recommended – but not mandatory – that entities permit multiple visualisations of themselves, both at the ‘class’ and ‘instance’ level.
[This is perhaps a bit abstruse, but it enables us to show the ‘same’ entity at different levels of abstraction. The recommendation about ‘multiple visualisations’ is to resolve a problem frequently encountered in modelling for different audiences: we need to show an appropriate visualisation – a computer, a fork-lift truck, a picture of a handshake or whatever – whilst still maintaining the formal rigour of the underlying model.]
Rule F) Even for ‘abstract classes’ that are not usually displayable, a ‘null-object’ must always be available for every entity-type, such as to indicate a placeholder for something that will be added to, or will be removed from, the model at some future point. Within modelling, and in an EA toolset, it should be permissible to convert a ‘null-object’ to a real (i.e. valid) entity of the respective entity-class or any derived class. For automated verification of models, such null-objects should cause a warning to be generated, but – other than for executable models – should not cause the verification to fail.
[This is to support two very common requirements in architecture-modelling: the process of modelling itself, and modelling of transitions from ‘as-is’ to ‘to-be’ etc. During modelling, we often want to describe an entity whose full details are not yet known, or the end-point of a link for which the source-entity is already modelled: this enables us to add a ‘legal’ placeholder to the model, but which will still warn us about the model’s actual incomplete state. Much the same applies in transitions, when developing transition-maps between ‘as-is’ and some ‘to-be’: we often need a placeholder for an entity that at present does not exist, or that will no longer exist in the ‘to-be’ context.]
Rule G) The metamodel supports a concept of ‘sets’. These are of two distinct types – exclusive, and intersecting – and typically represent the overall viewpoint of a specific group stakeholders. Exclusive-sets are created in groups – such as ‘layers’ – which each incorporate the current structure of the metamodel, but in which subsequent specialisations (derived entity-types) are specific to that set only. Intersecting-sets – such as a security-view, or a process-view – incorporate a selected subset of entities from across the whole of the current metamodel, regardless of exclusive-set boundaries. (In effect, there is always one ‘intersecting-set’ that consists of all of the entities represented in the entirety of the current metamodel.) A set may or may not permit further specialisation of entities that would be specific to that set alone.
[This is both to support the concept of ‘layers’ as in the current Archimate, and also to break out of their current IT-centric stranglehold. Personally I think that the concept of layers is dangerously misleading, but if we want to use layers, we can. In my opinion the only valid approach is to use intersecting-layers to describe the architecture ‘world’ from selected viewpoints – and unlike the current Archimate metamodel, this does provide proper support for that. In essence, the existing Archimate ‘viewpoints’ and ‘views’ are sets that can only use existing entities – in other words, are not permitted within themselves to create new specialisation-entities – so this mechanism does fully support that requirement as well.]
Assertion 4: The metamodel is defined using Object Role Modelling (ORM2) notation.
[This is an obviously-necessary requirement for compatibility with the existing Archimate metamodel. To be honest, I won’t actually use the proper ORM notation here – I’ll use text-descriptions instead – but the point is that it should be possible to model all of what follows in ‘legal’ ORM notation.]
Which brings us to the start of the Level structure of the original document.
Level 0: Define an entity called ‘Element’, which in essence could be anything at all.
Level 1: Define two types of Element, called ‘Concept’ and ‘Relation’. A Concept represents just about any kind of ‘thing’ – in any sense of ‘thing’ – whereas a Relation is a link between ‘things’. The definition-term for the relationship implied by a Relation link is described as the ‘fact’ of the relationship. A Relation can be used to link any Concept to any Concept, including to the same Concept, as in recursion; a Relation cannot be used to link to another Relation.
Level 2: Four specialisations of the default relation-fact ‘is related to‘ are defined. These more-specific relations are ‘is realisation of‘, ‘is specialisation of‘, ‘is aggregation of‘ and ‘is composed of‘.
[All of Level 0 to Level 2 is unchanged, exactly as in the original ‘Anatomy’ specification. Not a surprise, since it’s all very much root-level stuff.
By the way, note that general-purpose Archimate entities such as Group and Junction are actually defined as ‘closed’ (non-extensible) specialisations of Concept, right down at this level.]
Level 3: An either/or specialisation is applied to all Concepts: a Concept may be either an Intentional Concept (subjective, ‘Why’) or an Extensional Concept (objective, usually ‘What’ or ‘How’). Two specialisations of the default-relation support this separation of concepts: a ‘has‘ relationship may exist between an Intentional Concept and an Extensional Concept; and a ‘uses‘ relationship may exist between two Extensional Concepts.
[Again, this is exactly as in the original ‘Anatomy’ specification. However, we probably do need to define permissible relationships between Intentional Concepts, and possibly right down at this level: typical relationship-types would include the RDF core set for thesauri – ‘BroaderTerm‘, ‘NarrowerTerm‘, ‘Use‘, ‘UsedFor‘, ‘RelatedTerm‘ – plus requirements-oriented relationships such as ‘isA‘, ‘extends‘, ‘implements‘ and ‘conflictsWith‘. We also need to take some care that, having in effect split ‘Why’ from everything else, we don’t simply forget it – as happened in the current Archimate!]
//An aside: At this point I’m going to have to deviate somewhat from the ‘Anatomy’ level-numbering in Level 4 to Level 6, because there’s a core point – almost casually glossed-over in the document – which renders the notion of ‘levels’ invalid for this part of the metamodel. This is that much of what is defined in that stage consists of sets of either/or splits that are nominally orthogonal to each other – and hence must be considered to be at the same level in the metamodel. Part of the ‘Anatomy’ Level 4 – on specialisations for the Intentional Concepts – should remain as that level-number; everything else in the original Level 4 to Level 6 will go into subsections of an amended Level 5. For consistency with the ‘Anatomy’ document, ‘Level 6’ will be dropped, so that we realign with ‘Anatomy’ at Level 7.//
Level 4: Three specialisations are applied to Intentional Concept, providing the entities Meaning, Value and Reason. These represent single concepts, not categories: they exist primarily to provide backward-compatibility with Archimate v1.0. (See ‘Level 3’ above regarding relationship-types.)
[Further specialisations, expansions and relations of Intentional Concept should be definable, sufficient to cover everything in a required Motivation extension (as promised for Archimate v2.0), or preferably a more complete motivation-model such as Nick Malik’s Enterprise Business Motivation Model.
Note that this general category of Intentional Concepts must always remain distinct from any category or sub-category of Extensional Concepts: for example, they must not be bundled in with Passive Structure, as in standard Archimate. Additionally, if the Level 5a-recommendation to define a Decisions category of Extensional Concepts is followed, care should be taken to ensure that those are not confused with Intentional Concepts: both are ‘Why’ in Zachman terms, but Intentional Concepts describe the emotive ‘Why’ of motivation, whereas the Decision Extensional Concepts describe the active ‘Why’ associated directly with Behaviour and Active Structure.]
Level 5a (‘Level 4’): An either/or specialisation is applied to Extensional Concepts: each must be either Passive Structure (e.g. object), Behaviour (e.g. action, verb etc), or Active Structure (e.g. agent, subject etc). Two additional specialisations of ‘is related to‘ support this separation of concepts: an ‘is accessed by‘ relationship may exist between a Passive Structure concept and a Behaviour concept; and a ‘has assigned‘ relationship may exist between an Active Structure concept and a Behaviour concept.
[This provides the required direct backwards-compatibility with the current Archimate, though we may well need to be cautious about the specialisation of relationships here. From a Zachman perspective, note that this split is equivalent to ‘What’, ‘How’ and the capabilities-aspect of ‘Who’ – which leads us into the next point:]
It is strongly recommended that this split be extended to include three further specialisations or categories – Location, Agent and Decision – with an optional further extension to include Event. These would also map to the Zachman ‘Where’, agent-aspect of ‘Who’, ‘Why’ and ‘When’ respectively, to support full alignment with the Zachman taxonomy.
[I’ll admit I haven’t yet done the detailed work needed to identify all the relationships here, though some of them already exist in the Archimate canon – ‘triggers‘, for example, as an outgoing relation from Event.
One of the complications is that this isn’t a true ‘either/or’ split, because the closer we get to real-world implementation, the more we’re likely to come across entities that straddle two or more categories. In such cases, the entity-behaviour would be that it acts as an aggregation (composition?) of all of its component-categories.]
The entities would need to support sub-categories that identify other characteristics, such as in line with the schema in the following diagram. The ‘columns’ here correspond respectively to Passive Structure, including Agent (‘Asset’); Behaviour (‘Function’); Location; Active Structure (‘Capability’); Event; and Decision:
[The purpose of this is to break from of the IT-centrism that cripples the current Archimate. This schema enables us to cover the whole enterprise scope, without any arbitrary constraints.
The two groupings here relate to the ‘asset-type’, and the ‘decision/skill-type’. The asset-type distinctions identify fundamentally-distinct attributes of ‘things’: for example, a physical object is ‘alienable’ – if I give it to you, I no longer have it – whereas a virtual item such as data is ‘non-alienable’ – if I give it to you, I also still have it. Functions act on different asset-types; locations are defined in terms of schemas of the same categories of asset-types; and so on. Capabilities and decision-types relate to the level of complexity that the respective entities can address. (Note that a capability acts on asset-types with specific skill-levels – i.e. both groupings apply in that case.) These are, however, non-exclusive: a printed book, for example, is an object (Passive Structure, in Archimate terms) that is both a physical ‘thing’ and virtual information, and has to be managed in accordance with the nature of both asset-type categories.
Relationships across this schema will need further research, but one additional item that would often be required in an IT-oriented context would be a ‘represents‘ relation with other Passive Structure entities. For example, an information-item might have a ‘represents‘ relationship with a physical object (such as a parcel in a logistics context) or a real-person (as in a CRM or HRM system). (Note that this is not the same as the Representation entity: that’s External Passive Structure, not a relationship.)
Two further complications arise concerning the Agent category (of which the Archimate entity Actor is one example). Every Capability (or Active Structure, in Archimate terms – usually clustered into an individual Role or collective Collaboration) is enacted by an Agent. As implied in the permitted-relations discussed in the earlier review of Level 6, what Archimate describes as ‘Actor’ is actually treated as Passive Structure – not Active Structure. This is correct: the Active Structure is ultimately enacted by or embedded in some kind of ‘thing’, such as a Device or Application package. This is the actual non-IT-centric meaning of the Zachman ‘Who’: in the terms of the schema above, the Agent is or is represented by an Asset (i.e. Passive Structure). However, the human Actor represents a special-case, because real-people are not and should never be described as Assets: instead, the organisational and/or human relationship with that person is the asset in that context – the link to the person via a relational-Asset, not ‘person-as-asset’.]
Level 5b (‘Level 5’): Another either/or specialisation is applied to Extensional Concepts, splitting them into two categories: ‘external’ (e.g. Representation, Service, Interface), and ‘internal’ (e.g. Object, Function, Role).
[The idea of ‘external’ versus ‘internal’ is a good one, though it needs a better explanation and exploration in the light of the Level 5a extended-categorisation and schema above. For example, a Service is the outward expression of a Function (Archimate ‘Behaviour’) and a Capability (Archimate ‘Active Structure’, as Role).
However, the inconsistent mapping of internal versus external in Archimate’s Passive Structure does point to a real issue, that there are some cases where treating this as a true exclusive either/or split does not make sense. The real purpose of the split is to identify appropriate relationships, in particular ‘inbound’ versus ‘outbound’ relationships across set-boundaries, such as in the layered structure of Business / Application / Technology in current Archimate: an Internal entity accepts ‘inbound’ relations, and an External entity accepts ‘outbound’ relations. If we treat this split not as a strict either/or, but as an attribute which is normally either/or but may be both or neither (much as described for Level 5c below), then an entity which is ‘both’ may support both ‘inbound’ and ‘outbound’ relations.
Further exploration will be needed to establish appropriate relationship-types across the categories and between internal/external split, without drowning in special-cases.]
Level 5c (‘Level 6’): An attribute to distinguish individual versus collective entities may be applied, to select between (at least) four distinct conditions: ‘always Individual’, ‘always Collective’, ‘variable’, or ‘not relevant’. (The ‘not relevant’ case should be the default, and could probably be considered to be ‘implicit Individual’ for many/most modelling purposes.) The state of the attribute may affect the validity of certain relation-types such as ‘is aggregation of‘. Specialisations may be used to enforce the state of this attribute – e.g. Process as a collective of Service, or Collaboration as a collective of Role – but this is not a simple either/split.
[Further exploration will be needed to establish appropriate entities and relationship-types across the categories and between internal/external split without drowning in special-cases. Note that collectives may occur in any category: for a example, a Product may be a collective made up of many Components.]
Level 6: “This section intentionally left blank”.
[See the ‘//…//’ note above Level 4.]
Level 7: To retain compatibility with Archimate v1.0, three exclusive-sets (see Assertion 3, Rule G, above) are defined, labelled Business, Application, and Technology. The metamodel structure as described is replicated in each of these sets. An additional intersecting-set (again, see Rule G) is defined at the same time to incorporate all specialisation defined in each of those exclusive-sets, plus any additional elements required beyond those three exclusive-sets.
[This allows us to break out of the IT-centric box defined by the current Archimate, and enables what is, in effect, an infinitely-extensible architecture-space, to which we could apply further exclusive-sets and/or intersecting-sets as required.
Relationships between sets would typically use the ‘inbound’/’outbound’ structure as summarised for Level 5c – i.e. ‘inbound’ relations may only connect with Internal entities, and ‘outbound’ relations to External entities. This enables us to emulate the ‘layers’ concept in Archimate v1.0, without actually constraining always to that type of inter-set relationship.]
Level 8: Specific entities and relationships are defined for each of the sets, based on the underlying structure of the metamodel.
[Yes, in principle, this is exactly the same as in the earlier review. The difference is that it doesn’t force us into IT-centrism, and the rules in Assertion 3 above would apply: consistency and integrity of the metamodel is paramount, all special-cases must be described and defended, and so on. We are not allowed to permit the underlying metamodel to be all but ignored, as in some ways does appear to have been the case with the current Archimate.
I haven’t given point-for-point examples here: there are about 30 entities defined for Archimate 1.0, together with a dozen distinct relationship-types, hence describing exactly how each one of those would be mapped into this metamodel would probably take a post as long as this one again. But to me at least it’s clear how to support every one of the existing Archimate entities and relationships within the metamodel structure described above, without breaking any of the integrity-rules or creating any non-defensible special-cases. That structure also provides a better fit for what I’ve seen described as upcoming in Archimate v2.0 – particularly the positioning of the Location entity as a generic category, rather than as a single entity that is allowed to bounce around across the various layers. (Using Location as a category also resolves another special-case problem in the existing Technology layer, because Network and Node become re-flagged as the collective and individual of a particular type of virtual-Location.)]
So: that’s it for now. I’m well aware that this isn’t complete yet: for example, there is more work still to be done here on clarifying and simplifying the structure and connection-rules for inter-entity relationships. There’s also work to be done on support for dynamics and transitions, as mentioned in Assertion 2 earlier – though for transitions the ‘null-entity’ concept described in Assertion 3 Rule F should help a lot.
But I hope this is enough to get people started of rethinking and refining, such that we can end up with an Archimate that we actually can use for real enterprise-scope architectures.
Thanks very much for keeping going all the way through this marathon: hope it made some degree of sense, anyway. 🙂
Over to you – comments/suggestions, anyone?
Tom. OR … we can just keep using the TOGAF meta model. 🙂
A rich, finely-nuanced, detailed narrative which I was able to follow.
I’ll need to re-read a few times to pull it all together in my mind.
(Where’s Graham Berrisford?)
way too much here to comment on in detail. (But it did make sense)
I also have not liked the ‘smell’ of Archimate from the first time I encountered it. In my case I decided it engineer centric rather than IT centric.
I certainly choked on the arbitrary nature of the primitives – it was possible on the very first reading to think of a number of real world scenarios that Archimate would be impossible of expressing.
I think though, a major issue it the objective of ‘formal completeness’ that it aspires to. By formal completeness I mean a language that can be used to model all possible states of a system. (In this case states are entity relationship pairings.) This is to be expected when a bunch of software engineers and computer scientists sit down to write any kind of language.
The design failure is not the arbitrary choices you outlined but the assumption EA operates on formally closed systems. It doesn’t – and not even in relation to primary concepts in common use such as service, application, or process.
As I see it the real issue with Archimate is that is misconceives the world it is ostensibly designed to model. It conceives of the enterprise the way the chief architect of a large business application would like the enterprise to be.
That’s not a problem that would be fixed by the revisions you are proposing. They will just make Archimate models more convoluted and obscure.
The thing is I have seen Archimate used effectively in a number of scenarios – but always in the documentation of partial architectures. It also gets used rather loosely and few adhere to all the rules of syntax – If you use a free form Visio template you can put stuff anywhere you want.
It will end up a roughly understood language with enough formality to be useful for some things.
I’d rather leave it to ‘evolutionary’ forces to sort this out. Rather like the way BPEL supplanted BMN but not BPMN because the latter was just too elegant and downright useful for modelling and documenting complex process – particularly asynchronous ones.
Ric, I agree totally with your idea to leave it to the ‘evolutionary’ forces to sort this out. I would therefore like to see that The Open Group would create something like:
THE EA MODELING TEST – HOW WELL DOES YOUR METHOD SUPPORT ENTERPRISE ARCHITECTURE MODELING?
(idea borrowed from http://html5test.com/)
@Jon McLeod – Jon: I’ll agree that the TOGAF metamodel, although a bit thin, is probably adequate enough to describe basic IT-architectures.
But it’s actually worse than useless for anything else. Just as one really simple example: let’s say you have a record of a parcel, in a logistics context. In the TOGAF metamodel, you can say just about anything you need about that record of the parcel. But you have no way to describe the parcel itself. And because you have no way to describe the parcel, you have no way to describe the linkage (or lack of it) between the record of the parcel, and the real parcel. If there’s any mislinkage… well, that’s where a lot of your real-world business-problems arise, don’t they?
In short, you can use the TOGAF metamodel, or the current Archimate, to describe the imaginary world of IT. But it’s not very good – in fact very poor – at describing anything outside of that imaginary world. In other words, anything in the real world. The real world of business, in fact. And we then wonder why the wonders of TOGAF and current-Archimate and the like do almost nothing to reduce the dreaded ‘business/IT-divide’? – in fact do a really good job of helping to increase it? Oops…
I’m not ‘just being nasty’, as some people apparently seem to think; nor am I somehow ‘anti-IT’. Fact is that these are huge business-problems that the obsessive IT-centrism of the current ‘enterprise’-architecture industry is doing nothing to resolve – if anything, doing everything it can to avoid getting resolved. I’m trying to do something towards getting these problems resolved. Are you? And if not, why not? Might be worth taking a serious look at that question, perhaps?
Great piece Tom, I appreciate your scientific approach.
I specifically support your observation “As is usual in IT-centrism, the Business layer is clearly used as an arbitrary grab-bag for ‘anything not-IT’;”. However, my experience is that this is not limited to IT only. I have seen presentations from CFO using ‘Business’ as an arbitrary grab-bag for anything not-finance (thus including IT 😉
So I would be inclined to assert that ‘Business’ is used in many disciplines as an arbitrary grab-bag for anything not-my-discipline. Its just like the medieval drawing of maps where one’ country is the Center of the world.
I will ask my EA friends who, contrary to me, do model EA to read or even comment on this blog.
Thanks again Tom for all your effort to share your thoughts,
Ron van den Burg
Quite a lot to digest in one go and the damp towel fell off my forehead I’m afraid!
A lot of this seems to revolve around class hierarchies or taxonomy hierarchies which I think are an after-the fact issue. If you want ArchiMate to be able to represent more than just IT does it have the language (nouns = stereotypes and verbs = relationships) to be able to do so? This is independent of their arrangement in one or more hierarchies, classifiers or indeed layers as forms of organisation.
A quick look at the tech spec at the relationships table (the closest I could get to a metamodel on a single sheet) suggests that the stereotypes are predicated on IT. It is probably also essential to look at the taxonomy to see whether they types overlap (are sufficiently distinct). Having types with more than 1 word can be dangerous (the longer the string of words the greater the change that it embodies what should be 2 or more concepts and a relationship) e.g. ‘System Software’ which seems to include ‘system’ (a concept in its own right) and software. Having Some of the examples introduce things that probably should be concepts in ArchiMate e.g. competence.
I agree with Jon in that it doesn’t seem to contain much to describe what’s in the real world that you might see or touch. ArchiMate might, however, not be concerned with this if it’s remit is simply the software view of the world.
Whilst you can argue that generic concepts such as ‘artefact’ can cover a wide variety of things it also means you can’t differentiate between them (they’re all of a single artefact). This is where the tricky bit in balancing metamodel size vs resolution/differentiation comes in. If you leave this to users to create specialisations then exchange/interchange/consistency becomes a nightmare.
One of the problems from a systems perspective is that the spec immediately dives down into layers – there’s nothing obvious that provides the whole metamodel to enable a view of how it hangs together, error checking etc without diving down into each layer. If it’s too big to do so you then start to ask questions about complexity. Forcing a view of the whole thing on a single page is a good check to stop complexity running away.
Care is also needed on the section on architecture viewpoints as the examples provided aren’t ISO 42010 compliant. They provide ideas but they aren’t defined as the standard requires. Care also needs to be taken to phrase the concerns in a tangible way so that a check of viewpoint definition content wrt stereotypes and relationships can be made – a good check of both viewpoint definition and metamodel content wrt concepts and relationships.
From a local perspective ArchiMate couldn’t be used to represent a lot, if not most, views in TRAK, MODAF et al simply because as it stands in it’s vanilla state it doesn’t have the necessary concepts and having to specialise to do so defeats the point of an interchange standard. This doesn’t mean, however, that it’s no good only that the scope of the metamodel restricts what it can be used for. As with all these things you first identify the scope/concerns that need addressing, then choose a suitable architecture framework and then a suitable architecture description language (such as ArchiMate). At each stage you have to assess whether you can address what is needed i.e. does the framework have viewpoints that address the concerns, does the ADL contain the concepts/stereotypes to be able to represent those viewpoints etc.
I don’t think this will work. For starters is it the method, the framework, the metamodel, the view etc that is being assessed? Is it really the method that counts or the product of the method? Likely it’s the content and whether the content (of what – the view, the entire architecture description) conforms to presumably the framework (in reality the viewpoint definition(s)). The tools themselves can do this and it’s difficult to see given the debate about things like what EA is etc that there could be enough agreement to have a central spec of EA to form the basis for a test.
I think with some creativity it can work. A start could be that instead of focusing on the html5test example we can think about a kind of Enterprise’s Next Top Model show on the internet where a number of enterprise architects show how they solve a number of EA assignments. Even without a voting system the results should give an objective impression what EA is or can be and what the differences are between the different EA schools.
And inventing the EA assignments should be a fun community activity 🙂
@Ric Phillips (re comment #2 above)
Hi Ric – and yes, likewise had the same sinking-feeling when the very first thing I tried to describe in Archimate some years back – a logistics context – was impossible to model because the set of primitives available barely covered a third of the context. The problem was that we still needed something to model with: UML was a bad joke (at that time, anyway), BPMN was almost as IT-centric, the old tools such as IDEF0 were, well, old… – kinda stuck, really. 🙁 Hence the push to create something that actually works in the real world…
I take your point re formal modelling, though the automation-folks do need that level of formality. When I talked this through with Erik Proper a couple of years back, one of the key problem we found was that ‘classic’ (IT-style) modelling usually doesn’t bother to draw any distinction between binary-logic (true/false) and modal-logic (possibility and probability): if a link is possible, it therefore sort-of ‘exists’, which the IT-folks then seem to think means that it always exists – which ain’t true. Most knowledge-work runs on modal-logic – in fact that’s why it’s knowledge-work, because it takes knowledge and skill to disentangle the modal-logic enough to make viable decisions.
Creating a modelling-framework to support full business-style modal-logic would be the ideal – ORM can support a modal-logic, for example – but the blunt reality is that no-one would use it, because it’s way too abstract for most people’s taste. The other way to do it is with story: use models as an anchor for narrative-enquiry that gently elicits all the ifs and buts and special-cases and the probabilities and contexts in which they arise (aka modal-logic). We typically develop a model on the whiteboard or wherever that looks like formal-modelling but in reality is much more free-form – much as you described in your comment. The essential part of this ‘modelling’ is actually the process of discovery, the development of the shared-narrative: the ‘model’ itself is little more than an aide-memoire, a kind of abstract record like the photos you take on vacation that show those ‘special moments’ but may not make much sense to anyone else if they weren’t there. The problem then comes that someone misinterprets that freeform ‘model’ as a concrete description of what actually happens in that real-world context – and tries to build an automated system to do the same task. And then wonders why it doesn’t work.
But as you say, we can’t even get to the ‘freeform model’ stage unless we have a primitives-set that does cover the whole context, even if only in the most rudimentary way. We also need that primitives-set to have some kind of structure behind it, so that we don’t have to explain everything to everyone every time. In other words, some kind of metamodel and glossary/thesaurus that can at least clarify what we mean by various key terms: vision versus mission versus role versus task, for example, or process versus function versus service versus capability. Hence why all this discussion of models and metamodels?
But thanks again, anyway – hope this makes some degree of sense?
@Peter Bakker (Comment #3) (also Nic and Peter again in Comment #7 and #8)
Yes, likewise agree with both you and Ric re ‘evolutionary forces’: I’m just tryin’ to give those ‘evolutionary forces’ a bit of a kick along my preferred path, is all… 🙂
On the ‘EA Modelling Test’: uh, yes, nice idea, but Open Group are definitely not the right people to ask to do it. They’re very good at what they do, yet they’re an IT standards-body, not a business standards-body: asking them to do something that by definition is outside of their field of expertise is not exactly fair – and even less fair if we then complain at them for ‘getting it wrong’. (We can and should yell at them if they claim that it’s their field of expertise when clearly it isn’t, but that’s a different point.) Hence the only ‘EA Modelling Test’ that Open Group would be likely to produce is likely to be something that’s inherently IT-centric – which is fair enough, given the context, but it won’t actually do the job that we need here.
Yes, there’s a real need for a formal-standard EA Modelling Test: but we need it to cover not just enterprise-IT-architecture, but the full scope of enterprise-architecture – much of which, as Open Group are now more openly willing to admit, is well outside of an IT-oriented scope. So we do need to stop pestering Open Group on this, and look elsewhere. Where an appropriate ‘elsewhere’ would be, I admit I still don’t have much of an idea… suggestions for a suitable standards-body, anyone?
You are right. But I think there is no need to wait for a standards-body to develop a EA Modeling Test. Why not make it a community effort?
@Ron van den Burg (Comment #5)
Hi Ron – yes, strongly agree that the problem of ‘self-centrism’ is not specific solely to IT! We do experience IT-centrism a lot in enterprise-architecture, because IT-folks do still so often dominate the field – but it isn’t the only source of that problem.
The real problem is that whenever any domain dominates (or attempts to dominate) the architecture, by definition we’ll soon cease to have an enterprise-capable architecture. That’s why I keep hammering away at that one point: in a true enterprise-architecture, everywhere and nowhere is ‘the centre’, all at the same time.
@Nic Plum (Comment #6)
Hi Nic – really appreciate your TRAK perspective here. 🙂
Yeah, I know – the usual Tom-stuff: way too complicated, way too Archimate-specific in this case. Apologies… But then I did ‘advertise’ it as being a rethink of the anatomy of Archimate, after all…?
What I’m actually searching for is some kind of sharable notation that we can use for whole-enterprise architectures. I started from Archimate, because that’s what people know. Myself, I don’t know of any equivalent that properly covers the DoDAF/MoDAF/TRAK space anyway – and I’m well aware that there’s a lot I need to learn from you on that. (Please? 🙂 ) But let’s not lose sight of that aim: some means, preferably in visual form, to exchange ideas and experiences and understandings across any type of ‘enterprise-architecture’ context.
I believe we do need to go down to the metamodel layer (or more accurately, the metametamodel layer at least, and probably deeper than that), to provide the anchors for that shared means of storytelling. It also needs a solid base for the way in which it does its glossary and thesaurus and cross-context ‘translation’ – something(s) I’ve hardly touched on yet, but also absolutely essential. Discuss in more detail somewhen, perhaps?
Interesting read. Your main objections to the current Archimate seem to the arbitrary limitations of the language so that it is unable to capture the full Enterprise Architecture field. My feeling is that it is probably an idle hope to expect that you can get away with anything less than natural language to describe a thing as complex and diverse as an Enterprise in all its levels of being and becoming….
So, one may set different limitations in the formal language but it will never be complete. Or when it is, will be unusable because it has lost all focus and precision…. This is a well known fundamental tension in any (formal) language: expression power comes at the cost of loss of precision… If you can express all the intricate subtleties of Goals and Requirements, your language is so rich that you might as well write poetry in it….
@Michiel Perdeck – Hi Michiel – not quite, though I do see your point.
My practical objection is not so much that Archimate “is unable to capture the full [EA] field” as that it captures such a tiny proportion of the field (which it then presents as if it’s the whole field) that it is only slightly better than useless in real-world EA practice.
My theoretical objection is that the Archimate metamodel is – I’ll have to be blunt about this – let’s just say “not good”. As it stands at present, it is so laden with internal contradictions that it’s doubtfully ‘fit for purpose’ even for a narrow IT-centrism. Rather than a proper consistent metamodel, we’re left with something that has only slightly more structure than a random collection of entities with largely-arbitrary relationships – in other words, it is sort-of better than most of the ‘EA metamodels’ currently on offer, but not by much. As I’ve described above, it’s way too inconsistent and fragile to be able to use it to extend and/or fill in the gaps to make a metamodel that does properly cover a more viable scope of the EA field.
I’m not arguing for 100% coverage: that’s never going to be achievable. Even 50% would be nice. I’d even settle for 20%, if that 20% was generic enough to be useful. But what we have at present in Archimate and elsewhere covers perhaps no more than 3-5% of the whole in most organisations. That figure might perhaps rise to 10% or so for information-centric organisations such as tax, banking and insurance, but it’s still not usable for enterprise-architecture. It’s possible to sort-of use it for sort-of some bits and pieces of EA if you sort-of pretend that the only thing could ever matter to an organisation is how it sets out its IT-infrastructure. But not much more than that – which is kind of sad, really. All I’ve been asking here is that we drop the pretence, and develop something that does cover a more realistic proportion of the enterprise scope – and with an underlying metamodel that is robust enough to allow us to extend in any appropriate direction that we need.
We don’t need it to “express all the intricate subtleties of Goals and Requirements”, because we already have good enough tools for that – Mike Walker’s Extended Business Motivation Model, for example, as referenced above. What we do need is enough of a metamodel to be able to provide ‘hooks’ into those spaces, as required. The current Archimate can’t do that – but by reverting to its original pre-mangled structure, it might well be able to do that, as I’ve described above.
And as for “your language is so rich that you might as well write poetry in it” – well, why not? We’s gotta has some fun in EA work, ain’t we? 🙂
Tom, thanks for your reply to my reaction. So your aim is rather modest, just an improvement of the metamodel so that it will capture more of the EA field. I do hope that this will be possible. One of the issues I always have when using Archimate is that the choice as to use which Archimate construct for a particular real world concept is often more or less arbitrary and requires one to adopt a standard in the project at hand. This in itself is not bad, compare this with coding standards or style-guidelines for writing. However, I fear that this problem may aggravate (get worse) when the language gets more versatile and less restricted. I fear that the interpretation of a model will be even less unambiguous then. But maybe I’m wrong and maybe it will be possible to create an EA language that is both expressive and unambiguous enough for the purpose. I remain very sceptical although certain improvements will no doubt be possible.
Then one more point: as for the IT centrism of Archimate, I think this has been one of its design decisions from the beginning. It was, in my view, never created to design e.g. a logistics infrastructure or a social organisation. It was created to design IT systems that support the enterprise. So it is an Enterprise IT Architecture language. Mark Lankhorst should be able to shed some light on this issue.
@Michiel Perdeck – Thanks, Michael.
On your first point, it is possible to create a language that is both structurally-simple and versatile-enough to be fully-expressive. Southbeach is one example that a lot of consultants use, though it fits a somewhat different context to Archimate modelling. The point is that a well-structured metamodel can give us that richness, if it allows us to anchor everything back to close to the root-level. That’s a large part of what this review was about. Perhaps also take a look at my work on Enterprise Canvas: the reference-sheet is here, and at present you can still download the whole book “Mapping The Enterprise” for free from here, too.
I’m well aware that the initial clients/sponsors for Archimate were IT-oriented information-centric organisations (the key players were a bank, an insurance company and the tax-department). But as pretty much everyone in EA is at last discovering, you can’t make even the IT work without taking solid grasp of the real-world context – and for IT-infrastructure that includes not just the business-side of ‘business-architecture’, but also some serious concerns such as security, sustainability/Green-IT and business-continuity / disaster-recovery, all of which extend out into the physical and human space. In short, you can’t even make an IT-architecture work with a ‘classic’ IT-centric view. To deal with that fact, you have to create a framework that, as it happens, will also handle “a logistics infrastructure or a social organisation”, because they’re actually the same thing. 🙂
And yes, it was “created to design IT systems that support the enterprise”. Agreed, that was the ‘enterprise’-architecture of a decade ago. It isn’t the enterprise-architecture of the present day. I was exploring how to get Archimate to align with the enterprise-architecture of the present day – a fairly straightforward and fairly obvious requirement, I would have thought? The aim, among other things, was the explore the underlying metamodel to see if it could be tweaked a bit to cover the required broader scope.
And Marc Lankhorst did “shed some light on this issue”: as a follow-up to our back-and-forth in the comments section on a previous post here, he very kindly and personally sent me the PDF-file of the ‘Anatomy of Archimate’ document, that I pulled apart in this review. I also drew on notes from personal discussions I’ve had with most of the Archimate crew over the years, such as Erik Proper (who helped me a lot on ORM and modal-logic) and Danny Greefhorst and Harmen van den Berg. And I would have thought that was fairly clear from the way I introduced this post. Hence apologies, but I’m left kind of wondering if I’ve completely missed your point here? – because this review is already a detailed, precise, fully-documented answer to the questions you seem to be posing here… sorry, but I will admit I’m a bit confused on this. Enlighten me, if you would? – thanks.
I know I’m dim and don’t do this for a living but I don’t see that a metamodel and natural language are mutually exclusive. What I’ve tried to do with TRAK is to concentrate on tuples, not entities, so that you end up with strings of what look like sentences. This coupled with requiring everything be explicitly labelled gets away from softie notation so that it’s relatively easy to read. You can define a metamodel using whatever you like – it’s only the implementation in someone else’s language that forces you to use their constructs (if that makes sense). This happened in MODAF where THE M3 (MODAF metamodel) got defined using UML with the result that it’s a lot larger and complex that that if you’d just used visual shapes, lines and english. As with any design you need to separate intent the logical) from the solution or realisation of this. The danger is otherwise that you inherit the limitations – one of the reasons for declaring the suitability of any mapping from AF to ISO 42010 or from Architecture Description Language (e.g. UML, ArchiMate) to an AF. Does this make sense?
Whoah, that’s a lot to digest (damp towel required here as well…) I can’t really judge the consequences of all that you’re suggesting. I do think that your main objection, the admittedly limited scope of ArchiMate (basically the operational aspects of information-centric organizations), has a lot to do with the expanding use of the notion of EA. When we designed the language (2002-2004), the most pressing need was for a unified language to capture how such information- and IT-centric organizations function in this operational sense, i.e., what their business processes, applications, infrastructure elements etc. are doing and how these are related. So in essence, ArchiMate could perhaps best be characterized as an enterprise-wide information architecture language (but not just IT architecture).
Nowadays, we see that EA is (starting to be) used in conjunction with strategic planning, business models, networked enterprises etc. Whether e.g. your business model is or should be part of your EA is debatable; I am completely in favour of such an integrated approach, but I don’t know whether we should call this “architecture” (for various reasons). Gradually, we see that ArchiMate is expanding its reach as well, viz. the forthcoming version 2.0.
The problem has always been the balance between scope/expressive power and simplicity of the language. We intentionally focused on the latter, whereas most languages try to be as expressive as possible. but the more you want to do with it, the more complicated it becomes (look at UML…) For example, I agree with the remarks about modal logic, but the average language user wouldn’t know how to deal with that if we would have put that in ArchiMate (that is also one of the reasons the language does not have a type-instance distinction).
And please remember that ArchiMate was never designed to be a very formal modelling language, but rather as “semi-formal”: it should provide architects and designers with a tool to create approximate overviews of architecture landscapes as a means of communication, not to provide detailed, formally correct specifications. The Anatomy paper may be a bit misleading in that sense, since it piles a lot of formality on top of something fairly informal.
Of course, looking back now we would have designed some things differently if we knew then what we know now, but we wouldn’t have gained that experience without ArchiMate in the first place. That chicken-and-egg problem, combined with the need for backwards compatibility, limits what we can do now.
I think improvements based on feedback from practical experience of the user community is now more important than improving the internal structure of the language, which the users will never see. But I’d like to see what the resulting metamodel would be if you would apply everything you’ve suggested.
@Marc Lankhorst – Mark, my apologies for taking so long to reply, and many thanks to you for joining in with this in (yet again) such a statesmanlike manner. I fully admit I’ve been a bit (too?) harsh, but I really hope it hasn’t come over as personal, because that wasn’t the intent at all.
If Archimate was only a tool for information-systems architecture, and only for use in parallel with something strictly IT-oriented such as TOGAF, it probably work as-is. The ‘architecture layers’ concept is actually an arbitrary constraint, but it does help it to align with TOGAF and other common IT-oriented frameworks, which assume the same metaphor. That kind of structure wouldn’t actually need the metamodel behind it: it could just be a collection of entities and relationships, and leave it at that. It would be hard to make it extensible, and the relationship-mappings would have to grow exponentially (factorially?) with each new entity, but it would sort-of work for a while.
That was okay for 2003/4, and in a sense the underlying metamodel was almost overkill for that purpose. But as you say, the problem is that EA has moved on since then – as it always would have done, once we stop to think about what architecture actually involves in the systemic context of real-world practice – and a simple information-specific model is no longer enough. That’s why TOGAF is struggling (and why TOGAF9, sadly, was a serious missed-opportunity), and why Archimate 2.0 needs many more entities, which you’re adding now.
But the problem is that for that expansion to work, it now needs a solid metamodel behind it. Unfortunately, as I hope is clear from my analysis above, we would have to admit that the current structure – which you wrote about in 2010 but I presume is largely unchanged from the 2003 original? – really isn’t robust enough for the job. For a start, to be usable, it must break free from the ‘layers’ metaphor, otherwise there’s no viable way to do end-to-end modelling of hybrid processes (mixed IT/manual/machine). Which, given that TOGAF et al do still hold onto the ‘layers’ metaphor, means that it’ll need some way to simulate the layers without actually being constrained to them. That’s part of what I was trying to tackle above.
One of the reasons I’ve been ranting about formal rigour inmetamodels is that we need some kind of equivalent of UML at least, that enables us to port models from one toolset to another, and link the models cleanly to other domains such as BPMN/BPEL, UML itself, and probably Business Model Canvas and the like. We can’t do that unless we have a consistent structure that allows ‘translation’ between all of the different ‘uses’ for each type of entity and/or relationship.
I do believe that there’s a way to do it that conceals the underlying complexity, and I’ll aim to describe that in posts here over the next few days. I’d really appreciate your feedback on that? – and it would also give you a chance to get your own back for my perhaps over-harsh critique of Archimate, too. 🙂
Many thanks again, anyway – much appreciated.