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?

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?

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

Strategy and architecture are different in some quite fundamental ways. Strategy sets the direction: that’s the whole point of any strategy-capability. Architecture identifies the available choices and constraints for the most effective structures, or configuration of structures, that could implement that strategy; it also usually makes some concrete suggestions towards design, but that’s where EAs should really be starting to hand over to the solution-designers, and so on down the implementation chain.

Strategy has a clear decision-making role; whereas it’s arguable that architecture should only have a decision-support role at the strategic level. The architect may well be landed with making key strategic decisions, perhaps for practical reasons, or because no-one else will accept the responsibility; but blurring the two roles together can be problematic, not least because of the risk of ‘cart before the horse’ strategies such as where an arbitrarily-chosen technology ends up driving the strategy, rather than the strategy driving the choice of technology.

For enterprise-architecture, this is another example of why it’s useful to distinguish between ‘organisation’ and ‘enterprise’. An organisation is tightly bounded by the respective rules; an enterprise is a much more fluid affair, bounded by shared-commitment to shared principles, vision and values. (In effect, as described in the previous post, the enterprise is a story.) Another way to understand the difference:

• the organisation is about ‘truth‘, about demonstrable compliance to extrinsic constraints
• the enterprise is more about ‘value‘, about mutual agreement and alignment with intrinsic constraints

An organisation and its rules can exist at any level, from a work-team to a huge conglomerate or an entire nation: hence a business is an organisation, with explicit legal boundaries of responsibility and control. Organisations can be nested, with the rules becoming more and more and specific as we move downward into the detail-layers of the organisation-hierarchy. So in this sense the IT-department is usually also a distinct organisation in its own right, an organisation-within-an-organisation, with its own rules and reporting-relationships. Similarly for each enterprise: these too can be nested, or intersecting – and usually are. There’s a special-case where the boundaries of an enterprise coincide with those of the organisation, which sometimes gives rises to the illusion that the organisation is the enterprise – but it’s important to understand that this is only a special-case, and one that is rarely useful for strategy or architecture.

If we follow the logic of this, some important themes start to become clear:

A strategy is a set of rules and guidelines for future action. It therefore applies primarily to an organisation (rules) rather than an enterprise (values).

A strategy is bounded by the context of an enterprise. To put it another way round, a strategy is only usable in relation to an enterprise. An enterprise-architecture, which identifies the structure and purpose of the selected enterprise-of-interest to the organisation, must always precede strategy – otherwise it will not be able to provide the necessary decision-support about the nature of the enterprise, on which the strategic decisions will depend. Without that architectural understanding, the assumptions about the enterprise on which the strategy is based may well be invalid – hence, for example, the prevalence of cart-before-horse ‘solutions’ in so many organisations’ IT-strategies.

A strategy applies to an organisation, not to an enterprise. This is a direct corollary of the two themes above.  Without awareness of this distinction, the rules of the strategy (extrinsic motivation) tend to feel ‘imposed’, and hence shut down commitment within the enterprise (intrinsic motivation).

A strategy for any given organisation must always be defined in relation to an enterprise with broader scope than that of the organisation. The enterprise defines the context for the strategy, and hence must be larger than the applicable scope for the strategy itself. Note also that if the enterprise boundary is the same as the organisation-boundary (‘the organisation is the enterprise’), there is literally no space for anyone outside to connect with the organisation, and hence no reason to do so – a classic source of failure in marketing and most other forms of ‘outward-facing’ strategy.

A strategy will almost certainly fail if any attempt is made to apply or impose it onto an enterprise that is larger in scope than the respective organisation. This again is a direct corollary of the previous two themes. In effect, what happens in such cases is that the encompassing enterprise is treated as if it is an ‘organisation’ that is under the control of the subordinate organisation. For example, attempts at monopolistic business-strategies will almost invariably cause resistance and rejection in the respective market (ie. enterprise), often by creating large numbers of anti-clients. For the same reasons, an IT-strategy that attempts to tell the overall organisation how to run its business is guaranteed to cause friction – further exacerbating the infamous ‘IT/business divide’ – and, again, will almost certainly fail as a result of that resistance.

A useful rule-of-thumb is that the enterprise in scope should be at least two to three steps larger than the organisation in scope, both horizontally and vertically. This guideline applies regardless of whether the organisation in scope is self-contained or is a subset of a larger organisation. For example:

• business-strategy: defined in relation to partners and supply-chain (horizontal), and customers, prospects and broader community (vertical)
• IT-applications: defined in relation to people-based and/or machine-based components of processes (horizontal), and business and its customers (vertical)
• IT-infrastructure: defined in relation to buildings, power-supplies, cabling and other physical infrastructure (physical-horizontal), IT service-management (people-based horizontal), and IT-applications and business usage (vertical)

Hence business-architecture and applications-architecture are part of the ‘enterprise-architecture’ for IT-infrastructure strategy – but to say that enterprise-architecture is solely about those specific IT-related themes is to miss the point. An enterprise-architecture is always about a scope larger than that of the respective strategy – whether the strategy relates to IT or anything else.

Most existing IT-centric ‘enterprise-architecture’ frameworks completely fail to understand this crucial point. TOGAF 8, for example, described the ‘enterprise-architecture’ sufficient to guide IT-infrastructure strategy: it was not suitable (because not sufficiently-broad scope) for IT-applications strategy or, especially, business-strategy. TOGAF 9 has probably expanded the scope sufficiently to cover IT-applications-strategy, but is still far from sufficient for business-related strategy – even though many IT-folks try to do this, and then wonder why there’s then an increase in resistance from the rest of the business. TOGAF’s horizontal scope is also notoriously inadequate, describing all non-IT infrastructure-level items as ‘business’ (confusing horizontal with vertical); FEAF’s reference to ‘Human Capital’ and ‘Other Fixed Assets’ indicates a somewhat better grasp of horizontal scope, but still attempts to define strategy for higher-level organisation, from IT (‘department’ level) to ‘business’ (whole-of-organisation level). A whole-of-organisation or ‘business’ strategy’ will necessarily depend on a whole-of-enterprise architecture that describes the context two or three layers outward from the formal boundaries of the business-organisation itself.

So in effect every architecture-discipline can also do strategy – but only for the ‘organisation’ implied by their own discipline, and should only do so with the decision-support of an architecture that has a broader scope than that of the respective discipline. In practice, this means that IT-architects can of course do IT-strategy, but should only do so if they have a solid understanding of the enterprise (ie. ‘the business’) within which that IT will operate. The same applies for process-architects and manual-process strategy. And business-architects may also do business-strategy, but only if they have a solid grasp of the broader context described by a whole-of-enterprise architecture that can summarise the context of partners and suppliers, clients, prospects, non-clients, anti-clients and the entire business milieu.

To do strategy, you must be facing outward, towards the enterprise. To do design, or to convert strategy to tactics, you need to be facing inwards, towards the fine detail. The aim of strategy is to define rules; much of architecture is more about identifying and expressing shared values. Expecting just one person to do all of these things is a big ask – especially in a large, complex organisation. Hence, although architects can also do strategy on the one side, and design on the other, it’s probably wisest wherever practicable to keep those roles apart.

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

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.