Tom Graves / Tetradian

Still plodding away on ideas for a systematic process to translate a business-model in Business Model Canvas down into real-world architecture and implementation. (This links up with quite a few previous posts, such as ‘More on business-models‘, ‘Enterprise-architecture – let’s keep it simple‘ and ‘Is Archimate too IT-centric for enterprise-architecture?‘)

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

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…

This one started from a Tweet from Vince Outlaw, one of the attendees at the recent Gartner EA conference in San Diego:

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

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.

The following a selected subset of the Tweets and links sent out by attendees and other from the Open Group (TOGAF) conference on enterprise-architecture, IT-security and cloud-computing. Given my own interests, I’ve emphasised enterprise-architecture, but I’ve included many of the others as well. (If you want to see the full set, follow the ‘#ogsdg‘ hashtag on Twitter.)

I wasn’t able to attend the conference this time, hence many thanks to @theopengroup, @togaftm, @stevenunn, @masrod, @aleksb6, @TechnoDad and all the others who kept us ‘outsiders’ in touch with what went on.

For what it’s worth, I’ve added my own comments at the end of some of the Tweets, in italics and preceded by a ‘<’, <like this. Feel free to ignore, them, of course.

Read more…

As mentioned in the previous post, one of the key characteristics of ‘crossing the chasm’ to a viable whole-of-enterprise architecture is the explicit inclusion of people. In short, we need to be able to model and map where people fit in relation to the architecture.

But there’s a catch. A big catch. People should not be ‘designed in’ to the architecture.

We can see this well in building-architecture: there, the only case where people have been literally part of the architecture is that of the anchorite in the mediaeval church. An anchorite would choose to be permanently walled into a cell that was part of the fabric of the building, to act as a spiritual anchor for the people’s faith. Somehow I don’t think we’ll be likely to find many people willing to do the same for today’s for-profit enterprises…

Yet in most building-architecture, evidently, people are everywhere. Other than in certain special-cases – the equivalent of an IT-specific ‘enterprise’-architecture, perhaps – the building and its purpose and design will centre around people, about what people do, why they do it, what the building represents to people, and so on. And the equivalent of that ‘people-centrism’ is what we need in a viable enterprise-architecture.

But if we can’t design people into the architecture itself, how do we map people within the architecture? I would suggest four key themes:

• vision and values
• relational-assets
• roles and responsibilities
• capabilities and competencies

Let’s look at each of these in some detail.

Read more…

This one extends the models-for-enterprise-architecture theme from the previous post. Although for me this theme goes back a long way, the start-point here was a Tweet from Dutch EA consultant Martin van den Berg (@bergmart) that triggered off a veritable flurry of replies:

• bergmart: I’m more and more convinced that it should be forbidden to show ArchiMate diagrams to business management #entarch #bizarch
• EAatWork: @bergmart why should it be forbidden to show archimate diagrams to business management?
• blomr: @bergmart @eaatwork Depends on level/type of business management + depends on complexity of the diagram(amount of (different) objects&rel’s)
• ArchiTool: @bergmart I’m intrigued to know why. Are they infrastructure models?
• bergmart: @ArchiTool I’m not talking about infrastructure models but business / information models
• ArchiTool: @bergmart @EAatWork Then maybe break them down into smaller focussed viewpoints?
• bergmart: I think we need to find other ways. Business Model Canvas is a much friendlier way or use the operating model stuff of Ross
• ArchiTool: @bergmart Right. Higher levels. And ArchiMate could be used in addition for more detail if needed? // Hmm….Business Model Canvas in Archi? Development of the Sketch View? #archimate #bmc
• bergmart: @ArchiTool Yes, in the architecture & engineering communities
• ArchiTool: @tetradian Synchronicity is nudging me toward possible Bus Model Canvas & Ent Canvas implementation in Archi. Reading up on it now…
• tetradian: @ArchiTool aiming to have 2 new posts for you soon: models as anchors for discussion/decision-records; roles of tools in toolset-spectrum
• tetradian: @bergmart ‘don’t show Archimate diags to biz mgmt’ – in my experience showing them BPMN diagrams is an even worse idea…
• bergmart: @tetradian Can imagine!
• EAatWork: @bergmart too complex from a modelling language point of view (archimate) or too complex because the diagrams are too complex?
• bergmart: @EAatWork Both
• EAatWork: @bergmart  I think that the concepts are ok but the  different relation types are causing the confusion (look all similar) for bizz mgmt
• tetradian: @bergmart @EAatWork with BPMN diags, prob was need to translate from abstract to concrete – so overlay Archimate rigour w visual images?
• ArchiTool: @bergmart But with Business Model Canvas approach maybe managers are concerned with $$$$$$ rather than architecture and internal workings?
• ceri: @tetradian @bergmart To quote @wilm on Tuesday “never ever show the entire model to ANYONE, only the view that is relevant to them” #jiscfsd
• bergmart: @EAatWork Yes, the arrows are the main problem. The concepts are ok.
• bergmart: @ArchiTool Nice  with Business Model Canvas is the combination of $$$$ with coherency.

As mentioned in that back-and-forth above, I’ve had painful first-hand experience of what happens when we show ‘formal’-type EA diagrams to executives, as described in this quoted from my book Real Enterprise-Architecture:

In our first attempt to show the true value of [a proposed] logistics early-warning system, we made the mistake of showing the process-flows [to the executive] in the form of a Business Process Modelling Notation diagram. BPMN is great for the formal modelling rigour needed by software engineers, but not for a board-level presentation: the blank stares and silence from round the table sent us away in shame.

For the next meeting, we redrew the diagram, with the exact same process-flows, but replacing the bland BPMN boxes with clip-art pictures of trucks, conveyor-belts, fork-lifts, sorting-machines, delivery staff. This time it clearly made sense: we gained our go-ahead.

These senior people weren’t ‘stupid’: when we explained it in their own terms, they understood straight away what we were aiming to do. The problem before was that they didn’t have time to learn an abstract language and translate it back into their concrete world. As architects, we did need that level of abstraction: but it was also our responsibility to each audience to do the translation from the abstract into the everyday.

This is going to be a long one… sorry…

Read more…

Just posted on Slideshare my slidedeck ‘Unpacking Business-Architecture‘, from the Biner/OpenGroup enterprise-architecture conference in Stockholm earlier this week.

It also represented the first fully public outing for the Enterprise Canvas model, and, in effect, the launch for my latest book, Mapping the Enterprise, which focusses on the Enterprise Canvas.

Many thanks to Lars Lundgren, Emma Dahlquist and the others of the Biner and Open Group crew who made it such a great conference.