Tom Graves / Tetradian

Back at the launch of TOGAF 9, some eighteen months ago, one of the Open Group leads took me aside to a quiet corner of the hall. He looked around, as if to make sure that none of his colleagues could overhear. “You know what’s missing in TOGAF?” he said, in a near whisper. “People. There’s nowhere for people anywhere in the architecture.”

And he’s right: there isn’t. But it’s not just TOGAF: it’s the same with just about every other mainstream ‘enterprise’-architecture framework. Unlike TOGAF, the FEAF PRM does include a placeholder for what it calls ‘People’ or ‘Human Capital’ – but in essence does nothing with it. The Oracle EA Framework [PDF] includes a section called ‘People, Process, Tools’ – but it’s only about the people who do the architecture work, not the people within the architecture itself. CapGemini’s Integrated Architecture Framework covers What, How and With What – but there’s no mention of Who. (Oh, unless you look in the respective ‘Business Architecture’ sections, which in essence, as usual, are a jumbled-up, meaningless, unusable grab-bag of ‘anything not-IT that might impact on IT’.)

The only mainstream architecture-framework that does explicitly include people is the granddaddy of them all: Zachman. The original version, it’s true, only addressed What, How and Where; but the first revision, completing Kipling’s set of ‘Six Honest Serving Men‘, did make a point of emphasising the importance of Who.

The problem, as I’ve explained elsewhere, is that Zachman’s structure doesn’t really work in practice. Sure, it looks good, it’s easy to read, and those six interrogatives make immediate sense (in English, at least, if not always in other languages). But despite Zachman’s own insistence that the framework covers the whole enterprise, the examples given are all for IT only; it’s based on a metaphor of ‘engineering the enterprise’ that almost by definition cannot work in any real human enterprise; and it’s actually missing an entire dimension – distinctions between fundamental asset-categories and the like – without which it cannot be made to make sense for key architecture-concerns such as implementation trade-offs, load-balancing and disaster-recovery.

Back about three years ago I did a lot of work on ‘Rethinking Zachman‘, ending up with a revised taxonomy-framework that looked like this:

I’ve continued to tweak the various labels since then, and they’re still not quite settled, but the current single-row version that I’ve used in my ‘Enterprise Canvas‘ series looks like this:

The point here is that there are at least five fundamentally different things going on around ‘Who’:

• what the person does – which is what I’ve labelled ‘Capabilities’
• how we connect with the person – which is what I’ve labelled ‘relational Asset’
• how people (or roles) relate with each other, in terms of organisational structures etc – which is what I’ve labelled ‘relational Location’
• what each person is responsible for – which is part-implied here in ‘Decisions’, but is better described in a crossmap with a RACI matrix or equivalent
• who the person is – which isn’t described here

To me, Zachman’s ‘Who’ is a muddled mixture of all of these, which we can sort-of get away with as long as we can safely assume that people and IT and machines each do entirely different things. In terms of skill-levels, each of those groups tend to work on different things, too: machines follow simple rules, IT can also use algorithms, and people tend to be asked to take over for anything that the machines and IT can’t do. But if we use Zachman’s ‘Who’-merge, if there’s a context where they do all have to do the same things – such as when real people have to take over IT-type tasks, in disaster-recovery or the like – we suddenly find that we have no way to describe what’s actually going on. Hence we do need to rework the taxonomy and ontology, to put all of these different items in their respective places.

(The ‘Who’-merge kludge sort-of works because, within IT and machines, function and capability are structurally merged – so at first glance it can seem that we don’t have to assess them separately. Unfortunately, for architectural abstraction and redesign, we do need to treat them as separate: function uses assets, which are acted on by capability, which when linked together provides service, which when linked together provides process, and so on – all of which items can, may or should be interchangeable according to context and need.)

In principle, part of that exclusion of actual people from the frame is deliberate:  people are not assets or ‘units of production’ or whatever, but are themselves as themselves. (The relationship that an organisation has with a real person is an asset – and an extremely important asset at that, which needs to be maintained as an asset.) If we treat people as assets, we find ourselves straight back into the worst of Taylorism, regarding people as interchangeable objects – which is not a good idea.

(There’s also a danger, though, that describing capabilities separate from people would again lead us back into Taylorist temptations. We build capabilities into machines and IT, and those capabilities are [usually!] distinct and definable, associated with the entity-type as itself – the entity does the function using the capability. Each entity of that type is interchangeable with any other – in principle, anyway. But real people carry or express or enact or whatever a very complex mixture of capabilities: in terms of those capabilities, each person is different from any other – and even different from themselves, varying day to day, or even from moment to moment – so they are not interchangeable in the same way. The intersection of different capabilities within each person enables and requires fundamentally different approaches as to how we structure and partition work: treating people as interchangeable ‘production-units’ with fixed capabilities and skill-levels quickly guarantees a lowest-common-denominator result, leading to very low overall effectiveness. But that’s another story requiring another very long post! )

As a result of all of this, I tend to regard real-people as somewhat orthogonal to the architecture – they cut across it, but are not in it as such. There are a lot more places where we describe architectural themes that relate to people, and with people, and about people. Yet they’re still not in the architecture – and arguably shouldn’t be.

But the catch is this means there’s still no explicit place for people as people within the taxonomy of the architecture itself: instead, we need to describe them kind of separately-and-in-parallel-with the architecture. Yet is this a problem, in real enterprise-architecture practice? And if so, how much of a problem is it? What impacts does it have?

