• rtolido: interesting stuff coming soon around a global Business Architect certification standard by The Open Group #ogsfo

Important to say here that I have enormous respect for Ron: quite apart from his senior role at CapGemini, he’s also an amazing innovator in IT-architecture and enterprise-architecture, with ideas such as Slow IT, the importance of a demolition strategy, and the SCOOTER metaphor. Yet I must admit I was absolutely horrified at that comment above, and said so:

• tetradian: @rtolido IT-centrism in TOGAF etc has crippled #entarch for half a decade: please don’t let OG do the same to #bizarch as well…

The point is that, given their track-record so far on business-architecture,  I can hardly think of any organisation that’s less qualified than Open Group to create such a standard. For Pete’s sake, even the Piddletrenthide Parish Parent-Teacher Panel would probably do a better job of it…

And no, I’m not being nasty here – I’m serious about this. The utter shambles that is TOGAF’s ‘Phase B: Business Architecture’ should sound clangorous alarm-bells about any such suggestion: it’s just a random collection of ‘anything not-IT that might affect IT’, with no structure, no symmetry and no sense. If you want to see how so much of so-called ‘enterprise’-architecture actively increases the infamous ‘business/IT-divide’, you need only to take a careful look at the TOGAF specification for its ADM Phase B. And these people seriously consider themselves competent to define a global certification for business-architecture? No way! – please…?

Anyway, my Tweet-response above triggered a reply from Ron:

• rtolido: @tetradian it’s an IT thing to criticize IT-centrism but after all: #entarch is an IT people invention. Let’s try to do better with #bizarch

To which my first response was ‘What the…?‘, which came out in more polite form on Twitter as this:

• tetradian: @rtolido “it’s an IT thing… entarch is IT-invention” – disagree on both counts, but yes, please let’s do better with bizarch…

Let’s tackle Ron’s points in reverse order…

At least there’s an acknowledgement that we could do better with business-architecture than has been done with those current attempts at ‘enterprise’-architecture. That’s something. Good.

On “#entarch is an IT-people invention”, it isn’t. That’s a convenient myth that IT-people want to believe – though no doubt a fair few of them will want to throw various historical quotes at me to ‘prove’ their provenance. Sure, the term ‘architecture’ has long since been linked to IT – almost half a century, by now. And somewhen around a couple of decades back, some bright spark extended that idea to distinguish between a context-specific IT-architecture versus an IT-architecture at organisation-wide or enterprise-wide scope, as ‘enterprise-wide IT-architecture’ – at which point some idiot conflated that nominally-valid term to a no-doubt ‘simpler’ shorthand term as ‘enterprise-architecture’, without any awareness of just how misleading that would be, or how much damage that term-hijack would cause. Yet reality is that there are many long-established business disciplines such as systems-thinking and design-thinking as applied to the enterprise that have a much better natural fit with the term ‘enterprise-architecture’; the original meaning of ‘business-analysis’ was also probably very close, too. In short, ‘enterprise IT-architecture’ is arguably “an IT-people invention”; but enterprise-architecture most definitely is not.

On “it’s a IT thing to criticise IT-centrism”, I’m not quite sure what Ron means there – whether only ‘IT-people’ have the right to do so, or else that anyone criticising IT-centrism is inherently self-identifying as an ‘IT-person’. If it’s the former, then the fact that I’ve had perhaps 30 years experience in and around IT might qualify me to criticise? But more to the point, my background is as an explicit cross-discipline generalist – I’m one of the few people formally qualified as such, with an MA in General Studies from London’s Royal College of Art. And it’s in that sense, as a long-experienced practitioner of ‘design-thinking’ within a very wide variety of business contexts, that I see IT-centrism as such a problem. (And, for that matter, business-centrism – which I’ll come back to in a moment.) In terms focus of attention, the single most important fact in enterprise-architecture, or business-architecture, or any other architecture, is this:

Within any architecture, everywhere and nowhere is ‘the centre’, all at the same time.

What happens in any form of ‘-centrism’ is that we keep on being dragged back to some specific area that claims to be ‘The Centre’ of the architecture. Rather than an ‘outside-in’ view – an awareness of the whole – we’re constrained to an ‘inside-out’ view, where everything in the architecture is seen only in relation to and in terms of that single ‘The Centre’. If there is no direct connection to that ‘The Centre’, or no direct impact, whatever-it-is is usually dismissed as ‘out of scope’, and often deemed not even to exist. Hence, in TOGAF’s inherently ‘inside-out’ view – in which IT-infrastructure is its actual ‘The Centre’ – we have no means to describe anything that is not-IT and that does not in some way impact directly on IT.

