Tom Graves / Tetradian

Enterprise-architecture is dead – long live enterprise-transformation! Or so it would seem, from the description of the current Open Group conference at Cannes.

Yet is all as it seems? I’d have to admit that the conference-programme does worry me a bit. Despite the presence of a fair few people with a broader view than just IT – Alex Osterwalder, Len Fehskens and Stuart Boardman, to name just a few – so much of it still seems to be the same-old search for the ‘next big thing’, the next soon-to-fail IT-based magic-bullet: currently ‘Big Data’, mobility, cloud, cloud and more cloud. Oh well.

A bit of history might be relevant here. Back at the start of the 20th century, the electric motor was the great ‘next big thing’. Huge excitement! – huge hype! – the electric motor will solve everything! No doubt that it transformed industry: freed at last from that terrifying tangle of belts and pulleys, machines now placed wherever fits the workflow, smaller, more compact, more convenient. A whole new infrastructure to power it, control it, monitor it, measure it, manage it.

(Sounds familiar, perhaps?)

And finally, when electric motors were literally everywhere, embedded in almost everything, the realisation that although the electric-motor is an important enabler, it’s only an enabler: isn’t the enterprise itself.

The enterprise isn’t solely about machines, or information, or ‘making money’: it usually includes all of those things somewhere within the overall picture, but first and foremost it’s about the hopes and desires and aims of people. If we ever forget that fact, there’s no space for enterprise – and hence nothing against which enterprise-architecture, or enterprise-transformation, could ever make sense.

As Simon Sinek puts it, any enterprise-scope work must always start with ‘why’: the ‘how’ and ‘with-what’ come later in the story. And for enterprise-architecture that ‘why’ must always be about the whole of the scope – not solely about some arbitrarily-selected subset. Open Group’s TOGAF is excellent for enterprise IT-architecture; yet its rigid focus on IT (as defined in sections B, C and D of its Architecture Development Method) renders it problematic at best for anything else in the enterprise-architecture space. It’s fixable, as I’ve explained at various Open Group conferences and elsewhere over the past five years or so: yet still that kind of update has not been applied to the ADM, and in that sense TOGAF 9 represented a sadly-missed opportunity. As a profession, we need to do better than that.

To give some idea of what I mean by ‘the enterprise’ – and hence its architecture and its transformation – take a look at some of the projects I’m exploring at present in Latin America:

• a medium-sized brewer needing to resolve problems with internal theft
• a large manufacturer addressing multi-way ‘cultural translation’ between Asian ownership and executive, US management and methods, and Latin engineers and workforce
• a government department working with a film-producer to use social-media to break the cycle of mutual distrust between police and schoolkids and teenagers in the slum-districts
• an NGO wanting to use the ubiquity of cell-phones as a means to improve health-care in widely-dispersed indigenous communities

It’s likely that in each of these contexts, an enterprise IT-architecture will play some important part: but the IT itself is not the sole focus of the overall task. To make any of those transformations work, we need to start from people, not IT – start from enterprise as enterprise – and keep that whole enterprise in mind at every moment.

It may well be that enterprise-architecture is dead – but if so, it was killed by inanely inappropriate IT-centrism, in Open Group and elsewhere. As we move to a nominally broader-based enterprise-transformation, could more effort be made to ensure that we do not repeat the same IT-centric mistakes? Please?

This one continues the recent theme of IT-centrism and why it’s such a problem for enterprise-architecture, but extends it into a slightly different direction, courtesy of a Tweet yesterday by Ron Tolido:

• 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.

A set of Tweets from the third and final main day (01 Feb 2012) of the Open Group conference in San Francisco, collated via the#ogSFO hashtag. (Tweets from Day 1 are here; from Day 2 are here.)

Once again, many thanks indeed to all those who Tweeted, to help us all get a better picture of the current Open Group view of enterprise-architectures.