Suggestions/comments, please?

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?

Another weblog item that’s been triggered by a question on Twitter, though in this case it came via a personal ‘direct message’ from Australian enterprise-architect Mike Aikins (@AussiMike):

Surely there are groups focused on the art and discipline of strategic planning and execution? How can we coalesce #entarch and these groups

Often there will be several “groups focused on the art and discipline of strategic planning and execution” – or there should be, at any rate. It’s true that enterprise architecture – and especially IT-architecture – will often be landed with a strategic role, though I would suggest that that’s more by default than by actual understanding of what EA is or does.

(Once again this has turned out to be a long explanation, so read on after the ‘Read more…’ link.)

Read more…

This one starts with a blog-post by John Polgreen, of training-group Architecting the Enterprise, called “TOGAF for Feds – Isn’t TOGAF too IT-centric for Fed EA?”. The key issue that of scope:

TOGAF is often associated with IT architecture, as opposed to the business-driven, holistic enterprise architecture espoused by the US Federal government.

John argues that whilst there’s still room for improvement, TOGAF 9 is much more business-focussed than the previous versions:

The present TOGAF definition of enterprise architecture – although holistic – doesn’t seem very business-driven: “…the description of an enterprise as a system in terms of its components, their inter-relationships, and the principles and guidelines governing the design and its evolution.” Contrast this to a definition suggested by Paul van der Merwe to be included in the next release of TOGAF: “The continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.”

He then points to the TOGAF ADM (Architecture Development Method) as the solution. But to me the current structure of the ADM is a key part of the problem, not the solution. Since John asked “What are your thoughts? Is TOGAF too IT-centric for your agency? I’d very much like to hear your opinion”, I appended the following comments to his post:

The short answer to “Is TOGAF 9 too IT-centric for your agency?” depends on two factors:

• whether you think enterprise architecture is primarily about the relationship between business and IT, versus whether it’s about the enterprise as a whole, of which IT is only one small part;
• whether the work of the agency is centred around information (eg. IRS), versus some other domain(s) (eg. Parks & Environment)

If your concern is more with the first side of both of those two spectra – the business/IT relationship, in an information-oriented agency – then TOGAF 9 will be a very good fit, with TOGAF 9 a valued improvement over the previous version. For those contexts, the short answer would be ‘No’: TOGAF is not too IT-centric for the agency.

But the fit becomes progressively worse as you move to the other side of either of those spectra. Unlike FEAF, TOGAF has almost no concept of people (FEAF’s ‘Human Capital’), or of physical things other than IT-infrastructure (FEAF’s ‘Other Fixed Assets’). If your need is to build a whole-of-enterprise view for an agency that deals primarily with people or with physical things, TOGAF 9 provides little real gain over TOGAF 8. It’s true there are a few real improvements – such as the section on Capability-Based Planning – but in some ways it anchors the architecture even more rigidly into the IT domain. For those contexts, the short answer would be ‘Yes’: as it stands, TOGAF would definitely be too IT-centric – and in some cases even dangerously so.

The key problem-area is one of scope. The TOGAF 9 ADM retains from the previous version exactly the same fixed IT-centric scope, with a linear progression from ‘Business Architecture’ – in essence, “everything not-IT” – through ‘Information Systems’ to ‘Technology Infrastructure’. The end-point is always to clarify the design and structure of the IT-systems: everything else is peripheral to that purpose. If the architecture has any other purpose – as it will do in most agencies, especially as architecture maturity develops – the current design of the TOGAF ADM may become an active hindrance almost every step of the way.

(In principle the new section on Iterations should relieve this to some extent, but the iterations concept is not well-enough described to be useful in practice: in essence the ‘new’ ADM is still a Waterfall model with a few half-hearted attempts at Agile vaguely tacked on, with a governance model that fits neither approach well enough to be reliable – especially at an enterprise-wide scale.)

The ADM principle is sound, and provides a much-needed methodology that FEAF lacks. But for anything other than IT-oriented ‘enterprise’-architecture in information-centred agencies, TOGAF 9 is usable only if we can break free from the existing ADM’s fixed IT-centric scope. To do this, we need to rethink the detailed structure and sequence of the ADM, whilst retaining the overall principles of the methodology.

Key requirements for such a revision include:

• stronger support and governance for Agile-style iterations
• support for consistent management of iterations of any duration and any level of nesting
• support for any architecture scope, dependent on the needs of each iteration
• explicit removal of any assumptions about the centrality of IT

The latter requirement also supports architectural assessment of contexts where IT may not be involved or even available, such as in process-design and planning for some disaster-recovery/business-continuity scenarios.

For one example of one such modified version of the TOGAF ADM, see http://tetradianbooks.com/2008/10/silos-method-ref/. A matching framework to identify scope for architecture iterations is at http://tetradianbooks.com/2008/12/silos-frame-ref/.

And the last in the current series of slide-decks that I’ve placed on Slideshare.

This one’s from early 2007, and describes some of the analysis that I did at that period to find ways to break free from the usual IT-centric constraints of so-called ‘enterprise’ architecture. Full title is Whole-of-enterprise architecture: Extending enterprise architecture beyond IT. Some of the slides have been re-used in other presentations in this series, but the detailed content is specific to this example. Hope you find it useful, anyway.