Tom Graves / Tetradian

Nice to see that even the ‘big fish’ are finally ‘gettin’ there’ on the real scope of enterprise-architecture…

A month ago we saw Open Group begin to re-frame their previous IT-centred approach to EA into a new style of ‘enterprise transformation’. (The conference was still more IT than anything else, of course, but at least it’s a solid move in the right direction.)

Then a couple of weeks back it was academic and EA-luminary Jeanne Ross making clear her opinion that enterprise-architecture does not belong in IT, under the CIO. To quote her interview in CIO.com, “companies need to acknowledge that ‘architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO’”.

And now it’s Gartner, at this year’s Gartner Enterprise Architecture Summit in London earlier this week. I wasn’t able to get there this time, as I’m currently ensconced in central-America working on a bunch of EA-related projects; but fortunately the indefatigable Gerold Kathan was there, sending out a whole stream of useful tweets:

• gkathan: #entarch has no value until it is acted upon – deliverables should not be confused with value #gartnerEA
• gkathan: customize and adapt your #entarch framework – industry frameworks should be used for inspiration, not perspiration #gartnerEA
• gkathan: bringing something new like #entarch into top level management is hard: they will treat it as enemy in the beginning #gartnerEA
• gkathan: “EDD” is impacting application lifecycle: “executive deficit disorder” – short term focus and irrational decisions #gartnerEA

But what really caught my eye was this little beauty:

• gkathan: you have to reach out the 4 walls of your organization – extended enterprise includes e.g communities #gartnerEA

To which I can only sigh ‘Hooray!’…

I’ve no idea which of the Gartner consultants it was who said it; and since Gartner itself seems to have a policy of not crediting ‘outsiders’, I’ve also no idea if that comment has any link to the various conversations I’ve had with Gartner folks over the years. But just for the record, here’s my version of the full scope that an organisation’s EA must address, all the way out beyond the market to communities and more:

I’ve used a few variants of that in my EA presentations over the years – such as ‘What is an enterprise?‘ and the very-popular ‘The enterprise is a story‘ – but that’s the core idea, anyway. Nice to see that Gartner too is at last officially acknowledging that kind of scope for EA.

On the other side, I ought to acknowledge another ‘big fish’ that sort-of got there quite a long time ago. I was trawling through my downloads on this little-used netbook, and came across a report from Infosys – ‘Enterprise Architecture Expands Its Role In Strategic Business Transformation‘ [PDF] – from way back in 2008. It seems that even back then, the IT-centrism that still dominates ‘the trade’ was beginning to be challenged a lot more than most of the ‘big fish’ would be willing to admit:

Architecture steps out of the scope of IT and becomes part of planning and implementing strategy. In 22% of responding organizations, architectural processes are already being used for general business transformation.

And there’s this in the report, too:

Transformation is implemented in multiple streams within multiple units and functions of the firm. Today’s approach of architecture – looking at everything outside of IT as ‘the business’, and trying to access it through fairly generic, coarse-grained models – is bound to fail. A future enterprise-architecture will be ‘the architecture of the enterprise’. It will need to address the whole organization and each of its functions through appropriate models which are meaningful to the specialists of each area, and help them drive transformation. This means that it will have to provide structured models to represent architectures for production, research, finance and HR – much as it has for IT.

There’s a subtle trap in that that view is still centred around the organisation – ‘inside-in’ or ‘inside-out’, rather than the essential ‘outside-in’ view indicated in the Gartner quote above –  but at least it’s a lot broader than the obsessive IT-centric view that predominated then, and is still all too common even now. Credit where credit’s due – and worth reading the rest of the interestingly prescient report, too.

Gettin’ there, anyway – slowly, perhaps a bit too slowly for comfort still, yet we are gettin’ there. Feels good.

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?

A couple of weeks back, Gabriel Morgan of Microsoft’s internal Enterprise Strategic Planning unit posted an article on what he described as a ‘breakthrough’ in enterprise-architecture, “A Breakthrough: Maturing EA to be a Catalyst to Transform the Company“:

It’s time to rethink enterprise architecture people. Well, at least here in Microsoft IT’s Enterprise Architecture Team it is.

… For the past year or so, I’ve led a crack team of experts focused on aligning IT and the Business, and from this journey I wanted to share with you my current thinking. My team is called Enterprise Strategic Planning and it is a service team dedicated to enterprise-wide strategy and planning. Our initial goal is to become critical to the planning process with the intention of providing data to qualify an optimal set of IT Programs to invest in. … In this article I wanted to share with you something that has occurred to us during our journey and describe some changes we are making that I think is ground-breaking in the Enterprise Architecture domain.

Assuming a primary goal of EA is to align IT to the Business, the problem is that most, if not all, EA Frameworks are not equipped to actually deliver on this goal. They are limited to drawing associations from IT things … to Business things … . Some of the more mature EA teams have partnered with their finance department to apply financial modeling … to these associations to help describe business value in monetary terms and possibly start a chargeback model. These are all great accomplishments but at best they only capture how IT ‘relates’ to the Business. That is, these EA Frameworks and methods are more about IT transparency, not alignment.