Same minor edits as in the previous posts:, I’ve stripped out most of the ‘#ogSFO’ hashtags in the text, and added occasional comments of my own in italics, but otherwise the following is as Tweeted by the respective participants.

I’ve also added a few wrap-up remarks of my own at the end.

As usual, somewhat less volume again on this day of the conference, but still several pages’-worth, so continue after the break.

Read more…

A set of Tweets from the second day (31 Jan 2012) of the Open Group conference in San Francisco, collated via the#ogSFO hashtag. (Tweets from Day 1 are here.)

Once again, many thanks indeed to all those who Tweeted, to help us all get a better picture of the current Open Group view of enterprise-architectures.

As before, I’ve stripped out most of the ‘#ogSFO’ hashtags in the text, and added occasional comments of my own in italics, but otherwise the following is as Tweeted by the respective participants.

Not quite so much as the previous day, but still a lot, so continue after the break.

Read more…

A set of Tweets from the first day (30 Jan 2012) of the Open Group conference in San Francisco, collated via the #ogSFO hashtag.

Many thanks indeed to all those who Tweeted, to help us all get a better picture of the current Open Group view of enterprise-architectures.

I’ve stripped out most of the ‘#ogSFO’ hashtags in the text, and added occasional comments of my own in italics, but otherwise the following is as Tweeted by the respective participants.

There’s a lot of it, so best place a brief break here.

Read more…

Oh no, not again… Having all but crippled enterprise-architecture for the past decade with a muddled mess of myopia and misdefinitions, it seems Open Group are hell-bent on making the same kind of mess in business-architecture…

I need to be upfront about this: I don’t regard Open Group as ‘the bad guys’. Far from it: they’re an extremely important IT-standards body, and they do very important work indeed throughout the IT space. Yet it seems that whenever they touch anything that isn’t explicitly IT, they bring with them a perhaps-understandable yet entirely inappropriate IT-centric view of the world: and as a result, make a complete hash of it. Every darn time… And for the sake of all of us – including themselves – they really need to stop doing this…

On this occasion, it’s about business-architecture, specifically a transcript of Dana Gardner’s panel-session at the last Open Group conference, back in July: ‘PODCAST: Exploring business-IT alignment: A 20-year struggle culminating in the role and impact of Business Architecture‘. There’s a lot of good sense in there – no question about that – and for anyone involved in enterprise-architecture it’s definitely a ‘must-read’. Yet when I look at the sections that attempt to define business-architecture, and its relations to enterprise-architecture and IT-architectures, all I can do is weep:

[Dave van Gelder] Currently in the Business Architecture Working Group, we see business architecture as something that brings the balance between all the other architectures in the company — that’s IT architecture, financial architecture, money, people architecture, and a lot of other architectures.  If business architecture is bringing the balance between the different aspects of a company, then business architecture is something that should be handled in the top of the organization, because balance should be created between all the different aspects in the organization.

(I was present at that start-up meeting Dave describes, by the way, at the Open Group conference in Lisbon back in 2006. A very good conversation then that unfortunately seems to have gone almost nowhere: the main point I remember was that I was perhaps the only person there who didn’t speak Dutch… )

Well, yes, that definition is fine, in its own way – except that that’s actually the linking role of enterprise-architecture. There’s no distinct ‘architecture of the business of the business’ here: in other words, no business-architecture. And it gets worse:

[Harry Hendrickx] When we look at the enterprise architect and the solution architect, the business architect focuses more on the complete implications of the strategy and technology trends on the operations, whereas the enterprise architect is more interested in the IT and the implications for the IT strategy and how IT should be deployed. The business architect is much more focused on the complete performance of the business operations.

In other words, despite Walter Stahlecker’s explanatory document for the Business Architecture Working Group back in 2008, and despite Len Fehskens’ excellent article on ‘Enterprise architecture’s quest for its identity‘ on the Open Group’s own weblog, the Open Group still fails to grasp the bald fact that enterprise-architecture is not an IT-role, and that the term ‘enterprise-architecture’ is not a synonym for ‘enterprise-scope IT-architecture’ – the latter being what is actually meant by ‘enterprise architect’ above.