[To illustrate the point, try using TOGAF or its linked Archimate-notation to describe the physical activity of a production-line, the trucks and conveyor belts and other machines of physical logistics, the human activity of paper-based record-keeping, or the physical infrastructure - cooling, power-supplies and suchlike - of an IT data-centre: if you can do it all, you'll have to use some horrible kludges and fudged reframings of the supposed standards in order to do it... And yet all of these things would be essential in an enterprise-architecture for the respective industry.]

I need to reiterate that it isn’t only IT-centrism that creates this kind of problem: it’s any-centrism. What I’ve also been seeing recently is a lot more ‘business-centrism’ in enterprise-architectures, where ‘the business of the business’ is taken to be ‘The Centre’ of the enterprise-architecture. We see this, for example, in the insistence that financial metrics are the only metrics that count, and that return-on-investment (ROI) and the like can only be measured in financial terms – which might be valid within certain subsets of business-architecture, but are way too constrained to be valid in the far broader scope of enterprise-architecture. In some ways this trend worries me even more than IT-centrism, because by the nature of business it will tend to have even more of the wrong kind of credibility, making that much harder to counterbalance and correct within the architecture.

Anyway, Peter Bakker dropped in a useful comment at this point, pointing to a classic early essay by Christopher Alexander, famed author of A Pattern Language:

• pbmobi: @rtolido @tetradian #entarch & #bizarch just see the trees, we need architects who see the semi-lattices http://www.chrisgagern.de/Media/A_City_is_not_a_tree.pdf #ogsfo

• taotwit: @tetradian @rtolido erm.. Tom I think you’re mixing up what EA is with what should be!
• tetradian: @taotwit @rtolido if someone’s defining a new standard, surely it should be about what should be, not about preserving current mistakes?
• taotwit: @tetradian @rtolido good point – I hope they listen to the likes of Alec Sharp and Patrick Hoverstadt

Agreed with Nigel there: a business-architecture certification scheme would need input from people like Alec or Patrick, or likewise from other key figures in business-architecture or business-innovation such as Alex Osterwalder or Steve Blank. But, like me, none of them are members of Open Group – which means that not only do we not have a voice, but what we say will be ignored anyway. In other words, Open Group expressly locks out many of the people who are doing real innovation in business-architecture, and then wonders why there are real doubts about the usefulness or validity of what it then produces as its ‘standard’.

Which brings us to the disaster-area of certification. In principle it’s a good idea, even a very necessary idea: every profession needs some way to identify and validate core knowledge and the like. But when the certification for a discipline is managed by a group that evidently do not understand what that core-knowledge actually needs to be, then we have a problem… and that’s exactly what we have with Open Group and business-architecture.

Open Group are an IT-standards body: and they’re very, very good at what they do in IT. But they’re not a general business-standards body – and that fact is becoming extremely important here. In the days when TOGAF was solely about IT-architecture – as it was up until version 7 – then it made sense for the ‘enterprise IT-architecture’ standard to be maintained by the Open Group. But the problem with any enterprise-scope architecture is that, by definition, you have to take everything in the enterprise into account: hence an expansion out into data- and applications-architectures in TOGAF 8, and then, in TOGAF 8.1 ‘Enterprise Edition’, the addition of a loosely-defined ‘anything not-IT that might affect IT’. Unfortunately they made two fundamental errors at that point: because that random bundle represented IT’s view of what it called ‘the business’, they labelled it ‘Business Architecture’; and they then described the whole IT-specific structure as ‘Enterprise Architecture’ – both of which sort-of made sense from their own inside-out perspective, but made no sense to anyone else, especially when looking outside-in. Oops…

Anyway, back to certification. So first, there is a real value in having a common language for specific types of architecture. In that sense, the TOGAF 9 ‘Foundation’ certification is genuinely useful, because it tests knowledge of that common language.

Likewise the practitioner-certifications such as ITAC, which assess someone’s practical skills and competence. Unfortunately it’s no use to me, though, as it still assumes that the only possible path to enterprise-architecture is via detail-level IT-infrastructure architecture, which I don’t do and never have. (I’ve done a lot of mainstream data-architecture in my time, but that doesn’t towards ITAC certification either.)

But to my mind – and in my experience, too – the mid-level certification, ‘TOGAF Certified’, is actually worse than useless: to be blunt, it’s almost a measure of how much someone is not competent to do enterprise-architecture. Yikes… there are some serious problems there…

That perhaps sounds a bit harsh: it’s not. There are two interlinked reasons why this is so.

The first is that ‘TOGAF Certified’ is a content-based exam. All it tests is how well people know the TOGAF specification – not architecture-practice. And to be blunt, the TOGAF specification is a long way from what’s needed to do enterprise-architecture – especially in any industry other than ‘the usual suspects’ of banking, finance, insurance, tax. (Why those industries? Because their business-models are built almost entirely around large volumes of simple structured information with automatable business-processes – in other words, strongly IT-oriented. Which doesn’t apply to most other industries.) I almost failed my TOGAF 8.1 exam because I answered several questions in terms of what I knew worked in practice, rather than what’s written in the book. And the ‘correct’ answer in the book was just plain wrong: I knew from real-world practice that it was exactly what not to do. Needless to say, I wasn’t impressed when I was penalised in the exam for doing it right…

The second reason is that TOGAF is not a standard. This isn’t some arbitrarily-unkind assertion that I’m making: it’s not only common knowledge, but I’ve even heard several senior Open Group figures say so in public. (Exact quote: “Of course no-one uses TOGAF out of the box! – we always have to customise it one way or another”.) The best way to describe TOGAF is that it’s a somewhat-better-than-random cookbook of ideas and practices vaguely held together by a almost equally-vague structure of the Architecture Development Method [ADM] – and that’s it. There’s not much guidance in TOGAF itself on how to customise TOGAF: you get that from experience, with a bit of help from some of the better training-providers.

So what we have at present in the ‘TOGAF Certified’ exam is a way-too-simplistic multiple-choice test on the supposed content of a ‘standard’ that actually isn’t a standard and often doesn’t match up at all well with real-world practice anyway. So just how much use do you think that’s going to be? To anyone? Honestly? Hmm…

And given that, how much credence would you place on a certification-scheme by the same people on a domain which they demonstrably don’t understand much if at all, judging by the current content of TOGAF’s ‘Phase B: Business Architecture’? Oops…

Hence why I’m extremely wary of letting this current attempt by Open Group go unchallenged: they really are almost the least-appropriate group to do the job.

No question at all that we do need some very good work to happen on business-architecture, and urgently so. But please, not from Open Group? – at the very least, not until they’ve tidied up the utter shambles of ‘Business Architecture’ in the current TOGAF, and can demonstrate that that they can keep their reflex IT-centrism under better control than at present?

Sigh… Oh well… back to the grindstone, I guess…

Over to you for comment or whatever, anyway.

• togaf_r: TOGAF Resource: The TOGAF 9.1 changes overview and 6 other slide decks are now at http://t.co/Arm40mgA (free PDF) #ogsfo

The link points to the Open Group’s ‘public resources’ website for TOGAF (The Open Group Architecture Framework), which includes the respective slidedecks.

One of those slidedecks is ‘TOGAF Version 9.1 Management Overview‘ [PDF] – which turns out to be an interesting illustration of exactly how IT-centrism creeps into enterprise-architecture…

We’ll start with slide 18 (lower part of p.9):

What is an Enterprise?

• A collection of organizations that share a common set of goals

– Government agency

– Part of a corporation

– Corporation

• Large corporations may comprise multiple enterprises

• May be an “extended enterprise” including partners, suppliers and customers

They don’t give the source for that definition, but it’s one I’ve seen elsewhere – I think it’s used in FEAF, for example. Importantly, this definition explicitly does not regard ‘organisation’ and ‘enterprise’ as synonyms. In my view it doesn’t go far enough in that separation, but at least it’s clear that there is a difference, and that ‘the enterprise’ often extends well beyond the boundaries of ‘the organisation’. In short, so far so good.

Next, look at slide 19 (upper part of p.10):

What is an Architecture?
• An Architecture is the fundamental organization of something, embodied in:
– its components,
– their relationships to each other and the environment,
– and the principles governing its design and evolution.

As they say on the slide, that definition is adapted from ANSI/IEEE Standard 1471-2000, another well-known and much-used reference. Again, so far so good.

But note what happens in slide 20 (lower part of p.10), which purports to bring together those previous two definitions:

What is Enterprise Architecture?
Enterprise Architecture is:
• The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. [MIT Center for Information Systems Research]
• A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. [SearchCIO.com]

Which for me brings up an instant response of  ”Huh? Now wait a minute?”… The SearchCIO definition would make reasonable sense if it wasn’t arbitrarily constrained only to the view of the organisation – not the enterprise, as per that previous definition of ‘enterprise’. And in the MIT definition it’s constrained even further, with an unexplained emphasis on IT-infrastructure and “integration and standardization” – which doesn’t make sense at all.

One slide further on, and without any explanation or justification, we’re suddenly down in classic TOGAF territory, where the foundation for everything is IT-infrastructure, and where ‘Business Architecture’ is ‘anything not-IT that might affect IT’. Oops…

And by the time we get to slide 22 (lower part of p.11), we’re presented with this:

Why Enterprise Architecture?
• Effective management and exploitation of information through IT is key to business success
• Good information management = competitive advantage
• Current IT systems do not really meet the needs of business
– Fragmented, duplicated
– Poorly understood
– Not responsive to change
• Investment in Information Technology
– Focussed on system maintenance
– Tactical developments rather than a strategic plan

All I can say to that is “You what???”… To be blunt, what has any of this got to do with enterprise-architecture, in terms of the definitions of either ‘enterprise’ or ‘architecture’ above? “Some but not much”, is the short answer. To illustrate the point, let’s deconstruct some of those assertions above:

–  ”Effective management and exploitation of information through IT is key to business success” – is it? Can you prove this? Given this arbitrary assertion about the importance of IT, can you show the connection – if any – to either ‘enterprise’ or ‘architecture’? And what do you mean by ‘IT’ anyway?

– “Good information management = competitive advantage” – possibly. But what about government and other organisations for whom ‘competitive advantage’ has little or no priority or point? And what about all the other non-IT issues – such as respect and trust – that might have far greater impacts on ‘competitive advantage’?

– “Current IT systems do not really meet the needs of business” – so what? The same is true of many other business-systems, such as the structure and design of core business models – which, architecturally speaking, would usually need to come before any fix-up of outdated IT-systems.

– “Investment in Information Technology [maintenance focus, tactical]” – again, yes, we know, but so what? The same is likely to be true about almost every other aspect of the enterprise – especially in multi-partner enterprises.

So let’s again be blunt about this: that slide above is best dismissed as mere marketing-puff – a sales pitch for large consultancies who want to sell ‘IT-rationalisation’ programmes to clean up the IT-mess that in all probability they themselves had created in the first place… In practice, there’s so much that’s missing from that ‘Why Enterprise Architecture?’ – such arbitrary and unjustifiable constraints on scope – that it really is all but meaningless. It describes only a tiny subset of the actual scope of ‘the architecture of the enterprise’, but somehow seems to purport that this is the whole. Which would be laughable if it wasn’t such a bad joke – or such a destructive one.

In other words, somewhere between slide 19 and slide 22, we’ve gone from enterprise and business, to a largely-spurious attempt at business-justification for one specific subset of enterprise IT-architecture. The remainder of ‘the architecture of the enterprise’ – especially about anything not-IT – has been erased from the story.

Which is why the TOGAF-style EA story just does not make sense to anyone who’s not already embedded and wedded to an IT-centric view of the world.

If you want to see how and why enterprise-architecture is still such a darned hard ‘sell’ to just about anyone in business, all you need to do is read that ‘Management Overview’. And quietly weep…

Surely by now we can do better than this? Please?

• tetradian: RT @theopengroup: On @infomgmt about “Getting Holistic with Enterprise Architecture” http://shar.es/fWDYZ >strong recommend #entarch

To me the article is a very good illustration of the crucial distinction between IT-oriented versus IT-centric.

In essence, the whole interview is all about IT, and IT-education: nothing much more than that. And parts of it show the usual IT-type errors, such as ‘information-systems’ solely in terms of software and the like, without any apparent reference to the human side of information. And it doesn’t exactly off all that well, either:

We have a pretty strong and broad curriculum, the students get several different programming classes, good grounding in network technology and database technology and software.

Which is not exactly what those of us in whole-enterprise architecture would be likely to regard as a ‘broad curriculum’. At first glance, it can seem so much “Oh no, not again…” that I wasn’t much surprised when a colleague complained at me for reTweeting it in such glowing terms.

Yet there are several points that make it stand out from the crowd. Keppleman continues the above with these comments (with the interviewer’s question in italic):

But we also try to bring in the big picture, how it really fits together. Though most of our students take entry-level jobs working on a particular project or part of a system, whether it’s infrastructure or software or some combination, we want them to leave with some sense that the things they work on are actually part of a much larger enterprise. That piece they are working on needs to be not just a good piece, but a great piece that creates value for the whole.

That sounds like a sales pitch for enterprise architecture.

Yes, and in my career it came to me backwards, too. My original focus was software development and obviously the importance of getting the requirements right. Well, it turns out that to have the requirements right, you need what you are working on in the context of the whole because otherwise you might build a great system but it doesn’t create value. It might be adding redundancy or be the 73rd system to connect 72 other systems. Even if those other 72 systems are part of stovepiped business units and are perfectly aligned with them and serve their needs, as a whole the enterprise is wasting a ton of money and a ton of resources and talent. That experience is what brought me to the enterprise architecture space.

The way I read that is that whatever you’re doing in software or whatever, there’s no point in doing it if it doesn’t support the overall big-picture. Whatever we’re doing, it’s always part of the whole – so we have to be aware of the whole, at all times. Hence the need for enterprise-architecture – which, as can be seen from above, has to be a real ‘architecture of the enterprise’.

In many people’s view of ‘enterprise’-architecture, IT presents itself as the centre of the business-world, the one undisputed core around which everything else revolves. ‘The business’, if mentioned at all, is described solely in terms of ‘anything not-IT that might affect IT’. (If you don’t believe me, go ask anyone not from IT whether TOGAF’s so-called ‘Business Architecture’ makes any sense to them in business terms…) That’s IT-centrism, and it’s a really serious problem in current enterprise-architecture.

But the article above, and the overall mood of the piece, is not IT-centric.

Sure, it’s unashamedly IT-oriented – no doubt about that. Dr Keppleman’s unit is nominally part of a business-school, but as he says, “most of our students take entry-level jobs working on a particular project or part of a system… infrastructure or software or some combination”.  (There’s a mild mis-labelling there, perhaps – it’s not what many of us would think of as ‘business’ – but that’s about the worst that I can see of it.) It is what it is: it’s just IT – and it doesn’t really claim to be anything else.

And yet it does maintain a broader awareness beyond itself. It’s clear that IT is seen as an important role, yet also that it’s just one part amongst many within that greater whole:

“…help us change how we work together and communicate within organizations to be more integrated, more holistic”.

I’ll admit that I really don’t like IT-centrism: it’s been the bane of the EA industry for far too many years. But I’m definitely not ‘against IT’, as some people have portrayed me to be. In a true ‘architecture of the enterprise’, everything matters, in depth as well as in breadth: so I’m very happy to see a piece that’s as IT-oriented as this, and yet does also know how to play its part within them whole.

IT-oriented is not the same as IT-centric.

This one starts with a ‘rant’ (as he put it) by Anders Jensen, about the ongoing hype over (gosh!) ‘the Cloud’:

• aojensen: As phk of FreeBSD says: #cloud is no different to the IBM mainframe. // It puzzles me why so many people put #entarch and #cloud in the same tweet. The former is a mgmt function, the latter a tech concern. // In other words, #cloud is a solution pattern and delivery mechanism. #entarch is about systemic management of all of the enterprise. // Thus, #cloud architect is nothing but a fancy word for solution architect. // Okay, rant over. #entarch

• tetradian: @aojensen: “puzzles me why .. people put #entarch and #cloud in same tweet” – is valid if about enterprise strategy or strategy-to-tactics
• aojensen: @tetradian true, but then it is still a delivery mechanism realising a certain strategic/emergent intent.

• tetradian: @aojensen for viable biz-strategy, #cloud needs #entarch much more than entarch needs cloud – cloud can be biz-lethal without proper entarch
• dougnewdick: @tetradian @aojensen couldn’t agree with Tom more – whether you are talking EITA or “proper” EA

And Doug Newdick is right here, too: this isn’t just a ‘real-EA’ issue. It applies just as much to an IT-oriented or even IT-centric ‘enterprise’-architecture, because it’s about the organisation’s strategy for managing its business-critical information.

I’ve seen some people – okay, probably only the most hype-ridden and IT-obsessed, admittedly – who’ve argued that the availability of cloud-storage and cloud-based applications means there’s now no need for any enterprise-architecture. Let’s just be blunt about this: that’s dumb. Stupid – seriously stupid. Demonstrates an almost complete inability to grasp the role of enterprise-architecture – and probably of the role of cloud, for that matter. Various other irritated epithets… definitely worthy of Anders’ ‘rant’… mumble mumble grumble grrr…

Okay, back off for a moment. Cool down, Thomas. Etcetera…

For the moment, let’s just assume a ‘classic’ TOGAF-style ‘enterprise’-architecture, focussed solely on IT. (It’s perfectly adequate for this purpose, so for once I’m not going to complain about ‘IT-centrism’ etc here. ) It has four distinct domains: IT-infrastructure, Applications, Data, and ‘Business’, which in essence is a ‘none-of-the-above’ relative to the other three IT-specific domains. Let’s assume, then, that we now believe the cloud hype, and hence that we can do everything via the cloud:

• IT-infrastructure: don’t need any, it’s all ‘bring your own IT’
• Applications: don’t need any, it’s all in the cloud, accessed via browsers and apps
• Data: don’t need to define any, it’s all defined in the cloud
• ‘Business’ (process-workflows, business-models etc): we can build it all around what’s already available in the cloud

So: get rid of the IT-department, because there’s nothing for them to do any more. And get rid of all the enterprise-architects, because they’re just part of the IT-department that we don’t need any more. Simple, right? Huge savings in costs, too.

Hmm. Right. Let’s take just a few points that are missed in those glib assertions above:

• Who’s going to test the apps on all that range of different hardware and software and screen-resolutions and everything else?
• Who’s going to help people when their ‘bring your own IT’ doesn’t work?
• Who’s going to help people understand how to access those cloud-apps, to understand the security-issues, and why leaving their iPhone in a cab could be a lot more serious than just the loss of a few of today’s Tweets?
• Who’s going to choose which apps to use? Why will they choose those apps, from which providers?
• Who’s going to design the workflows that bridge between all the different apps? Who will be responsible for the end-to-end business processes that jump around between different apps and different cloud-providers?
• Who’s going to identify the business-metrics that bridge across those end-to-end business-processes? How will you gather those metrics, and ensure that they make business sense?
• Who’s going to manage the reverse-backup, where you back up your own cloud-data in local storage? Who is going to be responsible for information-security, for end-to-end business-continuity and disaster-recovery, for escrow and recovery when (not ‘if’) one of your cloud-providers goes out of business, or when (not ‘if’) one of your providers starts getting too greedy, or for deciding what to do when your cloud-provider is taken over by one of your own competitors?

That list goes on, and on, and on, and on: and you won’t be able to answer many, if any, of those questions, without a solid enterprise-architecture. You’ll probably discover that you do indeed need that IT-department, too – a lot more than you’d realised. Oops… perhaps throwing everything into the cloud isn’t such a good idea after all…

(There’s not much difference between this IT-oriented analysis and one coming from a ‘real-EA’ perspective. The latter would cover a rather wider scope that’d throw up yet more crucial issues that cloud-providers, uh, somehow seem to forget to mention, but that’s about all, really.)

The key point is this: cloud is just another outsourcing arrangement. Anders is right: in many ways it’s just a reversion to the IBM ‘data-processing’ bureaus of half a century ago – brought up to date a bit, of course, and with a few more fancy bells-and-whistles such as ‘access by anyone from just about anywhere’, but otherwise the core principles are almost exactly the same.

So if it’s ‘just another outsourcing arrangement’, we need to handle it architecturally much as for any other outsourcing arrangement. In other words:

• Never outsource your business-vision.
• Never outsource your strategy.
• Never outsource your business-critical information – and especially, never outsource the ownership or control of your business-critical information.
• Know what you’re getting into, and why.
• Know what it will cost, in every sense – including all of the myriad hidden costs that no-one seems to notice until too late.
• Know what rules and regulations apply, under which jurisdictions.
• Know how to ensure alignment between your organisation’s business vision and values, and those of the outsourcing provider.
• Know how to ensure customer ‘single-view’, end-to-end continuity and suchlike whole-enterprise requirements.
• Know who’s responsible for what, when, where, how and why – and how to plug the inevitable gaps between boundaries of responsibility across the overall partly-outsourced business-structure.
• Know what can go wrong, and what impact each type of ‘going wrong’ could have.
• Know what to do when (not ‘if’) things go wrong.
• Know how to get out of what you’re getting into.

(That’s another list that goes on and on, too… and again, that’s why enterprise-architecture exists, to help you resolve each item on that list.)

What’s scary is the number of business-folks and IT-folks who’ve never even looked at that list, for any kind of outsourcing arrangement: they seem to buy into all of the sales-hype of the latest ‘fad-du-jour‘ instead, and apparently just hope for the best… Perhaps not the wisest strategy, shall we say?

There’s no question that cloud is great for a typical start-up – because there you do usually have to outsource everything you can, to keep the initial costs right down. Yet in a more mature business, things get radically different. Sure, you can scale cloud-apps themselves, and data-storage in the cloud, and so on. But not the way in which information itself is used across a 5,000-person company: that’s a different ball-game entirely.

What we find in practice is that, yes, some parts of the business do still need to be as nimble as any start-up – and hence, at first glance, would be seem to be ideal candidates for cloud-apps and the like. But some parts of the business need to be very stable, in some cases for decades or more – as in health, for example, or retail-banking, or some aspects of pharmaceuticals, or some types of engineering. After half a century and more of IT practice in organisations large and small, we do know how to manage that kind of data, those kinds of processes – and one of the things that that tells is that those kinds of requirements are not a good fit for cloud. And it’s different for every industry, every organisation, every size of organisation – whereas the best that most cloud-providers seem to offer is a kind of vaguely-customisable one-app-fits-all which in some ways combines all of the disadvantages of the different options with almost none of the advantages, other than some surface-layer cost-savings that may well evaporate and worse once Reality Department barges its way into the real picture. Hmm… Tricky, that…

To make it even more difficult, most large organisations have organisation-specific taxonomies and schemas that do need to be enforced across all usages throughout the business – which may well not be supported in the kind of prepackaged schemas offered by many providers. As a result, we’d have to do some potentially-tangled to-and-fro translations between the internal schemas, and the providers’ schemas – all of which is doable, of course, but increases the cost and the risk-potential, and reduces the actual savings from the outsourcing arrangement.

To make sense of all of this, we need a solid understanding of backbone versus edge – of what must be maintained strictly according to standard, or what must be managed internally for strategic reasons, versus what can be much more freeform; and the transitions and translations and governance-issues between them; and how all of the respective choices are guided in turn by enterprise-strategy. Which, again, is where a solid enterprise-architecture really needs to be part of this outsourcing picture.

Which brings us back to Anders’ point with which we started: cloud is ‘just another outsourcing-arrangement’. And as with any other outsourcing arrangement, the business needs a solid strategic understanding of all the implications of that outsourcing-arrangement – its potential advantages and disadvantages, its costs and revenue-possibilities, its opportunities and risks, its impacts on business-processes, and much, much more. And almost the only way to identify whether that outsourcing arrangement does or does not make strategic sense is via a well-described enterprise-scope architecture-description, fully linked to enterprise strategy.

Outsourcing everything – or anything, actually - to the cloud could be lethal to the business: yet without a proper enterprise-architecture, there’s no way to know what is a risk, and what is not. As Anders says, cloud is just a solution-pattern: there are usually plenty of other options that can be used instead. But enterprise-architecture is a management-function, a strategic function: not wise to try to run a business without it…

So cloud isn’t actually necessary to any business: but an enterprise-architecture certainly is. In that sense, cloud needs enterprise-architecture much more than enterprise-architecture needs cloud. Might be useful for everyone if some of the current clutter of cloud hype-merchants were a bit more willing to grasp that point?

• tetradian: [post] IT-centrism is killing enterprise-architecture http://bit.ly/p8kfqf (thx @dougnewdick) #entarch
• tonia_ries: The only thing that should be at the center of any business is the customer. @krcraft @tetradian
• krcraft: Agree, if staff also inc. as customers RT @tonia_ries The only thing that should be at the center of any business is the customer @tetradian
• Tim_Flux: @tetradian I think 1 of IT-centrisms problems is, those guilty of it dont recognise it (in themselves), so will not respond to your argument
• tetradian: @Tim_Flux IT-centrism as ‘invisible to self’ – yes, unfortunately, very true (applies to all ‘-centrisms’, of course)
• chrisdpotts: The ‘centricity’ issue in #entarch: it is usually capital-centric, not enterprise-centric (economics; RecrEAtion) // A strategy of stopping all capital-centric #entarch has extremely low chance of success!  Better to demonstrate the alternatives.

But then a follow-on comment by Doug Newdick triggered a really good discussion around business-centrism, capability and process, with Doug, Alec Sharp, Kris Meukens, Chris Bird and others all diving in:

• dougnewdick: Excellent post RT @tetradian: [post] IT-centrism is killing enterprise-architecture http://bit.ly/p8kfqf (thx @dougnewdick) #entarch // @tetradian Hi Tom – that post is excellent, and I think much better for being more moderate in tone, though still passionate
• alecsharp: @dougnewdick @tetradian Tom – I’ve grabbed your post, and will read it with interest. It’s a topic much on my mind these days… // Frustrated by EAs who confuse the scene with “capabilities” (business processs) in trying to be “business oriented” // Most fields are guilty of reinventing (and renaming) the wheel, but EA has really done a disservice in recent years
• dougnewdick: @alecsharp You don’t like the term “business capability”? Or just the way it is used?
• alecsharp: @dougnewdick “Capability” is fine to describe abilities of a person or org. EA use of Biz Cap’y is indistinguishable from process // I have clients in a serious mess due to EA groups tossing BC into the mix when a process arch. was already in place
• dougnewdick: @alecsharp I suppose that if you had a good process arch in place, there’d be less need for business capability map // however I think business capability is a good way to describe something more than process: ability to deliver outcomes
• alecsharp: @dougnewdick I think the “business capability” concept is redundant – indistinguishable from process (which was there first.) // I can’t agree – a business process is nothing but a way to deliver an intended outcome. // MIke Rosen’s BPTrends article (inadvertently) demonstrated that “capabilities” are exactly the same as biz processes
• dougnewdick: @alecsharp You’d be proved right if capability analysis + process analysis gave the same answers, & I haven’t done that exercise // how do you address the qn of whether we have the right people with the right skills to do “x”? Surely not a process qn
• alecsharp: @dougnewdick My observation is they’re very close – the difference is in the rigor of the analyst, not the concept. // But that was my earlier point – “capability” is appropriate if describing abilities/skills of ppl and orgs… // … but all the “capability models” I see don’t address that, they describe processes… // …in my f’work, “skills” (HR) is an “enabler” along with IT, workflow design, motivation, policies/rules, workspace
• krismeukens: @alecsharp @dougnewdick business process is an ordered way to deliver outcome, but there are unordered ways as well // capability captures both, ordered and unordered
• alecsharp: @krismeukens @dougnewdick Disagree – business process spans the range, from transactional to totally unstructured // I think the problem we have in the BP field is that “automated workflow” is equated to “process”
• dougnewdick: @alecsharp Aha! You have explained my unease w many bus cap maps I’ve seen. They’re just process & I was expecting something else
• krismeukens: @alecsharp @dougnewdick people think of process as being linear and deterministic, I don’t like process as the catch-all term
• alecsharp: @dougnewdick Precisely! Orgs obviously need “capabilties” but they are different than “what the org does” which is processes
• krismeukens: @alecsharp @dougnewdick @tetradian the dangers is in what @snowded warns for: our favourite sense-making tool being used for anything
• alecsharp: @krismeukens @dougnewdick I agree that ppl often assume “process” is linear activity, but “capability” is even more open-ended // That’s why I have a kit full of sense-making tools. I’ll stand by what I’ve observed… // …which is that most capabilites I’ve seen EAs define aren’t, and cause much confusion as a result
• krismeukens: @alecsharp @dougnewdick agree, many misuses. I see capability as “what” one is capable of, process as a “how” to realize it
• alecsharp: @krismeukens @dougnewdick Understood. I see process as first being “what” (“Acquire Customer”) and then “how” (steps & decisions)
• dougnewdick: @alecsharp @krismeukens I’d agree with Kris capability = “what”, but also like Alec’s def’n of it as the “skill” of an org
• alecsharp: @krismeukens @dougnewdick I see capability as (surprise!) ability that enables process. That said, it’s hard to differentiate // In my framework, process is the “what” and a workflow (+sys, procedures, …) might be a one “how.” // I’m just sensitive because of hours spent trying to sort it out at clients.
• dougnewdick: @alecsharp @krismeukens Thanks for asking the hard questions Alec – I think I need to go away and think about this some more
• alecsharp: @dougnewdick @krismeukens I enjoyed the conv’n and learned from it. Wish we were all gathered around a whiteboard. Thx, Twitter!
• kdierc: @alecsharp @dougnewdick @krismeukens a twitboard?
• seabird20: @alecsharp @dougnewdick @krismeukens can I make the assumption that capabilities are what the org has available to do processes?
• alecsharp: @seabird20 @dougnewdick @krismeukens That’s how I’d see it. Not “we need the capability to Acquire Customer” – the process itself // There’s a process (what), how it’s done, & supporting enablers: tech, abilities, facilities,
• seabird20: @alecsharp @dougnewdick OK, then resource vs capability?
• alecsharp: @seabird20 @dougnewdick @krismeukens Ack! Resource and capability. What are you, Dick Cheney? My head is exploding…
• dougnewdick: @alecsharp @seabird20 @krismeukens My POV – Capability = the “what” of an org. We execute that using comb of people/process/tech
• krismeukens: @alecsharp @dougnewdick with a fractal organization that could work

Rather embarrassingly, it ended with various people thanking me for the conversation, when I hadn’t even been there:

• dougnewdick: Thanks @alecsharp @tetradian @krismeukens @seabird20 for the great conversations today!
• ebuise: @dougnewdick @alecsharp @tetradian @krismeukens @seabird20 Thanks for a much needed discussion! (apol. for all RT’s, but you trapped me)
• alecsharp: @ebuise @dougnewdick @tetradian @krismeukens @seabird20 Fun discussion. Now to read Tom’s post – he started it all! 
• tetradian: @dougnewdick @alecsharp @krismeukens @seabird20 @ebuise apols that i’ve not been in the capabilities conv – have been offline most of today

For the record, my own opinion is probably closest to Alec’s:

• a capability is the ability to do something, to some identifiable level of skill, as embedded in a machine, an IT-application and/or a real person
• a function is a conceptual ‘place’ or ‘space’ within which things are changed in accordance with specific business-rules etc with an identifiable interface or protocol, in accordance with an identifiable ‘contract’ or service-agreement
• a service is a linking-together of capability and function to provide the ability to deliver a specific outcome
• a process is a path that links together a sequence of service-transactions (where the service may be either predefined or not – Sigurd Rinde‘s ‘Easily Repeatable Processes’ and ‘Barely Repeatable Processes’), to create a desired set of changes in something

More details on this framework reference-sheet, if anyone’s interested.

Great conversation, anyway – many thanks, folks!

But the real point is this: IT-centrism is killing enterprise-architecture. Gartner made that clear some months back (apologies, can’t find the link…) in their ‘Hype Curve’ on EA: the IT-centric view of EA is increasing the ‘business-IT divide’, not reducing it. And as IT necessarily becomes more and more interwoven into everyday business, that IT-centrism is triggering a serious pushback from everyone else. Sure, if we’re in ‘the trade’, it demands our attention, but we’ve indulged it now for far too long: the blunt fact is that the obsessive IT-centrism of too many – especially amongst the ‘big players’ - must stop, and stop now, or else there will be nothing left. It really is as serious as that.

First, though, I ought to acknowledge some of the Twitter-stream that came up in response to that last post:

• dougnewdick: Good points w/o the invective RT @tetradian: [post] How not to define business-architecture… http://bit.ly/p0mITZ #entarch #bizarch #togaf
• tetradian: @dougnewdick point taken about ‘invective’ – but how on earth else do we stop Open Group from trashing the industry yet again…?
• dougnewdick: @tetradian I think that you weaken your case and alienate some of your potential audience with the invective. // I think you stop them by publishing a compelling counter-arg that respects all. I’m an enterprise IT arch & I’m listening 2 u
• tetradian: @dougnewdick yeah, I do know… – but after 5 solid years of repeatedly ‘publishing a compelling counter-argument’ it gets a bit wearing
• dougnewdick: @tetradian fair call!  - but I’m starting here
• tetradian: @dougnewdick other point is that that arrogant IT-centrism is really annoying to non-IT folks – it’s causing a lot of damage to #entarch
• dougnewdick: @tetradian That’s a good point too. My POV is that non-arrogant bus-centric EITA is a good place to start and try to get a seat at the table
• tetradian: @dougnewdick strong agree: ‘non-arrogant bus-[oriented] EITA’ is essential – and ‘non-arrogant’ creates space for seat at table

There’s also a useful comment from Stuart Boardman back on the previous post.

What do I mean by ‘IT-centrism’? It’s the assumption (usually implicit) that IT is not only the centre of our own world and work (which is fair enough if we work in IT), but also necessarily the centre of everyone else’s as well (which is not ‘fair enough’). It’s the attitude that for every possible business problem, there is always an IT-solution; and that that solution will always be the ‘best’ solution, simply and solely because it’s IT. It’s the assumption that there are no limitations to IT, that it alone offers the golden dream of perfect control – and therefore has the ‘right’ to control all others. It’s the assumption that the world can be meaningfully divided into ‘IT’ and ‘the business’ – and that IT, by definition, is the only one that’s right. It’s the attitude that only IT-people know how the world works, and therefore we have the ‘right’ to tell everyone else how they should work, so as to best fit in with the way that we work. And it comes out in a myriad of other subtle, unacknowledged, amazingly destructive forms.

It is, in short, myopic, narcissistic, and arrogant: and it really annoys the heck out everyone else.

If you want to see how and where and why the ‘business-IT divide’ is created, and why it stubbornly persists as a wicked-problem despite all the best intentions of so many people on every side, all you need to do is watch how IT-centrism keeps coming back, and back, and back, in just about everything that comes out of the IT-consultancy industry and elsewhere.

I ought to emphasise here that this kind of ‘self-centrism’ is not specific solely to IT. For example, ‘business-centrism’ is beginning to be another real problem in enterprise-architecture, where ‘the business of the business’ demands to be treated as the sole centre of the architecture. Finance people do it; HR people do it; shareholders do it a lot; Health & Safety folks do it far too often too. Just about every domain does, probably, at some time or other. But it does seem to be particularly endemic in the IT-consulting industry; and since they still dominate the enterprise-architecture discipline at present, that’s where most of our current ‘-centrism’ problems arise, and why IT-centrism is such a serious problem for us right now.

A domain-architecture necessarily centres around a specific discipline: that’s why it’s a domain-architecture. A solution-architecture also usually focusses its attention on a single domain. But every domain and domain-architecture has to learn to ‘play nice’ with all of the other domains and their architectures – otherwise the whole will always break down into feuds and infighting, or fragment into fiercely-defended ‘us-against-the-world’ silos.

For architecture – the relationship between structure and purpose – there needs to be something, some form of discipline, that helps to hold everything together. And the only way that works is by accepting whilst everyone does need to be the centre of attention at some point, no-one can claim to be ‘the centre’ around which everything always revolves. It does not work – it really is as simple as that.

In a true enterprise-architecture, everywhere and nowhere is ‘the centre’ all at the same time.

Hence we cannot allow IT-centrism to exist, or any other ‘centrism’ to exist, because it kills the architecture, every time.

Hence we must challenge it, every time we see it – in others, and especially in ourselves.

If we want our enterprises to succeed, there is no other choice: that IT-centrism has to go.

Which is why I’ve ranted so often on this point over the past five years or so. I apologise if it’s annoyed people a bit too much at times: but hiding from facts never helped anyone for long, and as a profession we really need to face this fact now.

That’s it, really. End of rant?

(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?

[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?

• SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R Very timely as Enterprise Business Architecture is a HUGE subject at #GartnerEA

If you know me, you won’t be surprised that to me that was like a red rag to a bull. Yup, I admit it, I fulminated:

• tetradian: RT @SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R >Business Architect is _NOT_ an IT job!!! #entarch #fercryingoutloud..

Then Ivo Velitchkov (backed up by Patrick Lujan) came back in with a dose of realism. Unwanted realism, maybe, but realism nonetheless:

• kvistgaard: @tetradian Well, let’s face it: it is! “Business” is misused in #BPM and Business Architecture, same as “E..” in #entarch. So really, Business Architect, nowadays, sadly, is an IT job.

Whilst Nick Malik dived in from another direction:

• nickmalik: RT @SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R >Business Architect is _NOT_ above EA either!!! #entarch

…and, later, expanded on this with a post of his own:

• nickmalik: [post] Different Specialties of Architect http://bit.ly/iRmtCE  –> To reduce the arguments about #entarch

Which might well look like Yet Another Pointless Argument About Job-Titles… “Oh no, not again”, I hear you cry?

Actually, this is a serious problem, and all of those are valid responses, in their own ways. Enterprise business-architecture is a very important aspect of enterprise-architectures; done properly, it is definitely not an IT-role, but at present it is still all too often portrayed as such; and the relationships between the various roles have become very blurred, very messy, and very confusing, to the point where that confusion is causing a lot of damage to organisations and their business-related architectures – and to the profession as a whole. Oops…

The core of the problem is not merely one but two related term-hijacks:

• portraying enterprise-architecture as minor subset of IT-governance;
• portraying business-architecture as a kind of random grab-bag of ‘anything not-IT’ that might affect IT’.

The worst perpetrator of this, I’m sorry to say, has undoubtedly been the Open Group, aided and abetted by ‘the usual suspects’ – the big IT-consultancies and analyst-firms. All of whom have only just realised how much they’ve succeeded in getting themselves ‘hoist by their own petard‘, but have unfortunately caused (and are still causing) a lot of damage with their previous overly-myopic IT-centrism.

I hasten to add that some of the Open Group crew are well aware of the problem, and the damage that it causes. For example, the indefatigable Len Fehskens has been fighting this particular battle for even longer than I have: his blog-post ‘Enterprise Architecture’s Quest For Its Identity‘ is an absolute must-read for anyone involved in anything to do with enterprise-architectures. His nomenclature of roles is really useful here: xA, ExA, EA (about which more in a moment). In essence, the architect’s role consists of bringing things together into some kind of unified whole, for a chosen purpose. I’ve expanded on this a bit more in my earlier post ‘Making sense of architecture roles‘, but the key point is that to understand and describe the role, we need to understand both its scope (or ‘breadth’) and its direct skill-level (or ‘depth’). A domain is a region of scope and expertise: for example, IT-infrastructure, security, brand, organisation, process, logistics and so on. In Len’s nomenclature, ‘x is any specific domain:

• xA (e.g. applications-architect, brand-architect): a domain architect, with emphasis on a single domain or closely-related cluster of domains, almost always with high skill-level (strong depth) in that domain – i.e. deep, but probably not broad
  (a solution-architect is usually a domain-architect assigned to a specific project or change-programme)
• ExA (e.g. EBA, ‘enterprise business-architect’; EITA, ‘enterprise IT-architect’): an enterprise-scope domain-architect, with emphasis on how a single domain links with other domains; the skill-level is sometimes referred as ‘T-shaped’, deep-skill in one domain, but sufficient of knowledge of other domains to able to support good ability to converse with other domain-architects and other specialists from those other domains
• EA: a specific domain-architect whose domain is the enterprise as a whole, and for whom the core skill-set includes cross-context specialisms such as systems-theory, human-factors, futures, strategy and other ‘big-picture’ themes; the skill-level across domains tends to be broad rather than deep (i.e. ‘comb-shaped’ rather than ‘T-shaped’), but must include all domains that are in scope for the enterprise

(Note that in most countries, by law, the only people who can describe themselves as ‘architects’ – without any other qualifier – are building-architects. Everyone else in all other cross-context-linking or cross-domain-linking professions must use some kind of qualifier – hence naval-architects, civil-architects, security-architects and, of course, enterprise-architects.)

What the Open Group have done in TOGAF is to completely scramble that nomenclature: routinely, an IT domain-architect or, at best, an EITA is labelled as an ‘EA’, with business-architecture – which should be a domain that is business-focussed and functionally distinct from IT – parked somewhere entirely arbitrary ‘under’ the IT-centric ‘EA’ banner. Hence that ‘business-architecture’ is simultaneously both ‘below’ and ‘above’ that ‘enterprise-architecture’, in several different utterly confused and utterly confusing senses. It is, bluntly, a mess – an unusable mess. And whoever it was that insisted on incorporating that mess into TOGAF 8.1 and TOGAF 9 should be quietly taken out and have their noses rubbed in that mess every single day until they themselves have sorted out the mess, because the end-result is that it’s made it almost impossible even for IT-architects to do their jobs, let alone anyone else.

So yes, Ivo and Patrick are right: it may well be true that ‘business’ architect is currently described as an IT role. But the blunt fact is that it really doesn’t help to do so: it just perpetuates the mess. Every one of us needs to be emphatic about this, because it is probably the primary cause of damage to the profession at present.

And yes, Nick is right, too: business-architecture is a distinct domain – the architecture of ‘the business of the business’ – that must not be seen as ‘above’ the scope of the broader shared-enterprise in which the business operates. By definition, it’s sort-of ‘under’ EA, because EA provides (or describes, or maintains, or whatever) the overall umbrella (or coverage, or network, or mesh, or whatever) under which (or through which, or within which, or whatever) everything connects with everything else. But when only IT-architectures are described as ‘EA’, then there are some circumstances in which BA or EBA is ‘above’ that kind of ‘EA’. Yet also circumstances when they’re not – given the way that TOGAF describes BA and EA. Which again adds to the mess…

Which is where we come to the second term-hijack in TOGAF and similar IT-centric ‘EA’: defining ‘business-architecture’ as ‘anything not-IT that might affect IT’. Reading the TOGAF spec – particularly the TOGAF ADM’s Phase B, ‘Business Architecture‘ – there is almost no distinction made between high-level strategy (whose main impact is at Zachman layers 3 and above), process-design (typically Zachman layers 3-4) and protocols and the like process-execution (typically Zachman layers 4-5): it’s all ‘not-IT’, hence all jumbled together into a kind of blobby blancmange with no functional meaning at all. Take a look, too, at the TOGAF description of ‘business scenarios‘ – somewhere around the Zachman layer-4 – and compare that to the business-usage of the term – which is more like Zachman layer-2. Hence, overall, no wonder that business-folk get seriously annoyed at IT-centric ‘EA’ and its daft description of ‘business’-architecture that makes no business sense.

So we have TOGAF – and just about everyone else in the so-called ‘enterprise-architecture’ space – describing an ‘enterprise-architecture’ that isn’t about the enterprise as enterprise, and a ‘business-architecture’ that has very little connection with the business of the business. Oops… not helpful…

So in that sense, no, I disagree with Ivo and Patrick: it may be ‘realism’ to say that “really, Business Architect, nowadays, sadly, is an IT job”, but it is definitely not wise to allow that misnaming to go unchallenged, because the consequences are very serious indeed. (The building-industry has long since discovered this blunt fact the hard way – hence the legal controls around the ‘architect’ term.)

And I also sort-of disagree with Nick – not from what he’s said as such, but more from where I know he’s coming from: when the business of the business is IT – as in his own business-context at Microsoft – it’s again all too easy to fall back into IT-centrism, and I do detect more than a hint of that in his follow-on post about ‘Different Species of Architect’.

Overall, though, I’d have to insist on this as a summary:

• business-architecture touches IT, but is not an ‘IT role’
• business-architecture is a domain-architecture – ‘the business of the business’ – and hence necessarily comes ‘under’ the broader whole-enterprise scope of enterprise-architecture

Any other way to describe the relations between business-architecture, IT-architectures and enterprise-architecture will merely compound the mess that TOGAF et al have already made of this profession. Sigh…

That’s my opinion, anyway. For what it’s worth. Over to you?

As a discipline, enterprise-architecture is still in the throes of a multi-year struggle against IT-centrism – in our context, the dangerous delusion that enterprise-scope IT-architecture somehow ‘is’ enterprise-architecture. There are signs now that that struggle is at last beginning to be won: a much better recognition in Open Group conferences, for example, that business-architecture is not merely “anything not-IT that might affect IT”.

But we need to be aware, and wary, of the next trap: business-centrism. Business-architecture is, and should be, the architecture of the business. But it is not the architecture of the enterprise: the two are fundamentally different. Or, more accurately, business-architecture is a detail-layer subset of enterprise-architecture – and exactly as with IT-architecture, it is essential not to mistake any subset for the whole.

Let’s take a classic business-architecture frame, Alex Osterwalder’s Business Model Canvas:

Business Model Canvas [(cc) Alex Osterwalder, Yves Pigneur et al.]

This provides an excellent way to describe a commercial organisation’s business-model: products and services, how the customer is contacted, revenue-streams, supply-chain concerns, costs and so on. We definitely need all that information in a business-architecture, and in considerable detail.

But what this doesn’t do is show how this expands downward into the fine-detail of implementation and operational-management – which is what we need in order to realise that business-model. For example, for the IT-related components of that business-model, that’s where the IT-architectures would come into play: information-architecture, data-architecture, applications-architecture, infrastructure-architecture and so on. We would also need to connect with BPM (business-process management), security-architectures, skills-mappings and a whole load more, especially on the ‘human’ side of business practice. So on its own, a business-centric architecture could be misleading: a big-picture that’s useful, and usefully descriptive, but not actually usable in real-world practice.

And that business-oriented ‘big-picture’ is not actually big enough: it ignores a whole swathe of information about the broader business-context, and hence is left to make arbitrary assumptions about that broader context – assumptions which may well turn out to be wrong. In essence, the Business Model Canvas – and almost every other business-architecture frame that I’ve seen – will summarise the core working of the organisation, its relationships with the ‘near-field’ aspects of the supply-chain, and some description of how it will relate to customer-prospects: but that’s usually as far as it will go. Which is dangerously incomplete in relation to the whole scope of the extended-enterprise:

Relationships with the ‘outside’ part of the extended-enterprise, beyond the core market, are primarily driven by values – not solely monetary concerns, which for the most part apply only at the market-transaction level. Failing to pay proper attention to those broader values can kill the viability of the business-model and even the business itself – even though those ‘transactions’ may not touch the actual business-model at all. We can perhaps see this best through what I call the ’market-cycle’:

Another cyclical view of the relationships between all these layers also illustrates the source – and danger – of the all-too-common ‘quick-profit’ short-cut version of the cycle, which is guaranteed to drive a business into the ground in the medium to longer term:

The greyed-out area described as ‘tactics + operations’ in that diagram is usually the maximum scope of a business-architecture. An enterprise-architecture must, by definition, cover the entire scope. A ‘business-centric’ version of enterprise-architecture would constrain us to the business-specific scope – which is why everything else would be left to arbitrary and often unconscious assumptions. Not a good idea – in fact actually worse than the IT-centric version of ‘enterprise’-architecture, because at least in the latter case the limitations are obvious to most people, whereas in the business-centric version the gaps are easier to miss.

One of the things that that unhelpful troll on LinkedIn mocked me for – and others have done much the same, in the past – was my attempt to explain that in an enterprise-architecture we must take into account the value-transactions and interactions: we can’t simply reduce it all to monetary terms. As should be obvious from the diagrams above, there are relationships between those value-transactions and the monetary-type transactions that come later in the market-cycle: but those relations are usually complex, non-linear and non-reversible, so we can’t start from a monetary view (as in so many conventional ‘value-proposition’ concepts) and return directly to a monetary view (as monetary ‘profit’). The transforms from there to the much-vaunted and apparently much-desired ‘shareholder-value’ are even more complex and non-linear: as Michael Porter once put it, the obsessive quest for ‘shareholder-value’ is “the Bermuda triangle of strategy“, in which so many companies sink without trace… Yet even Michael Porter misses the point in that article: he refers to ‘economic performance’, when what he means is ‘overall performance as measured in monetary terms’ – which is not the same thing. As business-architects we can sometimes get away with that kind of kludge: but as enterprise-architects, we can’t get away with it – especially at the Really Big Picture level.

So yes, heave a sigh of relief as we finally break free from IT-centrism in enterprise-architecture. But beware of the next trap – the trap of ‘business-centrism’ – and instead keep the focus and emphasis, at all times, on the extended-enterprise as a unified if always somewhat-chaotic whole.