I would have to admit that my first response to this would best be described as ‘unprintable’…  (The polite version of ‘unprintable’ would look at certain key phrases in the above, such as “It’s time to rethink enterprise architecture, people”, “a crack team of experts” and “Assuming a primary goal of EA is to align IT to the Business”, and thence to make extremely disparaging remarks about Microsoft, about apparent arrogance, about a supposedly innovative company being literally years behind the leading edge of enterprise-architecture, about breakthroughs that aren’t, and about the vapidity and shallowness of IT-centric assumptions… Oh well…)

My second response, after I’d had a chance to calm down a bit, was perhaps a bit more charitable, if still more than a little sarcastic: something more along the lines of “Welcome to the club, glad to see you’ve woken up at last, any chance we can actually talk about enterprise architecture?” – because to most of us who have been working at that leading edge of EA-development, this supposed ‘breakthrough’ is very old news indeed. It’s actually the understanding that existed decades ago, before IT-architects came in and hijacked the entire industry; several of my IT-oriented clients had each reached that same point independently half a decade or more ago; and even the Open Group, after we’d nagged and bullied and cajoled them for so long, finally ‘got it’ late last year, with “evolving EA from IT to business” now becoming an explicit key theme of current Open Group (TOGAF) conferences. So in terms of the overall EA industry, there’s not a single thing that’s actually new in that Microsoft ‘breakthrough’: and hearing someone call it a ‘breakthrough’ is frustrating in the extreme.

But that second response still misses the point: this actually is a breakthrough – for Microsoft. Which, because of who Microsoft are, means that it’s also a real breakthrough in another sense as well.

Yes, it’s frustrating to note that, from what appears in the article, Morgan and his group seem not to know that much about any ‘prior art’ – not even from other Microsoft EAs such as Nick Malik, who writes a very good ‘Inside Architecture‘ column at the same MSDN weblog-host, and is even listed in the links on Morgan’s weblog. Yet there is real change here: important change. Take a look, for example, at the business-architecture references that Morgan lists later in the article:

• Porter Five Forces
• Balanced Scorecard
• Business Model Canvas
• Geoffrey Moore ‘Core vs Context’

There’s no IT directly involved in any of those models (unlike, say, Ross, Weill & Robertson’s much-lauded ‘Enterprise Architecture as Strategy‘, which still takes a strongly IT-centric view of business-strategy). For someone like Microsoft, whose whole business-focus is and revolves around IT, that absence of IT-centrism is huge… definitely a real breakthrough.

I also need to remember that my own role in enterprise-architecture is very different from theirs. Morgan and his team are practitioners, dealing with the day-to-day realities of real-world architecture in a very large organisation. I’m a practitioner, too, yes, but my own work these days is mostly about setting-up architecture practices, troubleshooting, and doing practice-refresh for existing architecture groups – it’s consultancy, not mainstream production-level architecture. So although I’m a practitioner, my practice is mostly about theory, futures, creating new tools and techniques: which means that if my work isn’t well ahead of the mainstream, I wouldn’t be doing my job properly. Yet that view gives me a rather jaundiced perspective of the industry: too easy to forget that it does take years – several years at least – for the ideas and themes and concepts that we’re working on now to filter down into everyday EA practice. In short, too easy for me to become arrogant about what I see as other people’s ‘arrogance’… Oops…

Coincidentally, Gartner published their current ‘EA Hype Cycle’ this week, described in a press-release and a one-page graphic. They state that there are now two distinct generations of EA: the ‘traditional’ IT-centric one, which has now reached what Gartner term ‘the Plateau of Productivity’; and an upcoming “more business-focused” version that will help to prevent EA from falling permanently into ‘the Trough of Disillusionment’.

To me, though, these two ‘generations’ respectively represent maturity-levels 2 (“clean up the mess”) and 3 (“top-down strategy”), out of five distinct maturity-levels, as described in my book ‘Doing Enterprise Architecture‘. There are at least two more ‘generations’ to go before we reach a fully usable architecture for the enterprise; and, worryingly, far too few architecture-teams seem to have properly implemented maturity-level 1 – “what business are we in?” – which in the longer term places the entire architecture at risk. (It’s not adequately addressed in either TOGAF or FEAF: TOGAF 9 does sort-of include part of it in a kind of half-baked form in the muddled mess that it describes as ‘Business Architecture’, but that’s about it. To me, the only major framework that does cover it properly is Kevin Smith’s Pragmatic EA, which is still not as well-known as it deserves to be.) So there’s a long way still to go – and a lot of repair-and-refresh to do, too, to clean up the problems caused by the IT-centrism of the existing ‘enterprise’-architecture frameworks.

But I’m wondering just how much this article of Morgan’s should change the view that Gartner shows us. Gartner shows ‘Business-Driven Architecture’ as having only just reached ‘the Peak of Inflated Expectations’: yet the TOGAF conferences, and now Morgan’s article, seem to show it much further on, more like the start of ‘the Slope of Enlightenment’. Fact is that Microsoft is just about as mainstream as they get: so if Microsoft’s EA has now turned beyond IT-centrism to a more explicit whole-of-business focus, what it really tells us is that business-driven architecture has just gone mainstream.