As Len Fehskens makes clear in his article, enterprise-architecture is the architecture of the enterprise – and the enterprise (or extended-enterprise, if you prefer) extends not just beyond IT, but also a long way beyond the organisation itself. In enterprise-architecture, we develop an architecture for an organisation, but about the extended-enterprise or ‘ecosystem-with-purpose’ within which it operates. It’s also a much broader scope than the architecture of the ‘the business of the business’ – in other words, the domain-architecture that we would properly describe as ‘business-architecture’.

But what we have here is, unfortunately, yet another Open Group mess. Enterprise-architecture is sort-of defined as an IT role, tasked with bridging the gap between IT and ‘anything not-IT’. Business-architecture variously either takes on an organisation-centric variant of the real enterprise-architecture role (as in Dave van Gelder’s comment above), or a muddled mixture of ‘the architecture of everything not-IT’ (as in Harry Hendrickx’s comment) – the exact same IT-centric mistake as in Phase B of the TOGAF ADM. How this is supposed to help in bridging the infamous ‘business-IT divide’, when just about everything here will clearly increase it, I just do not know…

Perhaps the most worrying point, though, is this:

[Dana Gardner] Anyone else with some thoughts about how to make the certification and standardization of this stick?

[Mieke Mahakena] What we’ve been doing in the Business Forum, after we decided that business architecture has its own reason for existence, we described the business architecture profession – what’s the scope and what should be the outcome of business architecture. Now, we’re working on the practice of business architecture by defining a framework, looking at methods, and defining approaches you can use to do business architecture.

Parallel to that, if you know what the profession is and what the practice is, you’re able to create the business architecture certification, because those things help you define the required skills and experience a business architect needs. So, we are working on that in the Business Forum.

Why is this worrying? To see why, you need to click on the ‘Business Forum’ link. It takes you to a password-protected page – which, by examining the link, you’ll realise is only accessible to Open Group’s ‘Platinum’ members. The ‘big boys’: no mere mortals allowed here, thank you very much. Which should remind us, yet again, just how ‘open’ the Open Group actually isn’t: in fact, it operates a ‘pay for play’ membership, a straightforward hierarchy in which the only real rule is that the ‘big boys’ always win. So what we have in the Business Forum is a group of large IT-consultancies who’ve demonstrated over and over again that they have barely a freakin’ clue about anything beyond IT, supposedly defining the entirety of the business-architecture profession, discipline and certification, all of it behind closed doors, and with no input or review from anyone beyond IT. If you’re working in enterprise-architecture, and that fact doesn’t worry you, it should…

Again, some good ideas scattered throughout that transcript: but overall…? – well, perhaps the only word that could describe it is ‘yikes…’? Sorry, guys, but we definitely need to do better than this. Please?

Oh well.

Archimate aims to be the standard notation for enterprise-architectures. But has it become too IT-centric to be usable for that purpose? And is there any way we can get it to break out of the IT-centric box?

These questions came up for me whilst exploring the architectural processes we could use in expanding a business-model developed in Business Model Canvas out into the detail needed for real-world implementation. Archimate should be the obvious standard to use in describing an overall architecture: but at present it’s not so much IT-oriented as almost entirely IT-centric, and a real-world business-model involves a lot more than just IT. Yet if the only available standard only describes the IT, what on earth can we use to describe everything else? And how can we link everything else back to the IT? Therein lies the problem.

Let’s step back a bit. More like a decade, actually.

Archimate started out as means to solve some real architectural problems for users of large IT-systems in the Netherlands. A consortium of academics, IT-consultancies, business-users and government was brought together, to address how to link all the different layers of the IT-domains together, from the business needs, down through the IT-applications and data, all the way to the actual IT-infrastructure that supported all of those needs. In other words, the usual IT-oriented layering that we see in TOGAF and so many other ‘enterprise’-architecture frameworks.

