Why Archimate?

Archimate aims to be the standard notation for all enterprise-architecture work, bridging an important gap between free-form whiteboard-style sketches and detail-layer executable models.

The catch is that it all depends on what’s meant by the term ‘enterprise-architecture’… which is not a trivial point, as Len Fehskens explained on the Open Group blog early last year, in his seminal post ‘Enterprise Architecture’s Quest for its Identity‘.

The short answer is that version 1.0 of Archimate was a very good fit for what Fehskens describes as ‘EITA’ – enterprise IT-architecture. It was not a good fit for whole-enterprise architecture – a literal ‘architecture of the enterprise’ – because in essence everything in Archimate 1.0 centred around IT, and it had no real means to describe anything that did not in some way directly impact upon IT.

For a logistics context, for example, we could model how information about a package would move through the system, but not the physical package itself: so there was no real way describe any of the scenarios by which the parcel and the record of that parcel might become misaligned – or, perhaps more importantly, become realigned. (In the real world, that kind of misalignment still happens way too often for anyone to be comfortable or complacent about it – as can be seen in so many Twitter-complaints with the ‘#fail’ hashtag. It’s a very real business-problem – and usually a problem that is rooted somewhere deep within the architecture of the enterprise. Which is why it is our problem.)

There were also several key items that were missing from the Archimate metamodel that were going to be needed by anyone aiming to bridge the infamous business/IT-divide – particularly about motivation. (There’d been some coverage of that in the earlier versions of Archimate, but were dropped in the 1.0 release, perhaps to improve its alignment with the TOGAF 9 metamodel.)

The underlying anatomy of Archimate is also somewhat problematic. As I explained somewhen mid last year in a long post, ‘Unravelling the anatomy of Archimate‘, to me there are what seem to be several fundamental flaws in the structure of its metametamodel that actively constrain its use to an IT-oriented view of enterprise-architecture. And there seems to be no easy way to resolve those flaws without going a long way down into the internals and starting again. The surface-layer can look much the same – and certainly remain backwards-compatible – but the internals would need to be very different to make Archimate usable for the kind of business-oriented enterprise-architecture that so many more EAs are moving towards now.

So when I first found out about the revision for this new version, my attitude was ‘high hopes but not high expectations’. And that’s pretty much what’s happened – except that there’ve been some been very useful additions, some of them in places that I didn’t expect.

So for those of us working in whole-enterprise architectures, there’s good-news, and there’s bad-news. And there’s quite a lot of good-news, and nothing in the bad-news that we wouldn’t have expected, so let’s get the latter out of the way first.

Bad-news: there’s no fundamental move away from IT-centrism

The bad-news it that we’re still stuck with the same inane IT-centrism as before – right from the very first sentence of the specification:

An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization. … Architecture descriptions are formal descriptions of an information system, organized in a way that supports reasoning about the structural and behavioral properties of the system and its evolution.

There’s a lot more to any enterprise than just its IT-based information-systems, but in essence that’s all that this new version of Archimate would allow us to handle. And that annoyingly-arbitrary constraint is carried through into the same old pseudo-layering of Business, Application and [IT] Technology, in which ‘Business Layer’ is a similarly arbitrary and annoyingly-incomplete placeholder for ‘anything not-IT that might affect IT’. Not only absurd, but now seriously out-of-date for current EA practice – as even Open Group would freely admit, given the nominal focus of many of the presentations at the San Francisco conference and elsewhere

Sigh.

And they’ve used the same ‘plug-in’ concept for all the new add-ons as in the TOGAF 9 metamodel – which is a nice idea, but there’s nothing to support it in the existing Archimate metametamodel. So the result is that the underlying architecture has become yet more fragmented – which is going to make it even harder to do the fundamental rework of the architecture that must be done it’s to be usable forward into the future.

Oh well.

But that’s about the sum-total of the bad-news, and none of it was unexpected, so let’s move on to what is good in the new release.

Good-news: the Motivation extension

This wasn’t unexpected, but it’s still very good news: we can now link any architectural-entity explicitly to the reasons why it exists, and in a manner that allows for formal rigour between all of those interrelationships, roughly in line with the Business Motivation Model (BMM). The new entities are a subset of the BMM, but still eminently usable:

• Stakeholder
• Driver
• Assessment
• Goal
• Requirement
• Constraint
• Principle

In the Business layer we can link these to the existing entities for Value and Meaning, to create a (mostly)-complete trail of derivation for business-purpose. No equivalents in the other two layers, but it probably doesn’t matter as long as entities there are linked up into the Business layer, either direct or via the new Motivation entities.

The only thing that’s bizarre about this is the whole idea of treating motivation as an ‘extension’, rather than core. To use Simon Sinek’s term, surely we should always ’start with why‘?

Good-news: the Implementation & Migration extension

This one’s likewise very good news, and I wasn’t expecting it at all. This gives us a means to model the dynamics of an architecture – the way in which the architecture itself undergoes change. Again the new entities here are only a subset of what we really need for this, but they’re certainly enough with which to get started:

• Work-Package
• Deliverable
• Plateau (for example, an ‘intermediate state’ at some predefined time-horizon)
• Gap

It does make sense to describe this as an ‘extension’, because we don’t need it to describe a particular configuration or ‘state’ of an architecture – though we do need it whenever the architecture is to change.

The really good-news about this is that it provides a nice graphic workaround for the fact that almost none of the existing toolsets handle architecture-dynamics in any useful way. And if the toolset-vendor implements the appropriate ‘hooks’, this would also provide a solid anchor-point for cross-links into project-management tools and the like. Nice.

Good-news: the Location entity, and other minor amendments

A Location entity had been included in the earliest iterations of Archimate, but for some unfathomable reason it was dropped long before the Version 1.0 release; it now makes a very welcome and very necessary return.

A glance at Zachman should give the reason why it’s so important: without it, we have no means to describe the ‘where‘ of the architecture, whether in virtual, physical or any other form.

The Location entity is arbitrarily placed in the Business layer – which makes no sense, of course, because location should apply to everything, but it’s probably the only way that it can be handled within that absurd IT-oriented ‘layering’. Despite that placement, it is allowed to connect with every other entity, mostly via ‘assignment’ or ‘association’ relationships.

The other oddity is that there’s no explicit distinctions between types of location – particularly virtual versus physical, which is extremely important even in IT-architecture. No doubt this can be handled within toolsets via attributes, but it is a distinction that needs to be addressed.

There are a few other clean-ups down in the Technology layer, mostly new types of IT-specific relationships for newer technologies. To me the most significant item is Infrastructure Function – significant mainly because its stated purpose is to reinstate some much-needed structural symmetry in the underlying metametamodel for Archimate.

What next?

The specification ends with a ‘Future Directions’ chapter, which summarises some ideas about what could be added in future. Which is all fine: except they still don’t include anything that would make it more usable for the non-IT aspects of enterprise-architecture.

At the very least, if Archimate is to be usable for what it purports to do, we need it to be able to cover the symmetric equivalents of Application and Technology in the non-IT space – and not try to dump it all into ‘Business’, where most of it does not belong. The core partitionings that we need in an architecture are:

• role-type – passive-structure, behaviour and active-structure
• asset-type – physical-object, virtual-information, human-relation
• agent-type – physical-machine, IT-system and/or human-process

Role-type is the nominal core of current Archimate. But asset-types are in effect conflated into and scrambled within Technology, Application and Business layers respectively; and the only agent-type fully acknowledged is IT-system, with the others either ignored (physical-machine) and/or arbitrarily shunted into the Business ‘layer’ (human-process). This makes it all but impossible, for example, to use Archimate to describe business-process redesign or process-fallback where the existing or alternate implementation-methods would use machines or manual-processes; it makes it impossible to describe a business-continuity plan for a context where the IT is out of action; it still leaves it impossible to describe that logistics paralleling-problem between physical parcel versus information about the parcel. This are real needs in any viable enterprise-architecture, and we need a notation that can cover them. Hence, if Archimate is to be the notation of choice for EA, it needs to address these concerns: there is simply no other option.

From assorted snippets of conversation with various colleagues I know that such concerns are being explored in the discussions for the next version of TOGAF, currently code-named ‘TOGAF Next’. So if Archimate is to keep aligned with TOGAF, any putative ‘Archimate Next’ would have to follow suit. So I do still have high hopes for something useful and usable happening there; is it too unreasonable this time to have high expectations as well?

To be honest, we don’t need much help in thinking about the nature of enterprise-architecture or the like: that’s already well covered, and it’s actually quite straightforward anyway.

Where we need help is in rethinking the toolsets that we use for enterprise-architecture and the like.

To me it’s clear that if we’re to make sense of the enterprise, and support viable decision-making about the true whole-enterprise-scope within which our organisations operate, we’re going to need some kind of holographic approach to modelling.

We already have plenty of frameworks for enterprise-architecture. We also have plenty of methodologies to work with those frameworks. Each of those is constrained to some variously narrow view into this holographic space, and usually constrained by placing some particular point as ‘the centre’ – hence IT-centrism, business-centrism, health-and-safety-centrism and so on. And those constraints are useful in practice: no doubts whatsoever about that. So to my mind there’s nothing whatsoever that’s inherently ‘wrong’ about any of those frameworks or methods, other than their own occasional internal inconsistencies and than that they too-often position their own very limited perspective on reality as ‘the only possible’ view on reality. That’s the only problem there, and it’s very easy to fix, by acknowledging the value of a single viewpoint as a viewpoint yet also insisting on cross-viewpoint generics. We can choose anywhere as ‘the centre’, for some given purpose, yet must also insist that everywhere and nowhere is ‘the centre’, all at the same time.

Hence, as such, we don’t need any new frameworks or methodologies for enterprise-architecture. We have more than enough of them already, to be honest.

What we do need are better ways to manage and make sense of the information we have about this ‘enterprise-hologram’.

Which is where toolsets come into the picture. And that‘s the part that I really need help on – or we need help on, rather, because it’s definitely too large a context for any one person, or even any one group, to tackle on their own.

What we need most is clarity on the question we’re aiming to address. I think it’s an Einstein quote that says “if I had an hour to solve a problem, I would spend the first fifty-nine of those minutes on the question, and only the last minute on the answer” – because the right answer tends to fall out all by itself when we have clarity on the question.

One thing we do know, though, is that there are many different players all trying to tackle different aspects of the same enterprise-holograph – for example:

• enterprise-architecture and all the other domain-architectures and solution-architectures – an emphasis on structure and purpose, and how they link together to deliver useful value
• knowledge-management – an emphasis on how knowledge-items link together (especially narrative-knowledge, stories and ‘subjective truth’)
• change-management – how everything changes and can be changed over time
• process-management – how activities link together, and entities flow between them, to add value across supply-chains, value-networks and so on
• service-management – the human and technical aspects of keeping everything going and ‘on purpose’
• futures and other business-intelligence – how to trawl through the enterprise-space for sensemaking and the like
• simulation, ‘gamification’ and other skills-development – how to apply ‘what-if’ to any part of the overall context
• skills-management – identifying the skills needed, and the training and/or recruiting needed to cover present or future gaps
• performance-management – identifying required metrics and their impacts (especially, to avoid ‘gaming the system’)
• governance – identifying requirements and responsibilities, assuring assignment and ability to comply, and verifying compliance

In principle, yes, they’re all views or viewpoints into the same overall context. Yet each of those views also carries information or requirements that are specific to that view alone – in other words, more like an orthogonal dimension. And there are a lot of those distinct dimensions in there – an n-dimensional space, where n could literally be any number. (Certainly a lot more than are accessible in the simple flat images so typical of so many current ‘EA’-toolsets, anyway.)

Then there are all the different uses for all those distinct views: an architectural view shows us relationships between structure and purpose, for example, but do we need that view to decide on future strategy, to plan investment, to compare different implementation-options in trade-off analysis, to guide scenarios and substitutions in planning business-continuity and disaster-recovery? The views we’d use might at first seem similar, but the focus and emphasis and model-dynamics in each case might be very different.

At first glance this all might seem impossibly huge. Yet it’s not as hard as it seems. Most of the technology we’d need to deal with all of this complexity does already exist. Despite the huge spread of the overall toolset-ecosystem, most of the key software components we’d need are already easily available, at little or no direct cost, running on a wide-range of easily-available existing devices. Conceptually speaking, the underlying data-structures are straightforward enough: for example, it could be done with little more than freeform tagging in an object-database of some kind, with some kind of filters applied to the tagging. The same applies to search, and filtering: pretty much everything we need already exists somewhere, if we knew where to look. And even if display-technologies are not yet quite capable of showing a true n-dimensional holographic space, they’re certainly capable of simulating one. Given the right people and the right ideas, the technology side really isn’t all that hard these days.

But if the technology isn’t hard, the user-experience part is hard. And seems to me that that’s where we most need to focus our attention at the moment.

In many cases, we simply don’t have the right metaphors for model-relationships:

• some of it can be usefully described as a matrix – but it’s definitely more than a simple matrix as per Zachman
• there are some contexts in which a metaphor of hierarchical layers will sort-of make sense – but it’s definitely more than a simple ‘stack’ as per TOGAF or Archimate, or even a multi-axis matrix-stack as per CapGemini IAF
• there are flows of information and materials – yet it’s much more than a simple supply-chain
• there are identifiable relationships, including realisation, aggregation and so on – yet much of it tends to follow a modal logic of possibility rather than solely a simple true/false logic of presence or absence
• there are identifiable trails of derivation and decomposition – yet there’s more to it than a simple Zachman layering, or the classic ‘current state’ versus ‘future state’

And perhaps more important, we don’t yet have adequate user-interface metaphors:

• drag-and-drop for entities can be misleading – is it a class or an instance? how do we link back an instance back to a parent class? are we editing the instance only, or the whole class? are we affecting other instances elsewhere? or other versions of the same nominal instance? what happens if the parent disappears over time, but the instance continues as re-linked to something else?
• notations can be confusing – especially where the same nominal entity would appear in multiple views with different notations or visualisations or images
• aggregation (as in Zachman primitives versus composites, TOGAF ABBs versus SBBs [Architectural Building Blocks versus Solution Building Blocks]) can be very confusing – especially where entities can recombine in many different forms, and at different levels of abstraction or realisation
• zooming (as per Prezi) works well to describe a ‘containment’ or hierarchical concept of structural-decomposition – but it’s hard to make sense, if entities aren’t fully ‘contained’, or if there are more than two orthogonal axes
• timelines (as in Gantt-chart relationships, or Apple OS-X Time Machine backup/restore) provide a good means to step through time-related views – yet the views themselves may change over time
• multi-axis user-controls work well for up to three or four exactly-orthogonal dimensions – but become exponentially harder to use with increasing numbers of dimensions and other variables, and probably cannot cope when the dimensions themselves blur into each other

In short, we urgently need new user-interface metaphors to navigate through n-dimensional holographic space, where the nature of the space itself may change as we go.

(Oh, and it has to be easy to use, too, such that both the navigation and what’s visible in the view will make immediate sense to anyone. Of course.)

To use another Einstein quote, “Everything must be made as simple as possible, but not more simple”. Simple to use; yet actively dissuade overly-simplistic ‘solutions’ such as IT-centrism and the like.

That’s the challenge.

And that’s also where Agile and the like come into the picture – and, most of all, people who are experienced in Agile-style software-development for toolsets and the like. We seem to have quite a lot of methodologists and the like around here, who tend to be great on the theory. But what we need most are developers who know how to think seriously-sideways and put it into practice.

We can’t just talk it into existence: we need to get past the ‘talking about it’ stage now. Given the blunt fact that we’re very unlikely to get it right first time, we need something to play with, to test in real-world practice, to review and rethink our ideas, to help us clarify what the question really is that we’re facing here.

More thinking-about-thinking, about the theory and the like, well, yes, we’re always going to need it, it’s always going to be a ‘nice to have’, and so on. But right now, we’ve done more than enough thinking-about-thinking: it’s time to get down to the doing, of creating this new kind of toolset.

Anyone interested in helping with that? Please?

“Oh no, not again“, do I hear you cry? Actually, it’s not as bad as that: it’s not going to be yet another of those long tedious technical posts – honest!

(It is a sort-of technical question, I’ll admit. And, in the event, quite long. But interesting to just about everyone, I hope.)

What do we mean by ‘Why’? It’s a question that’s been puzzling me for quite a while – not least because enterprise-architecture is in some ways all about the shared ‘why‘ of an enterprise, and how we express that ‘Why’ in practice.

That kind of ‘Why’ is energising, and engaging. “Start with Why“, says Simon Sinek – and in terms of how things really happen in enterprise, he’s right. If we start with why, things do indeed happen, and usually happen well.

But then I look at the ‘Why’ column in Zachman: ‘Why’ is business-rules, it says. Gosh. Wow. Exciting… (To be honest, my heart just sinks. Doesn’t yours?) Business-rules? – seriously, where’s the fun in that? Kind of the exact opposite of engaging, really. Something’s gone missing there, clearly…

That’s not quite fair, of course. Up at the top, Zachman describes ‘Why’ as a list of Goals. Not quite as unexciting as business-rules. (But close…) Yet there’s something kinda odd here… kinda like a sudden sideways jump… different things all mixed up together in the same space…?

And I hit up against the same problem when working on the Enterprise Canvas concept, a year or so ago. The same Start with Why: the ‘vision’ for the extended-enterprise is the core ‘Why’ from which everything else flows. That ‘Why’ is emotive, it means something: for the right kind of ‘Why’, people are willing, even eager, to get out of bed way too early on a cold dark dreary workday morning. It matters. It sits above everything else. And yet, to make sense of the content and activities of the service that we’d represent on an Enterprise Canvas module, there’s that same dull boring ‘Why’ again: decisions, principles, rules and regulations, all that kind of stuff. Where’s the fun gone? How come we’ve lost the why from the Why?

I’ve been bouncing up against an answer on this in several previous posts over the past while, such as one about principles in enterprise-architecture, and another on the relationship between architecture, design and implementation. But perhaps a better answer came up over the past couple of days, when trying to unravel the anatomy of Archimate and, in particular, struggling to make sense of the split between what in Archimate they call Intentional Concepts versus Extensional Concepts.

Intentional Concepts are, as the name suggests, about intent. Extensional Concepts are about what we do with that intent – about how we extend that intent out into real-world practice. In Archimate, Intentional Concepts are entities such as Value, Meaning and Reason. And the important point is that these are viewed as separate from ‘the action’. Yet down in the details of that ‘the action’, we again come across another kind of ‘reasons’ – all those business-rules and so on. (Archimate doesn’t model any of that as yet, but that’s another story.) So again we’ve got this kind of sideways jump: ‘Why’ is above everything, as Intent; yet it’s also just another part of that ‘everything’, as Extension, the ways things work together.

The obvious answer: we’re dealing with two different kinds of ‘Why’. Or two different sides of the same ‘Why’, perhaps.

One side of Why creates a question: literally, it starts a ’quest’. For most of us, that’s the exciting bit.

The other side of Why is the answer to the question, the end of the quest. That was the question, here’s the answer: The Decision. End of story. For most of us, that’s when the fun ends: a sense of relief, perhaps, that there’s no more need to quest, but also, well, no more need to quest… Final. That’s it. Full Stop. (or Period, if you speak the US version of English). An ending, that somehow ends up in a bunch of rules, with No Questions Allowed any more. A Why To End All Whys.

Kind of like the braces round a mathematical function: a=func(x,y) and all that. The opening-brace ( begins the question: what’s x? what’s y? what do we do with them? – exciting, new, gosh, wow! And then we hit the closing-brace ) that ends the question: its kind of ‘nothing more to say’, really. We have the answer, the decision. Nothing more to do. Oh. Oh well. (Except that in much of maths, and in computing too, we have parentheses within parentheses within parentheses: q=some(func(x,y), also(y,z, andalso(b,c))) – quests within quests! Fun within more fun – hooray! )

So we do have two different kinds of ‘Why’ – and they go into different places in our architecture.

One kind of ‘Why’ – the question, the ‘(‘ – goes above the Zachman space, goes above the Enterprise Canvas, goes into Archimate as intention. Think of it as a row above everything, or a backplane, or something like that: whichever way we view it, it pervades everything.

The other kind of ‘Why’ – the ‘)’, the decision – goes into the Zachman space as just another column, goes into Archimate as extension. Each decision is specific, explicit: it literally cuts off other choices in that context. We can connect it to things, show how it affects other things, but it doesn’t pervade everything in the way that the question does.

In that sense, it does make sense to put them in different places. (And also – very important – not to forget the intention. Zachman ignores it, or loses it somehow in its strange sideways jump; Archimate all but abandons it, when it squeezes all of its Intentional Concepts into the literal meaninglessness of Passive Structure; and Business Model Canvas doesn’t even bother, but seemingly assumes that the only ‘Why’ that matters is ‘How do we make money?’ The ‘questing Why’ is literally emotive, the source of all motivation: if we don’t explicitly include it in our enterprise models, we’ve just shut out any reason for anyone to be engaged in our whatever-it-is. Perhaps not a wise mistake…?)

In another sense, though, it’s still the same ‘Why’. Just different faces – or phases – of the same quest. That’s where so much of the confusion comes, because often where we place it is more about how we choose to look at it than anything else. Looking ‘downward’, we see a stream of decisions: “because so-and-so… therefore… therefore… therefore…”. Looking upward, we see a stream of reasons: “because… because… because…” – ultimately ending up in the the unquestionable ‘Because!’ of the enterprise-vision or whatever. (I tend to place only that ultimate ‘Because!’ and its immediate implied-values as that uppermost layer of the enterprise-model; everything else ends up at various levels of that Extensional side-column of ‘Why’.) The Knowledge Genes structure also describes this Janus-faced relationship well, though in a different way: move leftward towards the question of Why, rightwards towards the decisions of How. The same ‘Why’, and yet different; a different ‘Why’, and yet the same.

Two kinds of ‘Why’.

That are also the same ‘Why’.

Now why is that, I wonder…?

(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’.

[Ditto.]

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?

This one picks up on a couple of sort-of-mistakes that I’ve made in the previous post, ‘Questions on business-model to enterprise-architecture‘, and which need a bit more clarity in explanation. In particular, it’s about specific points in relation to two of Stuart Boardman’s questions:

• an Asset as a type of a Resource – specifically as a Resource for which “the respective service is responsible”;
• a Capability also as a type of Resource.

A key part of this relates to what goes into the Key Resources section in Business Model Canvas, and how we translate and model the respective items in Archimate.

This will no doubt be another long one – sorry… – hence more after the ‘Read more…’ break.

Resources in Business Model Canvas

Business Model Canvas is about business, and in essence is in the language of business. Perhaps that seems obvious at first – but it has some implications that aren’t obvious at all, that are very important indeed to anyone working with detailed design.

Implementation folks need precision, exactness, certainty – because very often that’s the difference between what works, and what doesn’t. But the whole point of the kind of strategic language used in Business Model Canvas is that it’s blurry, uncertain, cluttered with clunky not-quite-categories and ‘you-know-what-I-mean’ mixups of service versus function versus capability versus process and so on. At that level, allowing that kind of clumsy clunkiness to exist is often what makes the difference between what works, and what doesn’t. But the clash between those two very different mindsets can life very, uh, interesting, for enterprise-architects and others who have to bridge the gap…

Business Model Canvas starts with a Value Proposition. No problem there. Yet the first questions any implementer will ask are:

• What do we do to create value?
• What do we use to create value?

In Business Model Canvas, that’s what we would list under Key Activities, and Key Resources.

Key Activities are what we do. In Archimate terms, that’s Behaviour, as a service, function, process, interaction. (We won’t explore these any further in this post.)

Key Resources are what we use. Anything that we would use in doing something is a ‘resource’. This includes what we use to do things to, and what we use to do things with. Archimate splits these into two parts: the ‘things’ that we use which Archimate calls Passive Structure, such as an object, a contract, a product and so on; and what we use to act on those things, which Archimate calls Active Structure, as roles, interfaces, actors and suchlike.

Capability as Resource

A capability is ‘the ability to do something’ – an active part of what we would use to do something. In Business Model Canvas, we would describe this as a Resource, because it’s something that is available to use, but not the activity itself.

A capability is part of the structure of work, rather than the doing of work. Hence it’s what Archimate would call Active Structure – except that it doesn’t use the term ‘capability’ at all. Instead, if we accept that capability is ‘the ability to do something’, then it’s sort-of-implied in Business Role (Business layer), Application Component (Application layer) and Device (Technology layer).

Note that those entities in the respective layers could also be described as capabilities embedded in a real-person, in IT-software, and in a machine. Those distinctions become important when we look at Assets later.

A capability is a Resource that, with some provisos, we translate into Archimate as an aspect of the ‘things’ of Active Structure. Or, to put it the other way round, each of the ‘things’ of Active Structure has capabilities. That capability is exposed through an Interface, to say how it will do something; and linked to a Function (or Process, or Interaction), to say what it will do to something; then both Function and Interface are linked together to provide a Service.

Anything that Business Model Canvas terms as ‘Key Resources’ is something that is available to be used within the business-model. Anything that Archimate terms as ‘structure’ – whether ‘passive’ or ‘active’ – is a resource. Capability is active structure that is a resource because it is something that available to use.

Asset and Resource

Over on the other side of Archimate is its Passive Structure, are the ‘things’ to which or with which something is done. This forms the bulk of the remainder of the Business Model Canvas’ ‘Key Resources’.

There are a few other Zachman-like items that don’t really fit into either Key Activities or Key Resources, though they are needed for modelling of implementation. These include key events for the business-model, key decisions (but not decision-making itself, which is a capability and/or an activity), and some types of locations. Archimate places Event as a class of Behaviour (somewhat oddly, because it’s a trigger for behaviour rather than a behaviour as such); the current version of Archimate doesn’t cover anything else, but the upcoming version is expected to include an entity for Location, and may cover some aspects of decisions in the proposed Motivation extension. (We won’t explore these any further in this post either.)

For most of these other Resources, I’ve found it useful to map them in terms of two specific dimensional sets of attributes:

• entity in focus is tangible versus non-tangible
• focus is on the entity itself, versus emotive relationship between a real-person and this entity

I’ve suggested in the other post that a Resource becomes an Asset when someone has an explicit responsibility for the appropriate maintenance and/or use of that resource. A clear illustration of this responsibility is implicit in the ‘assets and liabilities’ column of a balance-sheet – where a ‘liability’ is in relation to an asset for which the organisation accepts responsibility without actually the ownership of it.

This gives us four key categories of asset-’primitives’: physical (tangible entity), virtual (non-tangible entity), relational (person to/with tangible entity), and aspirational (person to non-tangible entity).

A physical-asset is tangible, hence also ‘alienable’: it is transferred from one owner to another by physical exchange of the entity. Responsibility for the asset rests with the person who holds it. It’s relatively simple to build a property-model based on ‘rights of exclusion’ around physical-assets. (We’ll ignore for the moment the ethics or sustainability of doing – the point is that the alienable nature of physical-assets makes it possible to do so.)

A virtual-asset is non-tangible, hence also ‘non-alienable’. (IT systems work almost entirely with virtual-assets.) Non-alienability means that the way we create a sort-of transfer is by making a copy of the entity at the destination for the ‘exchange’, and optionally deleting the original copy at the ‘source’: there is no actual transfer of ‘the entity’ as such. Again, responsibility for the asset rests with each person who holds each independent copy of the asset. It is extremely hard (perhaps impossible) to build a viable property-model based on ‘rights of exclusion’ to virtual-assets (i.e. ‘intellectual-property’), because the nature of virtual-assets requires that a new copy be created at every transfer. Attempts at exclusion require ever-more-cumbersome structures that are, by definition, ultimately self-defeating; business-models that rely on such exclusion are inherently fragile and may well be delusory, “held together by nothing more than smoke-and-mirrors and lawyers’ bluff”.

A relational-asset exists between a real-person and another tangible entity. (The other entity is often another real-person, but not necessarily so: it’s useful here to consider the emotional attachment people have to physical objects or places or animals as other variants on the same theme. We could also be pedantic and say that the source-entity does not always have to be a real-person: a dog, for example, is certainly capable of forming emotional attachment to people, to places, to other animals and also to tangible objects – and each of those connections would technically be a potential relational-asset.) The asset is undeniably ‘real’, yet cannot actually be transferred to any other person, because it exists between the source and destination. (Conditions can be provided under which an equivalent relational-asset can be created, but the asset itself cannot be transferred as such.) Responsibility for the maintenance of the asset rests with both parties to the asset: if either party abandons that responsibility, the asset will cease to exist. Because of all these factors, it is extremely unwise to attempt to build a property-model based on ‘rights of exclusion’ around these assets, because it literally makes no sense: it can only be made to seem to make sense by treating ‘the Other’ as a ‘possessable’ physical object or as a subordinate subject of self – as unfortunately does occur in much employment-law, for example, or contract-law. (The well-meant phrase “our people are our greatest asset!” only makes sense when those people are slaves… it is essential to understand that it’s not the person that is the asset here, but the relationship with that person.)

An aspirational-asset exists sort-of ‘between’ but actually from a real-person to or towards a non-tangible or abstract entity. As with a relational-asset, both entities must exist in some sense in order for the asset to exist, even though the ‘far-end’ of the asset-relationship is technically ‘imaginary’. This latter point is crucial for brands and similar types of aspirational-assets, where the non-tangible entity is maintained by a third-party: if the ‘owner’ abandons the entity, or even changes the entity in some way, any aspirational-assets linked to that entity may well be lost. As with relational-assets, an aspirational-asset cannot be transferred as such to another person, but conditions may be created in which an equivalent relationship may emerge. Likewise the nature of aspirational-assets is often very poorly understood in business-models, and are often mis-framed as if one or both ends of the relationship are physical ‘possessions’: attempts to build a property-model based on aspirational-assets – such as ‘goodwill’ in relation to a business – are often delusory at best.

Many real-world assets (perhaps most?) are composites of these categories; each composite takes on the attributes of all of its component categories. A printed book, for example, is both a physical-asset (the book-object itself) and a virtual-asset (the information contained in the book): it is therefore subject to all the constraints that apply to physical objects (inventory, deterioration, alienable location etc) and information-objects (transfer-by-copy, if only into the reader’s personal memory). A customer of a shop has both a relational-asset link with the employees of the shop and an aspirational-asset link to the shop itself (the abstract-entity or idea of ‘the shop’): the business will in effect leverage the relational-asset to strengthen the aspirational-asset.

Note that all of these asset-primitives or composites could be represented on an Archimate ‘Business’-layer diagram as a Business Object. Unfortunately, the effective IT-centrism of Archimate at present means that it can only portray an IT-specific sub-class of virtual-assets in the ‘Application’ and ‘Technology’ layers (as Data Object and Artifact respectively). This makes it impossible to describe a complete business-model in Archimate without resorting to unsupported ‘kludges’ to create non-standard Archimate entities to represent those other asset-types in the detail-layers of the model. We need a better solution than this in Archimate or any future equivalent.

In evaluating business-models or enterprise-models, note carefully the points above about the viability (or rather, the non-viability) of business-models that go against the inherent asset-type natures of the assets in scope for the business-model.

Also beware that many existing business-models rely extensively or entirely on a notion of ‘anti-possession’, of use of but non-responsibility for specific types of resources: a perceived ‘right’ to pollute, for example, or to extract personal benefit by socialising other business costs. (In Enterprise Canvas terms, this is an expropriation arising via a mismatch between the full set of between stakeholder-Investors versus a much smaller subset as Beneficiaries.) Increasing transparency, increasing awareness of environmental and other costs, and increasing availability of alternate information-sources beyond organisations’ own control, all tend increasingly to expose any covert ‘cost-export’ process; the resultant social and legal pressure from that exposure is likely to render non-viable any business-model that depends on such dysfunctional processes, and needs to be understood as a very high kurtosis-risk to that business-model.

Okay, better stop there: more than enough already. Very technical, I know, but I hope it’s useful to someone?

You advocate starting (“for now”) with one Business Service. How are we to determine what this business service represents? If the typical enterprise had one single, tightly defined core business, it would be easy but as that’s not usual, I’m unclear how one would define this.

In the adaptation from Business Model Canvas to Archimate, if we start with one Business Service entity, that entity would then represent either the business-model as a whole, or else one of the subsidiary models in a multi-part business-model. If the latter, we would come back later and build equivalent cross-maps for the other subsidiary models. We ‘define’ the service only in the sense that we choose that as the place to start modelling: the content for that ‘service’ is defined already from what we’ve developed on the Business Model Canvas.

The reason for starting just with one Business Service entity is that, when we first start doing this kind of cross-map, it’s often complicated enough already just with the one. As we gain more experience with the cross-map process, we can go straight to a model that looks more like a real-world structure right from the beginning, but that level of detail can often seem overwhelming at first – especially to others when they see the model for the first time. We’ll almost certainly need to decompose it into multiple Business Service entities later, but it’s best to keep it simple at the start!

Why did you pick Activity as the genericization of Application? I see an activity as a much more fine grained thing. (IT) Applications typically perform many activities (and I’m only talking about externally visible activities here). That’s actually one of the reasons I am uncomfortable about the IT focus on applications rather than services. But that’s another discussion. This point might just be semantics, in which case don’t worry.

To use the famous phrase, “it seemed like a good idea at the time”… to me there’s nothing special about that choice of ‘Activity’ versus any other equivalent term. The main point was that I wanted a term that could describe the same something-being-done, as done by any combination of real-people, machine and/or IT – not just the strongly IT-oriented term ‘Application’.

You say a Capability is “the ability to work on specific types of asset”. Can you give an example? I’m not following what you mean by “working on” an Asset.

This relates to part of the rework I did some time back on making the Zachman columns fit more closely to what happens in the real-world, and specifically relates to what Zachman describes as the ‘Who’ column. To me Zachman’s column-structure has never made sense, because it kind of randomly conflates different things into the same spaces, and the ‘Who’ column is particularly problematic. Business-folks also tend to use terms such as ‘process’, ‘service’, ‘function’, ‘capability’ and even ‘unit’ as almost random sort-of-synonyms for each other but at different levels of abstraction or decomposition – a further muddying of the waters that really doesn’t help when trying to disentangle the resultant mess!

There are several fundamentally different things going on in that context:

1. What is being changed or used or referenced or otherwise worked on or worked with;
2. The rules that govern what changes are to take place, and how those changes should take place;
3. The ability to work on (create changes to) whatever-it-is;
4. The ability to make appropriate decisions about how those changes are taking place (the skill-level or decision-level).

Item 1 is what I term an Asset – more about that in a moment, when we look at Stuart’s next question.

Item 2 is what I term a Function, because it’s essentially as in a mathematical function – a=resultofdosomethingwith(x,y). It defines the parameters that will be used (i.e. providing labels for Asset-types), but in essence everything else is encapsulated inside the function (i.e. black-box).

The specific combination of item 3 and 4 is what I term a Capability, because it’s the ability to do something at a specific level of skill and decision-making. (This is similar to the way that Stuart defines it below – “the ability to perform some activity/task/service” – but with a bit more specificity and taxonomic precision.) In the human context, capabilities are often clustered or bundled into Roles and/or Responsibilities – the latter of which are, literally, ‘response-abilities’. That’s the human side of skill and ability, which is why it fits as more consistent meaning at the detail-layer than Zachman’s ‘Who’.

We bring a Function and a Capability together to form a Service. On its own, a Function is always abstract: it needs a Capability to make it actually do something. And on its own, a Capability literally has no function: the Function provides a context in which the Capability can be put to work. A Service may present the same Function interface but with different underlying Capabilities – hence, for example, a Service that can handle any level of insurance-claim, with low-value claims processed entirely by IT-based Capability but higher-value claims requiring human intervention with a different Capability implementing a higher skill-level and decision-making authority.

A Process is just a sequence of changes provided by Services, that are regarded as related in some way (hence ‘choreographed’ etc). It may be a predefined sequence (as in most IT-driven processes); or it may be almost entirely freeform, requiring high skill-levels; or anywhere between those two extremes, using any appropriate combination of human, machine and/or IT capabilities.

This is yet another example where IT-centrism has scrambled people’s understanding of what’s actually going on here. The problem arises because Function and Capability and, often, Process, are all blurred together within a software-application, whereas in a human or even a machine context the distinctions are much more necessary and explicit. We need to be able to distinguish between them for key architectural concerns such as trade-off analysis for implementations or load-balancing, and business-continuity/disaster-recovery.

When you say an Asset is a Resource for which “the respective service is responsible”, how do we determine which service that is and what does responsible mean?

A Resource is simply something that can be used in some way: anything that exists in some form or other is a potential Resource for some kind of business-model. A resource becomes an Asset within some type of ownership-model: in the crudest possible sense, it’s an Asset if we own it. Some things – air, for example, or time – can be resources but can’t be Assets because we can’t own them as such.

We then hit up against the complexities of contrasting different ownership-models, particularly possession-based (i.e. what we’d usually think of as ‘property-rights’) versus responsibility-based. I won’t go into those distinctions in detail, but in essence all of this actually revolves around roles and responsibilities. The whole point of the business-model is we say that we will deliver the Value Proposition via the Channels to the Customer Segments. If we expand that statement into more precise taxonomic detail, what it means is that we declare responsibility (‘response-ability’) to deliver value to the shared-enterprise, by doing something (Key Activities) with Assets (i.e. resources for which we also have responsibility), and then, via some defined mechanism (i.e. Channels), passing the responsibility for those value-added Assets to the enterprise-stakeholders referred to as ‘Customer Segments’. That second definition probably seems horribly long-winded and pompous, but that’s the level of detail that we actually need when we’re going to design a real-world implementation.

I’m uncomfortable with Capability as a Resource. A Capability seems like an abstract concept, the ability to perform some activity/task/service. A resource is something that gets used – whether consumable or not. I realize that, if I’m right, we may have a gap in the Business Model Canvas, which doesn’t seem to have a place for Capabilities.

Perhaps the best way to explain this is that well-meant phrase “Our people are our greatest asset”. (In reality, it’s the relationship with the person that is the asset, but that’s another story.) The point here is that the skills and abilities of the person, the machine, the IT-application or whatever – the set of available “ability to perform some activity/task/service” – is definitely “something that gets used” in the organisation, and hence ‘resources’ from the organisation’s perspective. So it’s not a gap in the Business Model Canvas – it’s what we would include under the Key Resources banner.

In fact in general one of the things you’ve done (deliberately or otherwise) is to highlight a weakness in the Canvas, when it comes to dealing with extended enterprise. I mentioned this in another comment. Of course it’s possible but it requires one to think outside of the boxes (boundaries) in the Canvas. In particular the relationship with Partners seems to be unidirectional and rather more resource than service based. By doing the mapping this becomes clearer. So either we say that it’s OK just to work with the Canvas’s implicit support for extended enterprise or we need to address that (or rather ask Alex Osterwalder to do so). The first option means from my perspective that we then need to find a way to handle it explicit in the Archimate (or any similar) mapping. You were dealing with some of these issues in your post on non-profit enterprises and the Canvas.

There’s a real danger of being unfair here, so I ought to reiterate that Business Model Canvas works very well indeed for the task that it was designed to do. That task is about getting people to think and innovate about how their business-model operates, in a kind of integrated, big-picture way, all with the simplicity needed for rapid brainstorming and pre-prototyping and the like in a free-form workshop or cafe context. To me it’s a business-architecture tool, with a very specific purpose: we really have no right to complain that it isn’t a good fit for whole-scope enterprise-architecture, or for detail-layer implementation, because it was never designed for those kinds of uses.

If we need to link it into methods and tools and the like for those other uses, it’s our responsibility to get those cross-mappings to work – not Alex’s. That’s what this bunch of posts has been about: going downward to Archimate and suchlike, and upward to Business Motivation Model and beyond.

The same applies to using Business Model Canvas for business-models for government or non-profits. The fundamental structure of the Canvas is geared towards commercial organisations, and there’s nothing wrong with that. If we want to use the Canvas outside of a commercial context, it’s our responsibility – not Alex’s – to make the appropriate amendments. (Alex did set up a website a couple of years back to explore ‘business-models beyond profit‘ – and although it doesn’t seem to have gone any further in the last eighteen months or so, I know he does have a deep personal interest in that space.) So again, we do need to be fair here.

The only ‘weakness’ in the Business Model Canvas as such is its implicit asymmetry on the Key Partners side of the model: in my opinion those relationships need to be understood as exactly symmetrical with the Customer Segments side, not least because we can make or break a business on supply-side as easily as on customer-side. That asymmetry also makes it more difficult to visualise a full supply-chain, or the role of the business-model within an overall value-network. Much the same applies to its orientation towards resources rather than services, and (especially in the Canvas’ implementation in the BMTBox iPad app) the low priority given to modelling of flows and transactions.

But I do acknowledge both of those as trade-offs to preserve simplicity: that kind of structure does make it easier to focus on this organisation’s business-model, without getting too distracted by anyone else. For the Enterprise Canvas, I made different trade-offs: it’s explicitly symmetrical, and it’s explicitly designed around services, but it is also more complex – especially once we use it to go into recursive service-decomposition or inter/intra-service coordination or flows-modelling or role-mapping or values-dependencies and the like. It’s designed for those uses, and Business Model Canvas isn’t – but that doesn’t make Business Model Canvas ‘wrong’ as such. Using Enterprise Canvas for multi-layered enterprise-modelling also requires a different mindset and skillset, than those needed for roughing out business-models on Business Model Canvas – the difference between whole-enterprise architecture and domain-specific business-architecture, in fact. Sure, we can use Enterprise Canvas to develop business-models, and it actually fits that need very well: but it’s not specifically designed for that purpose – whereas Business Model Canvas is. ‘Horses for courses’, really.

I hope that makes some degree of sense, anyway, and that it answers those questions well enough for now?

But why all this fuss about business-models and enterprise-architecture? What’s the point about the bottom-line not being the baseline to work from? If everyone’s selling something to someone, is there really any difference between a for-profit and a non-profit business-model? And who would want to go from Business Model Canvas to Archimate, anyway? Is anyone interested in any of this technical stuff?

I suppose it all comes down to this quote from Chris Potts:

The devil is in the detail, but the angel is in the architecture.

People like building business-models. It’s wonderfully abstract, and it’s fun – like playing with model-trains, where the passengers are only imaginary and the trains really can run on time. Unfortunately (or fortunately?) the real world is a bit different from that…

Real-world detail can break the best-looking business-model without even breaking out a sweat. We need to know that detail – or at least have a better sense of that detail – before committing ourselves and others to a lot of hard work and ultimate heartache.

Yet we also need to avoid drowning in the detail – otherwise we’ll never get started. Analysis-paralysis, and all that.

Which is where architecture comes into the picture. Formal discipline, yet without overt formality. Patterns help us break through the problems. We simplify, without being simplistic. And we model to reduce the muddle, to cut through the chaos and complexity of all that devilish detail.

Perhaps even more, it’s about the story: the story of each action, and the story of the enterprise itself. If we get clear on the story, the sensemaking becomes a lot simpler.

As I understand it, architecture comes down to a single idea: everything works better when they work together, in pursuit of purpose, a clear aim in mind. Everything connects with everything else. It’s the detail of how everything connects with everything else, of how we get everything to work with everything else, that I’ve been focussed on here.

A lot of detail, I know: but sometimes that is the nature of the beast. Fact is that architecture isn’t all nice pretty abstracts and nice pretty pictures – sometimes there is a lot of petty picky detail, and sometimes we just gotta face that fact… sorry…

Hope it’s been useful to someone, anyway?

The detail’s there if you need it, but if you just want to do the translation from Business Model Canvas to Archimate, without worrying too much about the ‘Why’ behind it, here’s the short version.

Step 1: Start with a business-model on Business Model Canvas

That part’s straightforward enough for most folks here, I imagine?

Step 2: Separate out the players on the business-model

Start an Archimate diagram at the Business layer (the ‘Why’ layer).

Represent each Key Partner from the Business Model Canvas by a Business Actor entity on the Archimate diagram.

Likewise, represent each Customer Segment by a Business Actor entity.

(We will also need Business Role and Business Interface link-entities for each of these business-actors, but we’ll come back to that in a moment.)

The remaining cells of the Business Model Canvas – this organisation – can for now be represented by a single Business Service entity.

Step 3: Expand the detail for the interfaces of the business-model

Represent each Value-Proposition offer by a Product entity, optionally with an associated Value entity to describe why this offer would be of value to a customer-segment. Link these Product entities to the organisation’s Business Service.

Represent each Customer Relations item and Channel with the following:

• Business Interface entity, linked on one side to the organisation’s Business Service, and on the other side to a Business Role assigned to the respective customer-segment Actor
• Business Interaction entity, also linked to the Business Service and to a customer-segment’s Business Role
• Business Object entity – indicating the content of the flow between the organisation and the customer-segment, optionally associated with a Meaning entity and/or Contract entity – linked to the respective Business Interaction

Represent each Revenue Stream in a similar way, as a ‘back-channel’ through which value is returned to the organisation. Each back-channel will include its own Business Interface, Business Interaction, and Business Object, with the latter probably linked to the same Contract as for the respective Business Object in the main transaction channel.

Repeat the same process on the supplier-side, with matching Business Interface and Business Role entities for each Key Partner, and Business Interface, Business Interaction, Business Object and Contract entities for each external Cost Structure item. The respective channels and supplier-relations services are only implicit in Business Model Canvas, but you’ll need to add the respective Business Interaction and Business Object entities on that side, together with any needed Contract entities.

Step 4: Expand the Key Activities

Extend the Archimate diagram down to the Applications layer (the ‘How’ layer). In particular, we’ll use this layer to model the Key Activities in the Business Model Canvas.

We have a problem at this point: Archimate’s ‘Applications’ layer only knows about IT, and we need it to cover a much broader range of types of ‘How’. This is because an activity in a business-model could be done by any combination of people, IT and ordinary machines, and to understand the trade-offs between different ways of doing things – different types of ‘How’ – we need to model them in much the same way in each case.

To do this, we need to change the Archimate entities for this layer from the IT-specific ones in the standard, to more generic ones that will work with any type of implementation. In most cases, all we need to do is change the prefix of the name from ‘Application’ to the generic ‘Activity’. This gives us the following entities to model our Key Activities:

• Activity Object (generic of Data Object): represents an object (or subject) to be created, accessed, changed, deleted or otherwise worked on in a business-activity – may be physical, virtual, relational or any combination of those as required
• Activity Service (generic of Application Service): the ‘exposed’ part of an activity that connects with a Business Function in the Business layer
• Activity Function (generic of Application Function): a ‘chunk’ of activity that is visible only within this layer
• Activity Interaction (generic of Application Interaction): a unit of behaviour where two or more components or modules come together to act on an Activity Object
• Activity Interface (generic of Application Interface): a point where an activity can connect with its environment – particular to access or exchange Activity Objects
• Activity Module (generic of Application Component): a defined unit of activity in a structural sense, such as specified in an ISO9000-style Work Instruction
• Activity Collaboration (generic of Application Collaboration): a temporary configuration of two or more modules to perform collaborations

Link these entities as appropriate, using the respective standard Archimate relationship-links.

Step 5: Expand the Key Resources

Extend the Archimate diagram down to the Infrastructure layer (the ‘With-What’ layer). In particular, we’ll use this layer to model the Key Resources in the Business Model Canvas.

One of the frames we use extensively in our own enterprise-architecture is an extended and adapted version of Zachman, which uses the categories Asset, Function, Location, Capability, Event and Decision. In general, the Key Resources section in Business Model Canvas relates to Assets, Locations (physical, virtual, relational, and various combinations), and Capabilities (the abilities or facilities used to the work or within which or through the work takes place).

Again, the Archimate standard only knows about Assets, Locations and Capabilities that relate to IT: we need to extend this to include any other types we may need in the business-model – including buildings, machines, and individual people’s skills.

An Asset can be defined simply as a resource for which the respective service is responsible and can put to use as required.

A Capability is the ability to work on specific types of Asset using a specific level of competence and skill.

A Location is a node within some type of location-schema. Locations may be of any asset-type or resource-type, or any combination of these.

A network is a schema that describes a set of Location nodes, specific relationships between those nodes, and, often, the types of Assets than can be transferred on pathways of connection between those nodes.

An infrastructure is thus a clustering of Assets, Capabilities and Locations, often in network-relationships.

Given these, we would represent the Key Resources via the following Archimate entities, adapted as appropriate:

• The Artifact entity may represent any type of real-world Asset.
• The Infrastructure Service entity may represent the exposed available behaviour (Capability) of any cluster of related Assets, Capabilities and Locations, linked to any Activity Function in the Application layer.
• The Infrastructure Interface entity can represent the exposed interface for an Infrastructure Service, as linked to any Activity Interface in the Application layer.
• The System Software entity is merely one very specific example of a generic Capability entity, and can be used (preferably retitled) to represent any Capability.
• The Device entity represents a type of Asset that can be used in and for specific activities, as ‘active structure’: a hammer, a power-drill, a fork-lift truck and an ordinary ‘dumb’ telephone are a Device in this sense.
• The Network, Node and Communication Path entities respectively represent a schema for connections between Location nodes, a node within that schema, and a connection-path through which specific types of Asset (Artifact entity) may be transferred between nodes.

As in the Application layer, the types of relationships that Archimate permits between these more generic entities and their derived specialisations should remain essentially unchanged.

Step 6: Apply enterprise-architecture disciplines as required

Use standard enterprise-architecture techniques – such as the methods and tactics outlined in TOGAF Phases B-D – to review the resultant architecture portrayed in the Archimate model(s), and make any recommendations for changes to the business-model itself.

Use standard project/architecture techniques – such as the methods and governance outlined in TOGAF Phases E-G – to define and monitor change-projects to implement the agreed business-model.

This specific part goes from the business-model downwards, from Business Model Canvas to Archimate, and thence to BPMN, UML and other detail-layer models. (There’s another part needed to link upward, connecting that work back up through Business Motivation Model and the like to the core shared-enterprise, but I’ll have to deal with that in another post.)

As you’ll see, I’ve had to twist Archimate somewhat in a few places, to provide workarounds for its current IT-centrism, but otherwise everything exactly follows the existing standards. The keys that enable and to some extent validate those adaptations are two assertions:

• everything is a service (an assertion supported explicitly by the design of Archimate itself)
• everything is recursive (a principle that enables pattern-based modelling, such as the concept of ‘layers‘ used in Archimate, TOGAF etc)

The ‘how-to’ that follows after the break is the current outcome of a lot of exploration over the past weeks, months and years, a lots of posts and conversations on this blog and elsewhere, and a lot of in-person discussion with a lot of people, many of whom have explicitly asked to remain anonymous. I do believe it’s in a usable state right now, but it should still be regarded as ‘in beta’ at best: use with some caution, and please send me any feedback and suggestions.

In parallel with both Business Model Canvas and Archimate, this may be considered to be under a Creative Commons licence. It’s probably not yet stable enough to attach to a CC license-type in a formal manner, but for now please assume non-commercial, share-alike and attribution-requested for the parts described here.

More after the ‘Read more…’ break, anyway.

Step 1: Develop a business-model

The term ‘business-model‘ here means a semi-detailed overview of what the organisation does in its business with others, and the offers and value-types that are exchanged. A strong recommendation that the model should be developed in the Business Model Canvas format, using the associated methods described and/or summarised in the book Business Model Generation. (The book is currently available in at least 18 languages.)

Here’s an example Canvas from an earlier post:

Identify the flows that take place between the various entities in the model. This example (from the same earlier post) shows only the connections, but also identify and record what would traverse these flows in order to enact the intent of the model:

All of this would typically be developed in a workshop context, or in a cafe-type setting with a notepad or a software toolset such as the BMTBox app.

Step 2: Re-map the overall business-model as related services

Split the Canvas into a core for the organisation that executes the business-model, and separate entities for each of the Customer Segments and Key Partners:

In Enterprise Canvas, each of these would be mapped as nodes (services) in a value-network, all in relation to each other and the the overall vision for the shared-enterprise:

The Business Model Canvas typically shows only the immediate links in the supply-chain or value-network, but in Enterprise Canvas we could also extend the node-relationships as required:

In Archimate, at the highest level, the organisation and its combined business-model can be represented as a single Business Service; the [BMC] Customer Segments and Key Partners can be represented as Business Actor entities, each of whom takes on one or more Business Role positions, and connect to the service presented by the organisation via Business Interface relationships:

Step 3: Expand the detail of the overall business-model

From previous work, we can cross-map the Business Model Canvas onto Enterprise Canvas:

The Archimate specification indicates that a unit exposes functionality externally as a Business Service, but represents internal functionality as a Business Function. In essence, this is a simple recursion: structurally, they are the same – the difference is in in where and how the interface is exposed, for example whether or not the related Business Interface requires an explicit Contract.

The simplest summary is that the overall functionality and relationships represented via a single Enterprise Canvas entity would be depicted in Archimate as a Business Service; but the constituent ‘cells’ within that Enterprise Canvas would be depicted as Archimate Business Function entities:

The Archimate Business Process entity literally does not come into the picture at this level. A business-process is best understood as a pattern of activities that make use of services in some form of choreographed sequence: it is somewhat misleading to describe it as a structure in the same sense as other Archimate entities such as Business Service or Business Interaction, because in essence it’s a structure in time only. The term ‘business process’ tends to be misused as a kind of variant of ‘service’ or ‘function’ or ‘capability’, and all of these terms seem to be used in an arbitrarily interchangeable manner, leading to much confusion in modelling and even in business practice: instead, precise taxonomic distinctions are essential here. In that taxonomy, a service is a combination of function and capability, but for these purposes we can allow ‘service’ and ‘function’ to in effect be synonymous, as summarised above.

Given this, we can re-map the Business Model Canvas  / Enterprise Canvas [EC:] cross-map into Archimate (italics) entities as follows:

• The Value Proposition (EC: value-proposition) is represented by one or more Product entities, with related Value entities.
• We have already mapped the Key Partner and Customer Segment entities as Business Actor / Business Role / Business Interface entities.
• All of the Enterprise Canvas cells are mapped to Business Function entities with appropriate names (default: same names as in Enterprise Canvas); these also represent in part the Key Activities cell of the Business Model Canvas.
• All of the Enterprise Canvas interface cells (customer-relations, customer-channels, value-return; supplier-relations, supplier-channels, value-outlay) also include Business Interaction entities (which may optionally replace the respective Business Function entity), each linked to a Business Interface entity, representing the channels and other interfaces to the overall service.
• Each of the six channels (Business Interface entities) links to one or more Business Object entities, which in turn link to the Business Interface of a Customer Segment or Key Partner; each Business Object may optionally be linked to a Meaning entity.
• Each Business Object entity attached to a customer-channel Business Interface should also be linked to one or more Product entities; the same may optionally apply to Business Object entities attached to the supplier-channel Business Interface.
• The Business Object entities associated with a supplier-channel and value-outlay, or customer-channel and value-return, should be linked by a Contract entity, representing the required relationship between the respective Enterprise Canvas main-channel and back-channel (e.g. Business Model Canvas linkage between Value Proposition, Customer Channel. Customer Segment and Revenue Stream).

In essence, using the suggested sort-of layers described in the previous post ‘Rethinking the layers in enterprise-architecture‘, this represents the content for the ‘Why’ layer, which Archimate describes as the ‘Business’ layer. To a significant extent, the ‘Key Activities’ cell of Business Model belong in the ‘How’ layer (which Archimate at present describes only as the largely IT-centric ‘Applications’ layer), whilst much if not most of the ‘Key Resources’ cell belong in the ‘With-What’ layer (which Archimate at present describes only as the exclusively IT-centric ‘Infrastructure’ layer).

More on that in the next steps. In the meantime, we can summarise the mappings as follows – from the Business Model Canvas for one class of offer (Value Proposition, or Product):

Then to the equivalent Enterprise Canvas for that segment of the overall business-model; and thence to a high-level (‘Business’ layer) Archimate model. [Apologies - I started work on these diagrams, but realised they would probably take an entire day each, and need a blog-post each of their own as well: leave this until later, perhaps?]

Note that this is for one category of offer only, from six categories shown in this overall business-model. The complete business-model for all of the offers in context would be a much larger and more complex Archimate model, even at the ‘Business’ layer only.

Step 4: Expand the Key Activities to Archimate ‘Application’ detail

In Archimate, each Business Function or the like in the Business (‘Why’) layer is supported by (realised via) one or more Application Service entities within the Application (‘How’) layer. We also have the same symmetry on the ‘active structure’ side, with an Application Interface entity underpinning or implementing each Business Role; and, on the ‘passive structure’ side a Data Object representing a more real-world form of a Business Object.

(cc) Open Group

The first point that this tells us is that each of the Enterprise Canvas cells and interfaces and flows will be represented by one or more Application-layer entities in Archimate. That part is straightforward enough.

But here we hit a problem with Archimate, because it assumes that activities at this level will only be enacted by IT. In the current structural assumptions in Archimate, activities that are enacted by real people are pushed upward into the Business layer, whilst activities enacted by non-IT technology (i.e. physical machines) are apparently deemed not to exist at all, or else shoved down into the Infrastructure (‘With-What’) layer.

In principle, every activity could be implemented by any conceivable combination of ‘manual’-process, physical-machine and/or IT. Each of these categories of implementation – human, IT and machine – need to be assessed here as if at the same level, so as to identify the trade-offs between different implementations. We also need to be able to view as if ‘the same’ in development and in disaster-recovery, where – for example – we would switch back and forth between a paper-and-pencil versus an IT implementation of what is functionally the same business-process. But Archimate at present doesn’t allow us to do that trade-off assessment: instead, it assumes that everything can be implemented only by IT. In effect, each of the Archimate entities in this layer is an IT-specific specialisation of a generic entity that does not exist. This is a fundamental flaw in the design of Archimate – and one that we need to resolve before we can use Archimate for the kind of true enterprise-scope assessments needed in reviewing the architectural implications of business-models.

The simplest solution here is to go back and recreate the ‘missing’ generic entities of which the existing Archimate entities in this layer are the IT-oriented specialisations. Given that this layer is about the activities that enact business-functions and business-services, these generic entities could be labelled with an ‘Activity’ prefix:

• Activity Object – generic of Data Object
• Activity Service – generic of Application Service
• Activity Function – generic of Application Function
• Activity Interaction – generic of Application Interaction
• Activity Interface – generic of Application Interface
• Activity Module – generic of Application Component
• Activity Collaboration – generic of Application Collaboration

An Activity Object could perhaps be more accurately described as an ‘Activity Subject’, since it’s the subject of all activities, the entity which will be created, accessed, updated and/or destroyed through the respective activity. Again, note that this is the generic: this entity would usually be specialised in the model, to describe a physical object being worked on, a business-relationship being developed, a data-item being accessed or amended, and so on.

An Activity Module is a somewhat arbitrarily-bounded ‘chunk’ of functionality, described in structural terms (‘active structure’) rather than the action itself. For IT, this would typically be described as a ‘component’ or (somewhat misleadingly) as a ‘service’. For a manual process, a typical ‘chunk’ would be as described in a Work-Instruction (in ISO-9000 terms), or possibly a somewhat more abstract Procedure. For a machine-based process, a more typical ‘chunk’ would be the defined work within a given process at a single machine or workstation or cluster of workstations.

The types of relationships that Archimate permits between these more-generic entities (and hence between their derived specialisations) should remain essentially unchanged.

It may also be useful to include links and references to location – physical, virtual and/or relational. There is no Location entity in the current Archimate standard, but it is expected that one will be included in the upcoming Version 2, so there should be no problems with compatibility there.

A strong recommendation here to use the distinctions between Function and Capability as described in the extended-Zachman model used in conjunction with Enterprise Canvas. A function is a metaphoric ‘place’ where an Activity Object will be accessed or changed, and that summarises the changes that will take place; whereas a capability is the competence and skill-level brought to bear on Activity Objects in order to enact the required changes. In most IT applications, these two aspects are merged together into the one item of functionality, hence the distinctions between them may seem too subtle for some people to notice; but for machines and, especially, for human processes, the distinctions are much more explicit, and very important. The function aspect relates to activity, and hence belongs in this layer, whereas the capability is in effect a type of ‘resource’, and hence belongs more properly in the equivalent of the Archimate ‘Infrastructure’ layer. More on that when we look at the Key Resources section of the business-model, anyway.

I won’t go into more detail here of how to develop the model itself. Instead, refer to any of the Archimate reference-materials – such as the formal Archimate standard, the documentation from the Archimate Foundation, or the free Archi toolset for Archimate – and then adapt using the generics and re-specialisation of entities as summarised above.

Each of the activities summarised in the Key Activities cell in the Business Model Canvas should be represented somewhere in this layer of the adapted-Archimate, linked appropriately to the services in each of the cells in the matching Enterprise Canvas.

Step 5: Expand the Key Resources to Archimate ‘Infrastructure’ detail

We now go down one more level in the architectural recursion.

In Archimate, each Application Function or the like in the Application (‘How’) layer is supported by (realised via) one or more Infrastructure Service entities within the Infrastructure (With-What’) layer. We also have the same symmetry on the ‘active structure’ side, with an Infrastructure Interface entity underpinning or implementing each Application Component; and, on the ‘passive structure’ side an Artifact representing the full concrete form of a Data Object.

(cc) Open Group

The implication here is that each of the Key Resources in the Business Model Canvas should be represented in some way within this layer. But here again we hit up against the current limitations of Archimate, because it assumes that the only relevant resources are those that can be described in terms of IT: devices, networks, system-software and so on. In the current structural assumptions in Archimate, the competencies and skills of real people are somehow pushed upward into the Business layer, whilst any other non-IT technology or physical resources, capabilities and infrastructures are apparently deemed not to exist at all. To be blunt, this is IT-centrism running wild, and presents serious problems for modelling at this layer.

In principle, every activity could be implemented by any conceivable combination of ‘manual’-process, physical-machine and/or IT- which means that we need the respective resources and infrastructures to match and underpin each implementation. As in the ‘How’ layer, each of these categories of implementation – human, IT and machine – need to be assessed here as if at the same level, so as to identify the requirements and trade-offs between different implementations, including those needed for special-cases such as development and disaster-recovery.

But again, Archimate at present doesn’t allow us to do that trade-off assessment: instead, it assumes that everything can be implemented only by IT. Some of the entities in this layer are sort-of generic – Infrastructure Service, Infrastructure Interface, Network, Node, Artifact – but they’re kind of incomplete relative to the full infrastructure/resource set, and it’s clear that, as in the Application layer, they’re intended more to represent IT-specific specialisations of generic entities that aren’t available in the Archimate specification. This is another fundamental flaw in the design of Archimate – and one that, once again, we need to resolve before we can use Archimate for its purported purpose as an enterprise-architecture notation.

Because the IT-centrism here is more implied than overt, resolving this is not quite as straightforward as in the Application layer. Probably our best option here is to re-assess the whole structure from the perspectives of the expanded-Zachman used in Enterprise Canvas: Asset, Function, Location, Capability, Event and Decision. These are mostly self-explanatory, though note that each of these itself expands to cover the full ontological scope:

These categories apply everywhere, yet there are also distinct emphases in each of the Archimate-style layers: Decisions, Events and, to a lesser extent, Functions in the Business layer; Functions and, to a lesser extent, Events, in the Applications layer; and Assets, Locations and Capabilities in this layer.

An Asset can be defined simply as a resource for which the respective service is responsible and can put to use as required. (In this context, there’s no real difference between assets and liabilities, other than in terms of availability, because in essence they’re variations on a theme of resource and responsibility.)

A Capability is the ability to work on specific types of Asset using a specific level of competence and skill. Note that in general, physical-machines can only work at a rule-based skill-level, IT typically at an algorithmic level, but in most cases only humans can act at guideline or principle-based skill-level. Also that almost by definition, physical-machines and IT are unlikely to be much use for working on relational or aspirational assets – a point that is often forgotten in the design and operation of many IT-based CRM systems…

A Location is a node within some type of location-schema. These may be of any asset-type or resource-type, or any combination of these: for example, a room in a building will have both a physical location and a virtual location-identifier; an IT network-node will typically have an IP-address or equivalent, but also at a physical location; an organisational hierarchy is also a relational network; and so on. And whilst time is often referred to as an ‘asset’ or a ‘resource’, it can’t be changed or transformed in the same way as for other assets, and hence is best understood as a type of Location rather than a resource. (An Event may be considered to occur in time, but is not in itself of time: the distinction may seem subtle, but can be very important in practice.)

A network is a schema that describes a set of Location nodes, specific relationships between those nodes, and, often, the types of Assets than can be transferred on pathways of connection between those nodes.

What we could term an infrastructure is thus a clustering of Assets, Capabilities and Locations, often in network-relationships.

This schema enables us to identify how the existing Archimate entities in the Infrastructure layer are somewhat-arbitrary IT-specific specialisations of the underlying generics:

• The Archimate Artifact entity is specified as a virtual-Asset, but can be repurposed to represent any type of real-world Asset.
• The Archimate Infrastructure Service entity can be repurposed to represent the exposed available behaviour (Capability) of any cluster of related Assets, Capabilities and Locations, linked to any Activity Function in the Application Layer.
• The Archimate Infrastructure Interface entity can be repurposed to represent the exposed interface for an Infrastructure Service, as linked to any Activity Interface in the Application Layer.
• The Archimate System Software entity is merely one very specific example of a generic Capability entity.
• The Archimate Device entity represents a type of Asset that can be used in and for specific activities, as ‘active structure’: a hammer, a power-drill, a fork-lift truck and an ordinary ‘dumb’ telephone are each likewise a Device in this sense.
• The Archimate Network, Node and Communication Path entities respectively represent a schema for connections between Location nodes, a node within that schema, and a connection-path through which specific types of Asset may be transferred between nodes.

As in the Application layer, the types of relationships that Archimate permits between these more generic entities and their derived specialisations should remain essentially unchanged.

Again, I won’t go into more detail here of how to develop the model at this layer: instead, refer to the Archimate reference-materials, and adapt that to the generics and re-specialisations of entities as summarised above.

Each of the items summarised in the Key Resources cell in the Business Model Canvas should be represented somewhere in this layer of the adapted-Archimate, linked appropriately to the services in the Application layer, and thence the services and interfaces and the like in each of the cells in the matching Enterprise Canvas.

Step 6: Apply enterprise-architecture disciplines to review the business-model

What we have, as the outcome of this modelling exercise, is a full ‘to-be’ description of the implemented architecture for the business-model. Which means that we can now turn to all the usual enterprise-architecture tools and techniques – TOGAF ADM, VPEC-T, requirements-modelling and the rest – to evaluate and rethink what works and what doesn’t, and what’s needed to make it all work together well.

The question at the initial Business Model Canvas stage was whether the ideas made sense at the business level. The questions here are more about whether it would work in real-world practice, such as:

• What structures, capabilities, skills, equipment does this business-model need?
• What exactly passes between each party in each flow – what are the Business Objects that are transferred and/or changed or exchanged? At what points in each process do these transfers take place? What mechanisms and functions are needed to ensure complete balance across the whole ‘Before’ / ‘During’ / ‘After’ cycle of the whole transaction?
• What structures and so on do we have already for this? What equipment and configurations and the like would need to be repurposed? What impacts would that have on existing operations and existing business-models?
• What kinds of changes do each of the requirements demand – incremental, step-change or breakthrough? Has adequate allowance been made in the risk-assessments for the feasibility or achievability of any required breakthroughs?
• Has sufficient attention been paid to the human aspects of the required business-model, including skills-development, retraining, redeployment and cultural change?
• What intermediate stages would be required, in the transition from ‘as-is’ to ‘to-be’? Has sufficient attention been paid to the probabilities that ‘there’ may not in reality be the same as we expected when we aimed to get there?
• Over what timescales could these changes be implemented? What timescales must apply if the business-model is to be viable?

And so on: the usual stuff, really.

(There are some planned extensions to Archimate to deal with versioning and projects and the like, but I’ll cover that in the next part, that deals more with looking ‘upward’ in the enterprise from the business-oriented view in Business Model Canvas.)

The point here is that this kind of modelling process enables us to do an iterative assessment and reassessment of the idea of the business-model and its real-world feasibility, implications and its implementation, bouncing back-and-forth between top-down (the ‘Why’ of the Business Model Canvas) and bottom-up (the ‘How’ and ‘With-What’ of Archimate’s Application and Infrastructure layers). This is also where enterprise-architects would be directly engaged in the development of business-strategy and its real-world implementation – the ‘seat at the table’ at the CxO level of the organisation that so many EAs seem to desire!

—-

So: that’s a suggested pattern and process for direct ‘translation’ between Business Model Canvas and a more whole-enterprise adaptation of Archimate, using Enterprise Canvas as an intermediate layer. There’s another ‘how-to’ to come, going in the other direction, to link Business Model Canvas ‘upward’ to the shared-enterprise, but that’s it for now.

Many thanks for sticking with it this far, anyway. And over to you, if you would?

[Note: this is a work-in-progress post, not a finished piece - I really do need discussion on this one!]

What’s come up this time is the usual struggle with the so-called ‘architectural layers’ in common EA frameworks such as TOGAF and Archimate:

• Business
• Applications (in Archimate) or Information Systems (in TOGAF)
• Infrastructure

The problem is that, for me, these are ridiculously incomplete, and lead directly to IT-centrism – where IT is deemed to be the sole centre and basis for everything. That IT-centrism what creates most of the much-lamented ‘business/IT-divide’.

The corollary is that, because IT is placed as the centre for everything, and applications only run on IT, everything else has to be lumped into ‘business-architecture’, because it’s the only place it can go. Hence in TOGAF, for example, high-level business-strategy is bundled together with mid-level process and detail-level manual work-instruction, without any kind of distinctions between them, solely because it’s ‘not-IT’. And technology and infrastructure that isn’t computer-based – lorries, fork-lift trucks, assembly-lines, plumbing and wiring and even the buildings within which everything operates – don’t even get a mention anywhere.

This brings serious problems even in IT-specific architectures: for example, how can we usefully describe the overall architecture of a data-centre without mentioning power-supply or cooling or access-pathways? What’s the point of arguing about instant-on virtualization for data-servers if it takes a minimum of six months to construct the building that houses them? How do we describe disaster-recovery processes for when the IT is out of action, when the only metamodels available to us can only describe IT? To anyone doing real enterprise-scope architecture in the real-world, the myopic inanity of IT-centrism gets really frustrating after a while…

Hence why I’ve been ranting and raging so much about the limitations of TOGAF and the like over the past few years. It’s not because I’m ‘anti-IT’ – as some people have dismissed me – but because I’m trying to get things to work in the real world. A messy, chaotic, uncertain world in which IT is often unreliable at best, irrelevant at worst, and which, for the most part, is not centred on IT. Sigh…

So, in short, the conventional concepts of so-called ‘business-architecture’ are an unusable mess, and the ‘application’ and ‘infrastructure’ so-called ‘layers’ are too narrow in scope to make practical sense for anything other than the most IT-centric of IT-architectures. Hence, also in short, not so much useless as probably worse-than-useless for most real-world purposes.

Which means that we need to start again. Properly.

But from where? Using what as the layers?

(Or do we even need layers at all? Is even the idea of ‘layers’ misleading?)

There’s the Zachman layers, of course: Contextual, Conceptual, Physical, Logical, Implementation, Operations. That does make practical sense as a description of the process of change, but perhaps not so much about the architecture itself – the interrelated, interconnected structure of that which is in use.

What about structural-decomposition – from abstract to detail? Well, yes, that’s useful, certainly, but it doesn’t really tell us much more than Zachman does, and doesn’t help us to differentiate between different kinds of ‘thing’ – the distinctions that come up, if somewhat erratically, in Zachman’s columns of What, How, Where, Who, When and Why.

The ‘Why’, though, does lead to another suggestion: Simon Sinek’s principle of ‘start with Why’, and its layering of Why, How and What.

Because if we start with Why, and tweak the ‘What’ slightly to ‘With What’, we end up with an almost exact match to the Archimate / TOGAF layering – but this time a layering that is not IT-centric. And which also lines up with key parts of the Business Model Canvas:

• Why? – about the choices and Value Propositions that drive ‘the business of the business’
• How? – about IT-applications, ‘manual’-processes and any other Key Activities that enact those choices and needs
• With What? – about any machines, equipment, buildings and other infrastructures and Key Resources upon which or through which those activities take place

At first glance this has some parallels to the long-established CapGemini ‘Integrated Architecture Framework‘ [IAF]:

(I have a vague recollection that there’s at least one more EA framework that uses a similar Why / How / With-What structure, but right now I can’t remember whose it is… – my apologies to that person, anyway.)

But if we look more closely at those layers in IAF, it’s clear that they’re just a re-labelling of Zachman layers, with the old TOGAF-style layers sideways-on, and deeper ‘cross-cutting themes’ such as security and governance further behind. (And actually that’s quite a good way to put it – which we’ll come back to in a moment.)

The point here is that if we use that Sinek-style categorisation of Why, How and With-What, we can cover just about anything that’s needed in the architecture: it doesn’t assume that the end-point is only about IT. And it still lines up well to Archimate: hence business-information (linked to Why) is represented in Archimate as a Business Object, its usage in processes (linked to How) is a Data Object, and its physical form (as a With What) is a Representation. Archimate doesn’t as yet have any entity to represent generic ‘physical Thing’ or ‘thing that flows through processes’ – such as we’d need to represent a parcel in a logistics context, for example – but the Why / How / With-What structure makes it easy to understand that Representation, Data Object and Business Object are just IT-oriented specialisations (in the UML sense) of each of the respective generic entities. It works.

But should we use layers at all – especially scope-defining layers such as ‘business’, ‘application’ and ‘infrastructure’? In a sense, the IAF suggests not – any fixed notion of ‘layers’ is misleading. A better way to describe is to say that the ‘layers’ are merely areas of emphasis of attention: we separate those areas in order to ‘black-box’ the internals of an area of scope so as to focus our attention on the interfaces between those areas of attention. The IAF shows a very good way to visualise this, with sets of viewpoints that are in effect orthogonal to each other. The only problem there with the IAF is that, yet again, it constrains the overall scope to IT alone – which renders it too limited for whole-enterprise architecture. If we imagine that, rather than that catch-all column labelled ‘Business’, we could have as many columns as we need – and as many ‘backplanes’ that we might need, equivalent to the existing ‘Security’ and ‘Governance’ but covering all values in context for the enterprise – then something like IAF would make good sense.

I would suggest, though, that that simple categorisation would be a good place to start:

• Why – ‘business’
• How – ‘applications’
• With What - ‘infrastructure’

Use each of these not-quite-layers as a viewpoint for focus into the overall enterprise context, and use an adapted version of Archimate or an equivalent to model both within those ‘areas of interest’ and to explore the connections between them.

Okay, that’s it for now: over to you, if you would?