It’s still not a ‘real’ enterprise-architecture as I would understand the term: but it’s a heck of a lot better than than the old IT-centrism. That is a real breakthrough – and very good news indeed.

Watch This Space, at last?

Might seem a somewhat strange mix, but the link between them is Gartner‘s ‘new line of research’ in the enterprise-architecture/business-transformation space.

‘Hybrid thinking‘ is a term that Nick Gall and others in Gartner’s enterprise-architecture team have adopted from a Fast Company article in August 2009 by Dev Patnaik, ‘Forget Design Thinking and Try Hybrid Thinking‘. The idea is that the term ‘design thinking’ – currently sweeping the business-schools and elsewhere – is too limited, and supposedly only applies to product-design and the like. (As a qualified graphic-designer turned enterprise-architect, I think Patnaik and Gartner are kind of missing the point – for example, see the excellent BBC documentary ‘The Genius of Design: Blueprints for War‘ [60 mins; UK only, until 11 June 2010]. But never mind – Gartner are obviously entitled to use a different term if they wish. ) Hence a broader-based alternative, which they call ‘hybrid thinking’.

The Gartner article ‘Introducing Hybrid Thinking for Transformation, Innovation and Strategy‘ may well fall behind their paywall by the time you read this; but there’s a link here to a PDF version [330kb] which may be available for longer, and also a slidedeck-plus-voiceover [video, 50mins] of Nick Gall’s presentation at the Gartner EA Conference in London in late May.

The Gartner paper defines ‘hybrid thinking’ as:

An organic discipline for taking on wicked problems by iteratively implementing transformative, innovative and strategic change via the co-creative exploration of human-centered experiences that are culturally meaningful, technically feasible and economically sustainable.

Which is what many of us would call enterprise-architecture, of course – in its proper sense of ‘the architecture of the enterprise’, that is, rather than ‘IT-architecture with a purported enterprise-wide scope’, which is what Garner has been describing as ‘enterprise-architecture’ until now. (And still does, if you read the Gartner paper in depth.) But Gartner describe ‘hybrid thinking’ as a kind of metaphoric structure where a human-centred form of design-thinking sits at the centre-point of a group of six intersecting areas of interest:

• enterprise-architecture [by which Gartner mean enterprise-wide IT-architecture]
• wicked-problems
• complex-adaptive systems
• pattern-based strategy
• resilience / panarchy
• network science

They also assert that “hybrid thinkers must also exhibit particular characteristics and and attitudes, such as the following: creative, empathetic, integrative, comfortable with ambiguity, optimistic, experimental” – which again are themes that others have argued are essential for whole-of-enterprise architecture.

What’s perhaps surprising is one of the key sources referenced by Gartner for their new model: the US Army. (Perhaps it shouldn’t be so surprising, since much the same people were involved in the development of one of the most valuable tools in organisational learning, the After Action Review.) If we think about it, though, the Army often has to deal with a far more extreme version of the kind of conceptual conditions that we face in present-day business: the need to make fast, accurate, effective decisions in real-time in the midst of inherent uncertainty and inherent complexity, with limited resources and incomplete information, where one false move can send the situation spiralling far out of control and with far-reaching consequences.

So perhaps again it shouldn’t be a surprise that the Army have turned to design-thinking as a guide for action: what is a surprise is how completely they’ve turned to it, because they’ve actually rewritten the whole of their operations-manual on that basis. Although they still use the somewhat simplistic language of ‘command and control’ in a few places, almost everything else has a solid grasp of true complexity – including the enormous complexities of culture. Gartner, for example, include the following quote in their Hybrid Thinking paper:

The introduction of design into Army doctrine seeks to secure the lessons of eight years of war and provide a cognitive tool to commanders who will encounter complex, ill-structured problems in future operational environments… As learned in recent conflicts, challenges facing the commander in operations often can be understood only in the context of other factors influencing the population. These other factors often include but are not limited to economic development, governance, information, tribal influence, religion, history and culture. Full spectrum operations conducted among the population are effective only when commanders understand the issues in the context of the complex issues facing the population. Understanding context and then deciding how, if, and when to act is both a product of design and integral to the art of command.

The exact same principles also apply to whole-of-enterprise architecture – hence the US Army materials will likely turn out to be a really valuable resource for enterprise-architects. Some examples include:

• home-page for the US Army Combined Arms Center’s ‘FM 5-0 The Operations Process’ manual
• FM 5-0 ‘Information Briefing’ [.PPT, 11.0Mb] – a very useful overview of the role of design-thinking in the new model
• School of Advanced Military Studies: ‘Art of Design: Student Text v2.0‘ [337pp; .PDF, 12.4Mb] – long but very useful

Most of the materials emphasise the warfighting role rather the civil-support/disaster-recovery role, which is a slight disappointment – the latter would probably have provided even better parallels for conventional enterprise-architectures. But what there is, is still a real eye-opener in many places, and a real breath of fresh-air for who’ve struggled for too many years with the stifling IT-centrism of so many other ‘enterprise’-architecture frameworks. Well worth a read, anyway.