That kind of layering does make perfect sense if the focus of concern is IT, and if the business of the business revolves primarily around information. In other words, it fits well with IT-architectures for information-centric businesses such as banking, finance, insurance and tax – hence the reason why the usual Archimate ‘demonstrator’ is an imaginary insurance-company called ‘Archisurance’.

But this doesn’t make sense – or rather, is far too constrained and constraining – if the focus of concern is anything other than IT, or for any type of business whose business is not centred solely around information. Which latter, in reality, is the case for most businesses – if not all of them, once we start looking at the deeper detail of most business-models.

Which means that, for those of us involved in real enterprise-scope architecture, business-architecture, security-architecture, process-architecture, or any kind of architecture that touches just about anything other than IT, we have a problem here. A big problem.

A problem which in some ways is actually getting worse.

Which means it’s a problem that, collectively, we need to do something about, right now. Urgently.

Why do I say it’s getting worse? Well, take a look at this section from Chapter 2 of the original Archimate Primer [PDF], from back in 2004:

In the enterprise-architecture modelling language that we propose, the service concept plays a central role. A service is defined as a unit of functionality that some entity (e.g. a system, organisation or department) makes available to its environment, and which has some value for certain entities in the environment.

It’s clear that ‘service’ here is intended to be generic – not solely IT. And service-orientation is a certainly good place to start for whole-enterprise architectures.

The chapter-text continues with a brief summary of that all-too-common IT-oriented layering of ‘Business’, ‘Application’ and ‘Technology’. The accompanying diagram and text, though, do make it clear that there’s more to the context than IT alone, and that we do need to take the broader enterprise into account, beyond just the organisation itself:

The Business layer offers products and services to external customers, which are realised in the organisation by business processes performed by business actors. … On top of the Business layer, a separate Environment layer may be added, modelling the external customers that make use of the services of the organisation (although these may also be considered part of the Business layer).

So far, so good. It’s about services, and about the broader enterprise; it’s IT-oriented, but not IT-centric as such.

Yet somewhere, things started to go badly wrong, from an enterprise-architecture perspective.

Somewhen around 2008 or so, with the aim of making the still-somewhat-prototype standard more available worldwide, Archimate was transferred to the ownership and aegis of the Open Group. That move no doubt seemed sensible enough at the time: but the problem is that the Open Group is an IT-standards body, not an architecture body – and that built-in orientation towards IT starts to show even in the very first sentence of the Archimate version 1.0 formal standard, published in 2009:

An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization.

And by the time we reach the standard’s chapter on Enterprise Architecture, that all-too-common IT-centrism is in full flood:

The primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. Further, it details the structure and relationships of the enterprise, its business models, the way an organization will work, and how and in what way information, information systems, and technology will support the organization’s business objectives and goals. This makes IT a responsive asset for a successful modern business strategy.

Today’s CEOs know that the effective management and exploitation of information through IT is the key to business success, and the indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

You could just about get away with that kind of myopia in 2009, though even then its absurdity was beginning to be more widely recognised. Two years later, it’s probable that most members of Open Group would acknowledge that there are some serious limitations there, and many – such as Len Fehskens and Microsoft’s Mike Walker – are much more overt in asserting the need to break out of the IT-centric box.

In short, we need an Archimate for enterprise-architecture – not just IT-architecture. We need – and need urgently – an Archimate that isn’t all-but-uselessly IT-centric.

And yes, the good news is that a new version of the Archimate standard is due for release Real Soon Now. Hooray!

The bad news is that this new version isn’t likely to help much at all. If anything, it’s likely to make it worse…

I’m not a member of the Open Group or the Archimate forum, so I’m not directly involved in the update. But from what I hear from colleagues who are involved, the new version will be just as IT-centric as the old one. That text above apparently remains completely unchanged in the new standard: which means that its definition of ‘enterprise’-architecture is not so much out of date as just plain wrong. I’m told there are a couple of new sections to the metamodel: one is on motivation, to sort-of link it to the well-known Business Motivation Model; the other is about projects and dynamics, linking to and in some ways improving on the TOGAF 9 metamodel. I gather that there are a few new generic entities, such as Location, which would be not so much useful as essential. And Product, which used to be defined as “a coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers”, is now apparently defined in even more rigidly IT-centric terms, as something like “a collection of financial or information services, with a contract that gives the customer the right to use the associated services”. Which doesn’t leave any space for descriptions of physical product or service, or relationship-oriented services – which is what most businesses actually deliver.

In other words, fine for the relatively small subset of enterprise-architecture that focusses around IT, but almost useless for anything else.

Which is not good news for enterprise-architecture.

So what can we do about it?

One option, I suppose, is to yell loudly at Open Group, and try to make it evident even to the most IT-obsessed of their big-consultancy members that this is nowhere near good enough. Sadly, I don’t think that’s going to work…

Another might be to ask the original Archimate group – Telematica Instituut and others – to retrieve the standard from Open Group, so that we actually have a chance to make it work again. Sadly, I don’t think that’s going to happen either.

Another option might be to use the Profiles facility in Archimate to define a much broader metamodel, particularly around the physical and relational analogues to the information-space that IT partially covers. That at least is doable – but the problem is that without a standards-body to coordinate all the various needed extensions, we’ll soon have no standard at all. Not a standard that we could for interchange, anyway, and not one that we could get the vendors to standardise on, to at last enable us to move architecture-models between the various vendors’ toolsets. Yet it doesn’t seem to be in Open Group’s interest that this essential work takes place, and at present there’s no-one else to take on that role.

Which at present, and for the foreseeable future, leaves us without a notation/exchange standard that we can use for enterprise-architecture. Again. After all these years. Sigh…

Over to you, folks: any ideas for anything that can get us out of this metamodel mess?

A selection of Tweets from various folks – with an especial thank-you to @systemsflow and @theopengroup – from the Open Group conference, Austin, Texas, 18-20 July 2011, via the Twitter hashtag #ogaus. (Selected in the sense that most of the Tweets I’ve included are on business-architecture and enterprise-architecture – I haven’t included much on Cloud, IT-security or other strictly IT-oriented themes.)

Various breaks added to split the overall Twitter-stream into (I hope) more meaningful clusters; I’ve also added comments in various places in italics preceded by a ‘>’ marker, >like this.

There’s quite a lot of it, so take a wander after the ‘Read more…’ break.

Read more…

A busy week this has been. The Gartner EA Summit and the Open Group Enterprise Architecture Practitioners conference were both on in London at the same time, little more than a few hundred yards apart. And a lot of other things starting to happen in the enterprise scene as well: more good news on the way.

The highlight, though, was a stream of great conversations on enterprise-architecture.

The first of these was with Nick Gall and Bard Papegaaij from Gartner, and independent-consultant Richard Veryard. As usual, I failed to take notes… apologies. But probably the key theme throughout was the shift away from IT-centrism: Nick with his concept of the panarchy double-cycle applied to architecture, as ‘panarchitecture‘; Bard with a strong emphasis on architecture in government, and on emotional-intelligence and human factors (the latter with some strong parallels to my own themes around ‘enterprise as story‘ and ‘enterprise as language‘); and Richard on expanding out to a broader concept of ‘organisational intelligence‘. There was also quite a bit of discussion on whether the panarchy-cycle of creation, exploitation, collapse and rebuild, could be applied to Gartner’s own ‘hype-cycle‘: Nick was adamant that it couldn’t and shouldn’t, but Richard and I both felt that perhaps it could – particularly if we see the hype-cycle as two iterations of a panarchy-cycle, with the hype-cycle’s collapse into the ‘trough of disillusionment’ representing the second half (‘destruction’) of the first of those panarchy-cycles. A discussion for another time, perhaps?

We followed through on the next day with a stream of what ended up as mostly one-on-one discussions: Richard was presenting at the Open Group conference and could only drop by for a few minutes, whilst Nick and Bard had speaking-slots at Gartner that were almost back-to-back.

With Bard, the conversation started around the work by his late wife Michal, linking the native-American model or metaphor of the Medicine Wheel, and how those concepts can be applied in a business context.  In some ways this parallels my own architectural use of the traditional Five Elements model, and also some Jungian-style concepts that I’ve used for many a year, though Michal’s ideas seem to go into even further depth. (We’d planned to meet up at their home in Brisbane earlier this year, and had all been greatly looking forward to it; but we’d had to postpone at the last minute, because she became very ill, and sadly that meeting never took place. A huge loss not just to Bard but – from what I’ve seen so far – a huge loss also to all of us in enterprise-architecture, I suspect. Oh well.)  Very interesting, anyway, and I hope at least some of it will surface as a Gartner Note or the like from Bard in the relatively near future.

Another key part of the discussion with Bard was the relationship between agility and stability, somewhat as described in my previous post ‘Agility needs a backbone‘. The hypothetical example that we explored – based on real-world contexts which we’ve both worked – was the classic clash between bureaucrats and politicians in a government department. The blunt fact is that few politicians can see beyond the short-term: they need to deliver quick results of some kind to convince the electorate that they’re doing something of value. That means that they demand agility, to change everything ‘now!’ – which soon leads to a horribly fragmented architecture, with all manner of half-completed projects pulling in all manner of different directions. By contrast, the bureaucrats crave certainty, stability – and they often do hold a true long-term view, albeit often an over-cautious one. Caught between these two opposing forces are the project-managers and process- and IT-system developers, who somehow have to sort out the resultant mess. The way out seems to be an architecture based on some variant of the backbone – which keeps the bureaucrats happy – providing consistency and support for a myriad of smaller agile projects out on the edge – agile enough to keep the politicians happy. The two types of implementations need different emphases: the agile side typically thrown together as ‘shadow IT’, whilst the core follows a more ‘traditional’ waterfall-style cautious-change model with much tighter governance. New services feed outward from the core, enabling new agile-style ‘mashups’ – the many GIS-linked ‘citizen services’ being a good example of this. And some of those quick-win services will also slowly migrate into the core. But in terms of dependencies, it’s a kind of spoke-and-hub relationship: in general, services from the core should never be allowed to break anything – especially not without warning – whereas there would often be no guarantees at all for relationships between agile-services out on the edge. This approach would give us a unified form of governance across the whole agile/waterfall spectrum – and a lot more certainty for the developers who’ve too often been caught up as pig-in-the-middle.

Then to the follow-up meeting with Nick Gall. Much of this was a review of what Bard and I had discussed earlier, but there were also two key points that arose from a brief review of my ‘Enterprise Canvas‘ model-type (from my book Mapping the enterprise). One point was a link-up between my understanding of the tension between ‘vision’ and the real-world, that drives the architecture, compared to one of Nick’s own models of architecture as a kind of wasp-waisted ‘double-funnel’ between near-infinite possibilities and near-infinite implementations, with architecture as the ‘waist’ where constraints for key choices are identified and applied. To me, everything in the enterprise is like a cone, extending downward from the single point represented by the vision. But as Nick pointed out, architecture describes a structure that could in principle be used for a very wide range of different purposes – in other words, similar structures that can support different enterprise-visions. The ‘cone’ represented by a layered Enterprise Canvas would thus be one instance of the range of possibilities of purpose represented by the upper-half of Nick’s double-funnel, selected out by that specific vision; a different vision could well lead to an almost identical-seeming implementation below the ‘waist’ of the double-funnel. Hence why reference-architectures and commoditised-services and suchlike do actually work in practice – even though they’re linked to different enterprise-visions.

The other point was an easy way to resolve the age-old argument about architecture versus design. They’re actually part of the same spectrum from vision to realisation, from ‘why’ to ‘how’ and so on. The only difference between them is which way they face: architecture tends to face ‘upward’, towards the big-picture,  the vision, or ‘why’, whilst design tends to face ‘downward’, towards the detail, the real-world realisation, the how and who and where and when and with-what. So in practice, almost no-one is ever solely and architect or designer: everyone will do at least some of both. What makes it confusing at times is that the ‘architect’ orientation at a detail-layer – a solution-architect or application-architect, for example – will usually have a narrower scope than someone nominally working in higher-layer business-design or process-design. Once we realise it’s the same spectrum, it makes things a lot easier to explain: the difference between architect and designer is one of orientation – ‘up’, or ‘down’ – on that spectrum, more than one of position in terms of Zachman-style layers. Architects mostly architect, and designers mostly design; yet the two roles will always meet somewhere within each person on that spectrum.

Next was a meetup with a director of the vendor of a mid-range enterprise-architecture toolset. I won’t say which vendor it was, for confidentiality reasons, but to me this was important: perhaps the first toolset-vendor to really ‘get’ the nature of whole-of-enterprise architecture, and the support that it needs from the the architecture-toolset. Like almost all of the vendors, they’ve come up from an IT-oriented base, and that’s still the core of their toolset; but they do understand about how all of that links upward into strategy and vision, and horizontally across the non-IT aspects of the enterprise – people and machines and non-IT assets and the like. Nothing else to report just yet, but definitely a Watch This Space, I think?

Leaving the Gartner conference-venue, a very brief meeting with two of the new generation of whole-enterprise architects, Gerold Kathan and Ondrej Galik. I had to run to catch a train at that point, so only enough time to talk whilst crossing Westminster Bridge, but good to know that the future of the field in Europe seems already to be in capable hands.

And likewise in Latin America. The last of this stream of meetings this week was with Roberto Severo, lead for the Brazil chapter of AOGEA (Association of Open Group Enterprise Architects). We met first at the Open Group conference-venue – I didn’t go to the conference itself, for reasons I’ve explained earlier. A long, rambling walk-and-talk through central London, covering a very wide rantge of enterprise-architecture topics – in particular, how to expand and embed whole-enterprise architecture ideas and techniques in the Latin market. One of the best ways to do this will be through a stronger emphasis on values, which aligns better with Latin culture than it does to, say, British or (especially) US business-culture, where – as I’ve discovered to my cost – it’s often very hard to get business-folks to understand any concept of value beyond money or the near-mythical ‘shareholder-value’. There’s still a constant struggle to combat the baleful influence of IT-centrism in enterprise-architecture (and I’ll have to be blunt here and say that for the most part the Open Group and most of the big consultancies are really not helping us in this… ), but it’s probably somewhat easier to resolve this in Latin America than in mainstream ‘Western’ cultures. We’ll see: but it certainly looks like an interesting year ahead.

Interesting times, anyone?

Today’s the last day for the ‘Early Bird’ for the Open Group London conference (Twitter hashtag #oglon) on enterprise-architecture and the like. It’s being held in my ‘home-city’ – just over fifty miles away. In principle, it’s one of the flagship conferences for my profession. And there’s a fair number of people listed there who I’d really like to meet up with again. So in principle, yes, I ought to be there. No question.

But this time I’m not going. Sorry.

A bunch of different reasons, really.

One is that it’s become just that much too expensive. The full three-day conference is priced at well over a thousand pounds; even a single-day pass is something like four hundred. Sure, that’s not so much for a large corporation to pay, even in these cash-strapped times: but for a solo consultant that’s a serious amount that needs to be weighed against everything else. I’ve been to a fair number of Open Group conferences over the past few years, but to be honest the only way I’ve been able to afford it has been that they’ve allowed speakers to go in at the Member rate, which used to be something like a third of the price. Yes, in principle, I could save money by joining, and getting the Member rate the proper way: but again, that’d be several thousand pounds a year, because Open Group still only support a per-organisation membership, with no allowance at all for small companies or individuals. And to be blunt, I object strongly to Open Group’s notion that it’s ‘fair’ that an individual should have to pay the same membership-fee that’s paid by the whole of IBM: somehow OG still don’t seem to grasp that I and the many other solo-consultants in this space would literally be getting far less than a thousandth of the per-person value for our membership-money…

Which brings me to the second reason: I do enjoy those conferences, yet I’m really not getting much value for money there any more. The Open Group conferences are great if you’re into IT-architecture – which I’m not. IT-architectures are right out on the fringes of the work I do these days, which is mostly about the architecture of the enterprise as a unified whole. Open Group do of course insist that they’re doing ‘enterprise-architecture’, with TOGAF and the like: but in reality it’s still only enterprise IT-architecture – which is not the same thing at all. And whilst it’s true that there’s a been lot more mention of business-orientation in the descriptions for the past few conferences, in practice it’s clear that it’s still little more than a surface veneer on top of the same old IT-centrism. Which I suppose is fine, in its way, for IT-folks, but it doesn’t have much business relevance – let alone relevance at a true enterprise scope. To again be blunt, it’s still pushing the EA profession in a direction that all but guarantees business-irrelevance, and reinforces still further the infamous ‘business/IT-divide’ – which doesn’t help anyone in the longer term. I’ve had a lot of value from those conferences in the past; but in reality that value has mainly been to clarify for me that the Open Group’s version of ‘enterprise’-architecture was pretty much exactly what I’m not doing, and help me hone my understanding and explanation of what I am doing instead.

Open Group’s focus and heritage are all about IT standards and IT-architectures. Which is fine: someone has to do that, I’m very glad that someone does do that, and to me there’s no doubt whatsoever that Open Group do it very well indeed. Yet their involvement in enterprise-architecture has been more like an historical accident, a scope that grew and grew far beyond IT because the reality is that that’s the only way it would it work. Their natural reflex, though, is to keep trying to force it back into the IT-domain, where it frankly does not belong: enterprise IT-architecture is important in its own right, and is also important as one aspect of whole-enterprise architecture, but it is not the whole of EA! And now that there are other less IT-centric EA conferences, such as Integrated EA and IRM-EAC, it’s clear that I’m likely to have better value for my ‘conference-buck’ there than at yet another IT-only Open Group conference.

(There’s one aspect of enterprise-architecture, though, that fits right within Open Group’s chosen remit of ‘boundaryless information flow’ and that urgently needs their attention: standards for information-exchange between enterprise-architecture toolsets, preferably covering the span of the whole of the ‘toolset-ecosystem‘. Open Group have had a preliminary standard for this languishing on the back-blocks for half a dozen years or more: is there any chance it could revived and brought up to date?)

I’ll next be speaking on whole-enterprise architectures at AE Rio 2011 in Brazil next week, and at IRM-EAC 2011 in London in early June. If you’re going to either of those conferences, perhaps see you there?

And for Open Group London, and probably for other EA conferences as well, is it perhaps time to revive that fine old tradition of the ‘fringe festival’ – where those who don’t fit in with the criteria for the formal festival get a chance to showcase their work as well? Several folks have happily suggested that around the IRM-EAC conference we could have a ‘#nottheeac‘ meetup, complete with its own ‘official beer’ (London Pride, of course!); perhaps we could organise a ‘#notoglon‘ EA fringe-festival as well?

Either way, if you’re going to Open Group London and you’d like to meet up, just drop me a line: I’ll be around. Just not at the conference itself.