Tom Graves / Tetradian

In enterprise-architecture, how do we disentangle business-function, business-capability and business-service?

This one’s for Adam Johnson, particularly as a follow-on to his comment to the previous post ‘More on EA and asset-types [Part 4]‘:

I perceived your usage of function to be business function at a certain level of abstraction that could be perceived as a capability. Sorry..and now based on your reply I think I understand, but lets try an example…

Capability – Marketing Resource Management – What we are capable of
Function – Marketing
Service – Create Marketing Resource

Capability – Disaster Management:Alert / Notification Management
Capability:Actor – Disaster Recovery Lead
Function – Disaster Recovery:Disaster Recovery Triage
Service – Alert / Notify Disaster Recovery Team

Perhaps my take on actor is a bit off, but I’m trying not to think too much…

I’d say that both of those sets are pretty close to what I meant – thanks. The actor of ‘Disaster Recovery Lead’ makes sense as the person (in this implementation) who is able to deliver the work of Alert/Notification for Disaster Management.

It still seems worth going over all of this once more, to hammer home both why clarity is needed, and what we can do about it.

The biggest single problem here is that people tend to use ‘business-function’, ‘business-capability’, ‘business-service’ and sometimes even ‘business-process’ as either direct synonyms or near-synonyms. Sometimes they’re at the same level of abstraction, sometimes not; either way, there’s very little clarity as to which is which, the same term is used by different people to mean different things, and different terms to mean the same things. The result, unsurprisingly, is a lot of confusion – and that confusion certainly does matter when we’re trying to describe or implement an architecture.

To cut through all of this, and to try to introduce some certainty and precision, I’m using a fairly flat set of definitions for the levels of abstraction, and for certain key terms that are used within all layers of abstraction. (Okay, almost all layers – some terms aren’t needed in ‘higher’ levels of abstraction, as we’ll see later.) I’m well aware that others may define these items differently: these are just the definitions that I use with Enterprise Canvas, to manage consistency across the entire architecture space.

First, we have a set of definitions for levels of abstraction, from row-0 – the vision/values layer, ‘the unchanging future’ – to row-6, ‘the unchangeable past’. Each of the rows between those two layers – the Zachman rows 1-5 – represents a changeable future, each row coming closer to the moment of ‘the travelling-Now’; and every one of those rows adds something more to the architecture:

Note, though, that the inverse also applies: each ‘higher’ layer is less definite about the content of the architecture. So, for example, the moment we specify a particular technology, a particular type of implementation, we can’t be above row-4; the moment we specify any kind of content, we can’t be above row-3; row-2 describes relationships, between ‘relevant items’, but no content; and row-1 is just lists of ‘relevant items’.

The reason for the pedantry is that we model things in different ways at different levels of abstraction; and there are different dependencies, which don’t link well – or don’t make sense, rather – across different levels of abstraction. (Hence in Enterprise Canvas we model relationship within a layer by flow- and composition-relations, but between layers with realisation-relations.)

The catch is that what is nominally the same entity may recur in different forms at different levels of abstraction – the same name, the same overall ‘thing’, yet not actually the same entity or same type of ‘thing’ from an architectural perspective. To complicate this even further, it’s common to use an abstract ‘container’-entity at one level as an aggregation of a whole lot of other entities for the next level down – hence a business department is an aggregation of a cluster of facilities and activities, in both a metaphoric (abstract) and administrative (literal) sense.

Given all of that, when we talk about a ‘business function’, what exactly is it?

Uh… werll, ‘s a business-function, innit, know what I mean?

We can just about get away with that inclarity in a general business conversation; we definitely can’t get away with it in architecture. Hence the necessity for Mr Pedant…

In row-2 and above, Zachman’s distinction between What, How, Where, Who, When and Why work well enough. In lower rows, though, they can get seriously misleading – especially around ‘Who’, which gives us a very muddled confusion between the agent for a capability versus the person responsible for that capability. In row-3 and below, once we start to describe service-content in proper detail, we need a lot more precision – hence that service-content checklist in Enterprise Canvas:

The relationships between the asset-types and everything else – the orange section of the checklist – is what we covered in those asset-types posts; the relationships with skill-type and decision-type are essentially the territory covered by SCAN.

For this purpose, the key distinction is between function and capability.

A function is just a place-holder for “where something happens*. Think of it in the same way as for a mathematical function: what_i_get = do_something_with(this_thing,that_value). An alternate term might be ‘interface’: it’s a declaration of a protocol, with some indication of what might happen at that point.

Yet on its own, that function doesn’t do anything: it’s just a declaration of intent, a black-box marked ‘Magic Happens Here’. If we drill down into it, we’ll usually find similar declaration of sub-functions, perhaps chained into defined sub-processes, each with their own sub-sub-functions, and so on – but in effect it’s still just ‘Magic Happens Here’. So a ‘business-function’ is just the same thing at a higher level of abstraction or aggregation: a bigger box labelled ‘Magic Will Happen Here, Honest’.

A capability is the ability to make something happen. A ‘business-unit’ is a cluster of capabilities. Note, though, that on its own, a capability literally has no function: it’s able to do something, but on its own it doesn’t know what that ‘something’ might be. In other words, unrealised potential – a description that certainly applies to all too many real-world business-units…

In itself, a function is kind of like ‘vapour-ware’: we’ve described it, but that doesn’t necessarily mean that we know to do it, or even that we can do it even if we knew how. And on its own, a capability has no function: it needs some practical, useful means and direction to realise all that potential. So it’s only when we put the two together that we get something that could actually be useful: and that coupling of function and capability is what I term a service.

So a ‘business-service’ combines a ‘business-function’ and a ‘business-capability’ (more usually, a business-unit). Note that we can ‘unbundle’ this: that’s what allows us to restructure an organisation and yet still deliver the same business-services. That unbundling and rebundling is what makes outsourcing possible; and it’s the linkage between the functions, the capabilities and the broader more-abstract aims of the enterprise as a whole that determine whether or not that outsourcing is viable in practice. And that’s also why a solid understanding of architecture is so essential to any outsourcing arrangement – including cloud, of course.

There’s one very important complication here. When we’re dealing with machines, and even with IT, there’s a tendency to assume an inherent bundling of function and capability: hence there’s often no perceived difference between function, capability and service, because they’re so tightly bundled together that there’s no way to tell them apart. (For software, the ‘capability’ is actually delivered by the programming-language: from there on up, everything is bundled together.) But this isn’t what happens with real-people: capability and function are definitely separate – or, to put it the other way round, people are highly versatile, whereas machines and IT generally aren’t. This has huge implications for process-redesign, process-automation, disaster-recovery, load-balancing and much, much more in enterprise-architecture and the like.

The same assumed-bundling is echoed in modelling-languages such as BPMN and Archimate. It may be different now, but last time I worked with BPMN, it didn’t even have a realisation-relationship, so there was no way to distinguish between logical-model (row-3) and physical-model (row-4/5). Archimate does have realisation-relationships, but treats different aspects of the same process-implementation as different ‘layers’, which makes it all but impossible to show alternate implementations of the same process – especially for a disaster-recovery context where IT roles have to be taken over by real-people.

Once we disentangle that non-trivial problem, though, Archimate does sort-of distinguish between function and capability, in its distinction between ‘Behaviour’ versus ‘Active Structure’. Unfortunately, it’s the opposite way round to what we might expect: function in this sense here translates to the Archimate ‘Behaviour’ category, whilst capability sort-of translates to ‘Active Structure’, with Archimate’s ‘interface’-entities as the interface to capability, not service or function.

It doesn’t help that in Archimate, service and function (and business-unit, and even business-event) are all bundled together as sort-of-synonyms; but ‘business-actor’ and its virtual and physical equivalents of ‘application-component’ and ‘device’ do at least make some degree of sense. To be somewhat unkind, the structure of Archimate in general is a mess, with many of the entities in plainly the wrong places, in part because of that scrambled pseudo-layering of ‘Business’, ‘Application’ and ‘Technology’: but at least those key distinctions are there.

Anyway, hope that makes more sense, and that it gives you something that you can use in real-world enterprise-architecture practice?

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the first post in this series, we identified four distinct asset-dimensions:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

In the second post we looked at how these same dimensions thread through the entire architecture, as per the ‘service-content checklist’ from Enterprise Canvas, first with an emphasis on Assets and Functions:

In the third post we looked at how those asset-dimensions also apply to Locations and Events.

In this final part of the series, we’ll look at how the asset-dimensions impact on Capabilities, and then how all of those concerns come together within services.

[As before, we'll skip the Decisions and Capabilities:skill columns for now: the asset-dimensions do apply there, but only kind-of in parallel - as implied in the service-content checklist above - rather than directly as in the other columns. A topic for another post, really.]

The asset-dimensions apply to Capabilities in a somewhat more complicated way than for those columns described earlier. What we definitely need to avoid here are those endless arguments about capability versus function versus service versus process and the like, which can get very tangled indeed. So to keep everything as simple as possible, I use a very flat definition here: a capability is the ability to do something.

[If you want to extend it a bit for the business-context, a capability is the ability to do something that would be of value to the enterprise. We'll see why such a bald definition is so useful later when we look at services.]

In practice, though, this capability ends up with three distinct components:

• action: what kind of capability, what the capability can do, to what, and with what
• actor: who or what does the work implied by the capability
• skill-level: in effect, the ability to deal with real-world variation within the context of that work [which we won't explore here]

The simplest part of this is Capabilities:action. The actions of a capability act on assets, or create changes in assets, so it’s essentially the same as for assets.

We have physical-actions, which act on, use or change physical-assets, or the physical-dimension components of composite-assets.

We have virtual-actions, which act on, use or change virtual-assets, or the virtual-dimension components of composite-assets.

We have relational-actions, which act on, reference or change relational-assets, or the relational-asset components of composite-assets.

And we have aspirational-actions, which act on, reference or change aspirational-assets, or the aspirational-asset components of composite-assets.

Sadly, the real world is rarely quite that simple…

True, if everything lines up straight away – for example, we have the right type of physical-action to work on the right type of physical-asset – it actually is that simple: metal-working capability to work on metal, and so on. Remember, though, that these are dimensions, which in the real world usually occur in fairly complicated and sometimes dynamically-changing composites – both for asset-types, and for the capabilities that would act on them. Getting everything to line up properly is often a lot harder than it looks, with plenty of scope of for inefficiency, ineffectiveness and error – especially if we don’t even know about the relational-asset and aspirational-asset aspects of some task that needs to be done. Hence why we need to use the dimensions-set as a checklist – along with other checklists, of course – to make sure that nothing has been missed.

[I won't give a detailed example here: it'd take too long, and would probably only make sense in that specific context anyway. But if you do need a full example, please let me know? - preferably with some background and description from which to build the example.]

Which brings us to Capabilities:actor – that which actually enacts the required action with the required level(s) of skill and suchlike.

In a business sense, the capability is often thought of as an ‘asset’, a kind of active asset. Yet the capability doesn’t just appear from nowhere: something – or someone – will do that work, will enact the capability. That ‘something or someone’ is the actor of the capability – which in principle implies that it’s the actor, rather than the capability itself, that is the respective ‘asset’.

Which leads us once again to the asset-dimensions, because there are crucial distinctions here about the relationship between actor and asset:

• physical-dimension: actor is embedded in physical-asset (e.g. machine)
• virtual-dimension: actor is embedded in virtual-asset (e.g. as software)
• relational-dimension: actor is linked with via relational-asset (e.g. person-to-person relationship with worker)
• aspirational-dimension: actor is linked to via aspirational-asset (e.g. person-to-purpose relationship with worker)

The key point here is that whilst machines or software are real business-assets, real-people should never be described as ‘assets’. Although the person might be the actor for the capability in terms of doing the required work, it’s the relational- and aspirational-links between the organisation and that person that are the actual assets here: and if those links are lost, the effective access to the capabilities of that actor are lost as well.

This distinction becomes critical when we need to switch back-and-forth between machine, IT and manual implementations of the same nominal capability – such as is a common requirement in prototyping and process-development, in load-balancing, and in business-continuity and disaster-recovery. It’s easy enough to see that if we don’t have the right machines or the right software on the right IT-servers, it’s going to be difficult to get a job done that needs that capability. It’s also obvious that if we don’t have the machines or the IT, then we’re going to need a real person to do the work.

But it’s not as simple as swapping out one machine and plugging in another (even though classic Taylorism assumes that that is the case) – because even if we find someone with the right capability, we’re not going to be able to access that capability without providing enough reason for that person to engage in the work. That’s why the relational (person-to-person) and aspirational (person-to-purpose) links are so important: they in effect provide that person with the reason to be there, the reason to engage their capability. That’s why we need to understand that, from the organisation’s perspective, it’s the relationship that is the key asset here – and never the person as such.

[There are some other interactions we also need to take into account here, around the Capabilities:skill component. For example, skills for high-variability (Complex and Chaotic) contexts are in most cases available only in real-people, not machines or IT: at certain levels of complexity, we're going to need a real person, whether we like it not. Yet if the relationship isn't there, the person may be present, but probably not with the required skill-level: which means that if there isn't adequate attention to relational- and aspirational-assets, the capability will be unavailable, and the service or process won't work. Which makes this very important for a service- or process-architecture. Another topic for another post, though.]

Finally, Services are what bring this all together.

To me, services are the core to the architecture: everything in the enterprise is or represents a service, and every service in an enterprise exists to serve in some way the vision of that enterprise.

[Note that the meaning of 'the enterprise' here is much larger than the organisation: see 'What is an enterprise?'. In enterprise-architecture we develop an architecture for an organisation, but about the extended-enterprise in which that organisation plays its part. Don't fall for the trap of thinking that the organisation 'is' the enterprise: they're fundamentally different.]

Which leads us to another deliberately-flat definition: a service is something that serves a need within the respective context.

So how does the service serve that need? This is where we bring together all of the above work on asset-types:

– The organisation as a whole, and each of its services at every level of decomposition from ‘business-services’ right down to individual actions and web-services and the like, serve the enterprise by making appropriate changes (CRUD etc) to assets on behalf of other services.

– Assets may be of many different forms or types (such as indicated by the asset-dimensions described here), and, within a service, may be changed from one form or type to another as required.

– Assets are located at, and may be be moved between, specific locations.

– Assets are acted on in response to events.

– Assets are acted on (CRUD etc) as specified by functions and their protocols, service-level agreements, contracts etc.

– The ability to act on assets is embodied by capabilities.

– A service brings together the structure of the function and the capabilities to enact that function, to act on specific assets at specific locations in response to specific events. [Also in accordance with specific decision-types at specific skill-levels, but that's that other topic again.]

– A process is a kind of pathway – predefined, free-form, or any combination – that links services together in a sequence that delivers required overall changes to assets or to asset-status or ownership or whatever.

And the asset-dimensions weave across all of this, applying to the assets themselves, and to locations, events, functions, capabilities, services and processes, in all of the ways that we’ve explored above.

That’s it, really.

Comments, anyone?

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the first post in this series, we looked at the concept of four distinct asset-dimensions:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

In the second post we looked at how these same dimensions thread through the entire architecture, as per the ‘service-content checklist’ from Enterprise Canvas:

And we looked at how those asset-dimensions apply in practice to for the first two columns of that checklist: Assets, and Functions.

Moving on, we now apply the same logic to locations: every location, of any type, exists within a schema that incorporates any combination of the asset-type dimensions.

[As in shown the service-content checklist above, there's a fifth dimension - time - that applies primarily to locations, though potentially to specific types of events as well. The key point is that although we do treat it as a dimension here, time is not an asset in the same sense as for the other dimensions: we know this because we can't 'own' time, in any sense, and we can't create it, update it or delete it. (We can waste our own time, of course, and sometimes for or with others as well - but that's not the same as deleting time itself! )]

Obviously, we have physical-locations – locations with physical-dimension schemas – with which we would typically associate physical-assets.

We have virtual-locations, with which we would typically associate virtual and/or physical-assets. An IP-address or URL is a classic-example of a virtual-location. A street-address or room-number is actually a composite, a virtual-asset from an imaginary-schema of street-names or floor-numbers or the like, that also references a parallel schema for physical-locations. Much the same for the pairing of a network-address and rack-location for a data-server, for example.

We have relational-locations, within relational-schemas, within which we find relational-assets: the dreaded org-chart is perhaps the archetypal example of this. (Note, by the way, that it’s the relationship between people that is the asset in this context - never the person!)

[I'll admit I'm not quite sure how best to describe, within this taxonomy, the implicit relationship indicated by an 'owner'-responsibility such as process-owner, project-owner, data-owner etc. There's no person-to-person connection there, so it's probably not a relational-asset; in fact it seems to point strongly towards it being an aspirational-asset, because it's clearly person-to-abstract, even where it's a physical object that's 'owned'. The fact that such 'owner'-responsibilities only work well when there's a personal commitment involved again points to a variant on aspirational-asset. But I'd appreciate any comments you might have on this, anyway.]

Then we have aspirational-locations, within aspirational-schemas, within which we find aspirational-assets. This one’s perhaps a bit of a mindstretch too, but the most obvious example is brand-mapping, where brands are mapped in relation to each other, and demographics mapped to brands.

And, of course, we have temporal-locations, within various forms of timescales – some of which may be time-itself, others as proxies for time, such as video-framenumbers and the like. Time isn’t itself an asset, so we can’t place ‘time-assets’ within time: but we can place other assets, and other locations in other schemas, and so on, in relation to time.

As with functions and assets themselves, locations often exist within composite multiple-dimension schemas, which may intersect with other multiple- or variable-dimension schemas: it gets complicated… But again, this taxonomy does help to disentangle all the threads, which can become highly relevant as we move assets or functions or whatever between or even within different location-schemas.

By contrast, events are relatively straightforward.

We have physical-events: mechanical triggers, events in the real-world, and so on.

We have virtual-events: a signal, a numerical-value, a clock-event.

We have relational-events: something that marks the start of a beautiful relationship, we might say, or an unfortunate divorce – in a business sense, in this case, but the metaphor still holds for events that impact or are triggered by changes in relational-assets.

We have aspirational-events: anything that affects a brand, for example.

And we have composite-events, of course. “A man walks into a bar” might be the beginning of a joke, but in business terms it’s a composite of a physical event, probably a virtual-event ‘door open’ signal, possibly a relational-event, and quite likely a select-a-beer-brand aspirational-event too.

We can also see how the various asset-dimension threads weave through sequences of events, such as in what might happen after “a man walks into a bar”:

• there’s the change-of-status physical-event of no more beer in the vending-machine, which is…
• indicated by the ‘dispenser-empty’ virtual-event signal from the vending-machine, which may lead to…
• a physical-event of an angry kick at the machine from the would-be customer; thence to…
• an end-relation event with the bar-keeper, and…
• the aspirational-event of the signal of a potential beginning of an anti-client aspirational-link ‘anti-asset’ between the now-ex-customer and the bar

Disentangling all of those threads is an interesting exercise for a service-designer or solution-architect, one that really is made a lot easier through this type of taxonomy – though probably not very interesting at all to our ex-customer, who still just wants his drink!

Again, stop there for now: in the final part of this series we’ll explore how the same principle applies to capabilities, and thence to services – to me, the core of the architecture.

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the previous post in this series, we looked at the concept of four distinct asset-dimensions: Physical, Virtual, Relational and Aspirational.

The same dimensions carry right the way through the entire architecture. We can see this if we map it as per the ‘service-content checklist’ from Enterprise Canvas, which can also be understood as a much-extended adaptation of a single row from the Zachman taxonomy:

The asset-dimensions are kind of orthogonal to the dimensions represented by the Zachman-style ‘columns’. For this we’ll keep the emphasis on the columns to which these dimensions map directly: Assets, Functions, Locations, ‘action’ and implicit ‘actor’ component of Capabilities, and Events.

[The mapping comes out in a related but somewhat different way in the Decisions/Reasons column and the 'skill-level' component of the Capability column, which I won't go into here.]

On assets themselves, we’ve already covered the fundamentals in that bullet-list from the previous post:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

We need to handle and manage assets in accordance with the respective dimensions: management in terms of storage, security, access, natural-lifecycle, refresh, migration and so on.

It’s all fairly straightforward territory for enterprise-architects; the only real complication is that many entities are or represent composites of dimensions, which means that they need to be handled and managed in accordance with the rules for all of the respective dimensions. A printed book is one simple example:

• book as physical-asset (object): physical storage, ownership-title, inventory-control, access-control, instance-identification, maintenance, repair, physical disposal etc
• book as virtual-asset (information): data-storage, copyright, copy-control, access-control, version-control, validity, review, renewal, metadata, indexing, withdrawal, secure-deletion etc

Just to make it even more fun, the combinations of those composites can change, too, in response to events, the CRUD actions in functions, sometimes in different locations, and even through natural deterioration or depreciation within the lifecycle.

[There's a lot more to explore about the detail of this, but I'll do that in another post: for here I want to concentrate on the way the same principles go across the whole architecture.]

Hence, yes, can be a bit mind-bending at times: but taking a dimensions-approach – using the dimensions as ‘lenses’, if you like – really does help.

In the broadest sense, functions act on assets: they describe the activities that apply CRUD-type changes and the like to assets. Hence, again, we have different dimensions of functions – actually the same dimensions – that act on those respective dimensions of the assets.

We have functions that create, use, change and destroy physical objects, or physical attributes of objects.

We have functions that create, read, update and delete information and other virtual-assets or virtual attributes of entities.

We have functions that help people create relational-links with each other; remember existing relational-links; refresh those links, or provide conditions under which a link can sort-of be transferred to another person, such as in a shop, or an escalation at a call-centre; and although relational-links in effect delete themselves as soon as either party drops it, we have functions which can either assist that to happen, or to dissuade it from happening,

And we have functions that help people create aspirational-links – for example, to connect with a brand. We have many, many functions – most advertising, for example – that help people refresh and renew and reconnect with their aspirations in context of a brand or some other aspirational-link ‘target’: in other words, ‘read’ an aspirational-asset, the aspirational-link itself. We have a suite of functions to get people to ‘update’ the aspirational-asset link – for example, to get someone to change loyalty from a competitor’s brand, or to support ‘upsell’ to a more upmarket brand of our own. And for a few special cases, we have functions that aim intentionally to destroy an aspirational-asset – such as when a brand comes to the end of its life, yet we have no replacement, and we don’t want to upset existing customers of that brand.

And, as before, there will be functions that interweave any or all of these dimensions at the same time. But it’s useful to be able to tease all of the threads apart where necessary – not least because a re-implementation of a function in a different form could lose or gain key aspects of dimensions that we might otherwise not realise were there in the previous form.

Thinking of relational-links and aspirational-links as assets, in exactly the same sense as for physical- and virtual-assets, can sometimes be a bit of a mindstretch: but because it allows us to address all asset-types – and what we do to and with all types of assets – in exactly the same overall way, it really does simplify the architecture-frame a lot. And as we’ll see in a moment, it also brings a new clarity and new simplicity to service-oriented architectures, right up to a whole-enterprise scope.

Stop there for now: in the next post we’ll look at how this applies to locations and events.

My earlier post ‘IT-centrism is killing enterprise-architecture‘ seemed to touch a nerve with quite a few folks:

• tetradian: [post] IT-centrism is killing enterprise-architecture http://bit.ly/p8kfqf (thx @dougnewdick) #entarch
• tonia_ries: The only thing that should be at the center of any business is the customer. @krcraft @tetradian
• krcraft: Agree, if staff also inc. as customers RT @tonia_ries The only thing that should be at the center of any business is the customer @tetradian
• Tim_Flux: @tetradian I think 1 of IT-centrisms problems is, those guilty of it dont recognise it (in themselves), so will not respond to your argument
• tetradian: @Tim_Flux IT-centrism as ‘invisible to self’ – yes, unfortunately, very true (applies to all ‘-centrisms’, of course)
• chrisdpotts: The ‘centricity’ issue in #entarch: it is usually capital-centric, not enterprise-centric (economics; RecrEAtion) // A strategy of stopping all capital-centric #entarch has extremely low chance of success!  Better to demonstrate the alternatives.

But then a follow-on comment by Doug Newdick triggered a really good discussion around business-centrism, capability and process, with Doug, Alec Sharp, Kris Meukens, Chris Bird and others all diving in:

• dougnewdick: Excellent post RT @tetradian: [post] IT-centrism is killing enterprise-architecture http://bit.ly/p8kfqf (thx @dougnewdick) #entarch // @tetradian Hi Tom – that post is excellent, and I think much better for being more moderate in tone, though still passionate
• alecsharp: @dougnewdick @tetradian Tom – I’ve grabbed your post, and will read it with interest. It’s a topic much on my mind these days… // Frustrated by EAs who confuse the scene with “capabilities” (business processs) in trying to be “business oriented” // Most fields are guilty of reinventing (and renaming) the wheel, but EA has really done a disservice in recent years
• dougnewdick: @alecsharp You don’t like the term “business capability”? Or just the way it is used?
• alecsharp: @dougnewdick “Capability” is fine to describe abilities of a person or org. EA use of Biz Cap’y is indistinguishable from process // I have clients in a serious mess due to EA groups tossing BC into the mix when a process arch. was already in place
• dougnewdick: @alecsharp I suppose that if you had a good process arch in place, there’d be less need for business capability map // however I think business capability is a good way to describe something more than process: ability to deliver outcomes
• alecsharp: @dougnewdick I think the “business capability” concept is redundant – indistinguishable from process (which was there first.) // I can’t agree – a business process is nothing but a way to deliver an intended outcome. // MIke Rosen’s BPTrends article (inadvertently) demonstrated that “capabilities” are exactly the same as biz processes
• dougnewdick: @alecsharp You’d be proved right if capability analysis + process analysis gave the same answers, & I haven’t done that exercise // how do you address the qn of whether we have the right people with the right skills to do “x”? Surely not a process qn
• alecsharp: @dougnewdick My observation is they’re very close – the difference is in the rigor of the analyst, not the concept. // But that was my earlier point – “capability” is appropriate if describing abilities/skills of ppl and orgs… // … but all the “capability models” I see don’t address that, they describe processes… // …in my f’work, “skills” (HR) is an “enabler” along with IT, workflow design, motivation, policies/rules, workspace
• krismeukens: @alecsharp @dougnewdick business process is an ordered way to deliver outcome, but there are unordered ways as well // capability captures both, ordered and unordered
• alecsharp: @krismeukens @dougnewdick Disagree – business process spans the range, from transactional to totally unstructured // I think the problem we have in the BP field is that “automated workflow” is equated to “process”
• dougnewdick: @alecsharp Aha! You have explained my unease w many bus cap maps I’ve seen. They’re just process & I was expecting something else
• krismeukens: @alecsharp @dougnewdick people think of process as being linear and deterministic, I don’t like process as the catch-all term
• alecsharp: @dougnewdick Precisely! Orgs obviously need “capabilties” but they are different than “what the org does” which is processes
• krismeukens: @alecsharp @dougnewdick @tetradian the dangers is in what @snowded warns for: our favourite sense-making tool being used for anything
• alecsharp: @krismeukens @dougnewdick I agree that ppl often assume “process” is linear activity, but “capability” is even more open-ended // That’s why I have a kit full of sense-making tools. I’ll stand by what I’ve observed… // …which is that most capabilites I’ve seen EAs define aren’t, and cause much confusion as a result
• krismeukens: @alecsharp @dougnewdick agree, many misuses. I see capability as “what” one is capable of, process as a “how” to realize it
• alecsharp: @krismeukens @dougnewdick Understood. I see process as first being “what” (“Acquire Customer”) and then “how” (steps & decisions)
• dougnewdick: @alecsharp @krismeukens I’d agree with Kris capability = “what”, but also like Alec’s def’n of it as the “skill” of an org
• alecsharp: @krismeukens @dougnewdick I see capability as (surprise!) ability that enables process. That said, it’s hard to differentiate // In my framework, process is the “what” and a workflow (+sys, procedures, …) might be a one “how.” // I’m just sensitive because of hours spent trying to sort it out at clients.
• dougnewdick: @alecsharp @krismeukens Thanks for asking the hard questions Alec – I think I need to go away and think about this some more
• alecsharp: @dougnewdick @krismeukens I enjoyed the conv’n and learned from it. Wish we were all gathered around a whiteboard. Thx, Twitter!
• kdierc: @alecsharp @dougnewdick @krismeukens a twitboard?
• seabird20: @alecsharp @dougnewdick @krismeukens can I make the assumption that capabilities are what the org has available to do processes?
• alecsharp: @seabird20 @dougnewdick @krismeukens That’s how I’d see it. Not “we need the capability to Acquire Customer” – the process itself // There’s a process (what), how it’s done, & supporting enablers: tech, abilities, facilities,
• seabird20: @alecsharp @dougnewdick OK, then resource vs capability?
• alecsharp: @seabird20 @dougnewdick @krismeukens Ack! Resource and capability. What are you, Dick Cheney? My head is exploding…
• dougnewdick: @alecsharp @seabird20 @krismeukens My POV – Capability = the “what” of an org. We execute that using comb of people/process/tech
• krismeukens: @alecsharp @dougnewdick with a fractal organization that could work

Rather embarrassingly, it ended with various people thanking me for the conversation, when I hadn’t even been there:

• dougnewdick: Thanks @alecsharp @tetradian @krismeukens @seabird20 for the great conversations today!
• ebuise: @dougnewdick @alecsharp @tetradian @krismeukens @seabird20 Thanks for a much needed discussion! (apol. for all RT’s, but you trapped me)
• alecsharp: @ebuise @dougnewdick @tetradian @krismeukens @seabird20 Fun discussion. Now to read Tom’s post – he started it all! 
• tetradian: @dougnewdick @alecsharp @krismeukens @seabird20 @ebuise apols that i’ve not been in the capabilities conv – have been offline most of today

For the record, my own opinion is probably closest to Alec’s:

• a capability is the ability to do something, to some identifiable level of skill, as embedded in a machine, an IT-application and/or a real person
• a function is a conceptual ‘place’ or ‘space’ within which things are changed in accordance with specific business-rules etc with an identifiable interface or protocol, in accordance with an identifiable ‘contract’ or service-agreement
• a service is a linking-together of capability and function to provide the ability to deliver a specific outcome
• a process is a path that links together a sequence of service-transactions (where the service may be either predefined or not – Sigurd Rinde‘s ‘Easily Repeatable Processes’ and ‘Barely Repeatable Processes’), to create a desired set of changes in something

More details on this framework reference-sheet, if anyone’s interested.

Great conversation, anyway – many thanks, folks!

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?

Back to enterprise architecture, with a cross-link to another previous discussion on capability.

Reference-models are a key deliverable for many enterprise-architecture processes – for example, the Business Reference Model (BRM) or Performance Reference Model (PRM) in FEAF, or the Foundation Architecture Technical Reference Model (TRM) in TOGAF. But I’ve been thinking for quite a while now about how we actually use those reference-models in practice, because there’s no point in defining a model unless it has some practical business purpose.

Strikes me that what we’re really doing in a reference-model is defining a set of desired capabilities; and that to put that into practice, the closest analogy elsewhere in business is the job-description, because that too is a summary of skills and experience – capabilities and ‘response-abilities’, in other words – that are deemed to be necessary in order to do a specific set of business tasks.

That point here is that a job-description defines what we want – which is rarely identical with what we’re likely to get. In practice, real-world candidates will usually have both less and more than we say we need for the task: they will have some of the skills and experience that we need, and will also have other skills and experience that may be relevant elsewhere in the enterprise. (Unlike most machines, they can also learn new skills if and as required!) We use the ‘required skills’ section of the job-description as a risk-management tool, a filter to constrain the list of candidates to those most likely to match the immediate task-requirement; but we then also use the job-interview as an opportunity-management tool, to identify each candidate’s potential to act not only as a specialist for the task in scope, but also as a generalist providing links for end-to-end processes across the enterprise silos and hierarchies.

The reference-model describes what should happen in an idealised world, within a constrained scope – the ‘to-be’ of a portion of the overall enterprise architecture.

The way we use the reference-model is as a guideline to describe the capabilities that we believe would best fit the identified business-need. We then assess candidates for those capabilities against the reference-model, using both risk-management – “how well does the candidate fit the requirement?” – and opportunity-management – “what opportunities does this candidate provide for enhancements, for innovation, or for greater coherence across the whole?”.

What we don’t try to do is demand that everything should fit exactly to the reference-model definitions. The reference-model describes an imaginary ideal that doesn’t exist in the real world: trying to force the real world to fit an imaginary ideal is a guaranteed recipe for frustration, futility and failure. Instead, just as with job-candidates, we need to accept that there will always be exceptions, things that ‘don’t fit’ – and that there are many opportunities that arise from that ‘don’t fit’, too.

So how does this work in practice? Perhaps the simplest way to describe this is to summarise in terms of the FEAF stack:

• The Business Reference Model (BRM) describes the layering of what and how we expect to deliver to our end-clients – ‘services to citizens’, in a FEAF-style government context, or partners and customers in a commercial context.
  • Risk-management: do we have the business-capabilities to deliver those services?
  • Opportunity-management: what other services could our existing or amended capabilities enable?
• The Performance Reference Model (PRM) describes how we will monitor service-delivery, and identify ‘success’ in the BRM’s terms.
  • Risk-management: do we have the right metrics and correct capabilities to monitor and validate performance.
  • Opportunity-management: what else could those metrics and capabilities imply?
• The Service Reference Model (SRM) is slightly more problematic, because it describes a ‘bundling’ of capability and function into a pre-packaged service.
  • Risk-management: do we have the right capabilities to deliver the BRM’s services and PRM’s metrics, and are they bundled together with appropriate business-functions or other functions to create the right services? In what ways do or could we ‘slice and dice’ different technologies and delivery-techniques to provide the full set of required services? How do we cover the gaps in service-delivery that are not addressed by any of our candidate technologies?
  • Opportunity-management: what other ways could we combine our capabilities and functions, and what else could those alternate services deliver?
• The Data Reference Model (DRM) describes the layering of data, information and (in principle) knowledge needed for each of the capabilities and services.
  • Risk-management: do we have all the data we need, when and where we need it, and the right IT-based, human and other capabilities and services to transform that data to the required information? How do we fill the gaps in knowledge-management, especially those that cannot be covered by any available technology?
  • Opportunity-management: how else could we use and re-use that data, information and knowledge?
• The Technical Reference Model (TRM) at present usually refers only to IT, but could and should cover all forms of technology used within the enterprise.
  • Risk-management: what capabilities, functions and services does the candidate technology provide? How do we fill the gaps that cannot be covered by any available technology?
  • Opportunity-management: What other capabilities does the candidate technology enable? What new services could be created via ‘mashups’ of those capabilities with other already-available technologies in the enterprise?

Each person enables their own unique ‘mashups’ of different capabilities and services, through their own specific ideas, relations, experiences, skills and capabilities; it’s the alignment of these with the needs of the enterprise – the risks and opportunities for the enterprise – that we assess in a job-description and job-interview.

So it’s useful to think of architecture reference-models in the same way: they form the ‘job-description’ for a set of capabilities in some context within the enterprise, whilst the architecture-assessment is the analogue of the ‘job-interview’. In the real world, it’s rare that we would find a job-candidate who has matches every detail of the job-description; in much the same way, it’s rare to find a set of technologies that match all of our expectations – and if we did, it would probably prevent us from seeing other opportunities that those ‘not-quite-right’ technologies could enable.

Architecture provides a means for both risk-management and opportunity-management: reference-models perform part of that function. But we do need to be realistic about it, just as we are with job-descriptions and job-candidates: in the real world, a reference-model can only ever be a ‘recommended guideline’, not an instrument for delusory attempts at ‘control’.

And the ‘why‘ of architecture also comes to the fore here: whenever we vary from the recommendations of the reference-model, we need to be clear as to why we’re doing so, and what risks and opportunities that variance implies. If we don’t have an enterprise-architecture in place – a real ‘architecture of the enterprise’ as a whole, not solely an incomplete architecture of the enterprise IT – we’d be unlikely to have sufficient understanding of that ‘why’ and its implications across the enterprise… which could lead to dangerous assumptions, unnecessary constraints, many unnecessary risks, and many, many lost opportunities. Architecture matters.

Reference-models are the ‘job-descriptions’ for the capabilities of the enterprise as a whole. What difference does that make for your architecture practice, and for you as an architect, if you rethink your reference-models in this way?

This is in effect a continuation of the previous post on Zachman and capability, following on from some further comments on Microsoft architect Nick Malik’s original post on business-capability.

Nick kindly described my comments as ‘extremely interesting’, and perhaps even more kindly remarked that:

Your model is the first honest attempt I’ve seen to remove “Actors” from the ZF [Zachman Framework] and replace that column with Capabilities under the notion of “Who.”

He was concerned, though, that changing Zachman’s ‘Who’ to ‘Capability’ means that we then lock out what Zachman also parks under ‘who’, namely organisational structures:

I’d be concerned about your approach, however, because you leave no room for the combination of organizational structures with other architectural elements, because you replaced the organizational structures with capabilities.

But from my view he doesn’t need to worry, because organisational structures are in the wrong place anyway in Zachman: the correct place is under ‘Location’ – Zachman’s ‘Where’. Or that’s part of it, at least. The point is that organisational structures are kludged into ‘Who’ in Zachman because his model is missing an entire dimension (or more than one, in fact). We need to resolve this absence before we can make sense of org-structures in a Zachman-like taxonomy. The main ‘extra dimension’ that I use relates to asset-categories:

• physical (‘things’)
• virtual (e.g. information)
• relational (e.g. links between people and/or groups of people)
• aspirational (e.g. brand, morale, purpose)
• abstract (‘none of the above’, such as finance)

In essence, an organisational structure is a map of relationships between relational locations (i.e. ‘where : relational’ links), in much the sense sense that a physical network is represented by a map of relationships between physical locations. That’s the primitive, but we more often see it as a member of a broader composite: for example, a business-unit is typically a composite of ‘where : relational’ and ‘capability + function’ (i.e. ‘service’). Any change to any of the underlying primitives will change the composite, and hence – in that example – the role, purpose and placement of the business-unit.

Nick expressed some concerns about the relationships between primitives and composites, especially in relation to capabilities:

You have correctly stated that capabilities need to be combined with other things to be interesting, and that “molecules can be based on simpler molecules, in the same way that DNA is based on simple molecules.”

Just as you can take a molecule and add an atom to produce another molecule, I believe that you can take a capability and add a relationship to an architectural primitive and get another interesting composite.

But, can we say that capabilities are, or are not, constructed from existing primitives?  That’s an interesting problem, and one that I don’t have an easy answer for.  Just as the effort to move up or down a row in the ZF is more of a transformation than a construct, is it possible that the capability is a construction that sits on a fictional row, above row zero, that represents not one owner’s viewpoint, but ANY owner’s viewpoint?  That, in fact, the capability is a transformation above a composition of people and process?

To me this stems from a slight misunderstanding about the roles of primitives versus composites in architecture: we need to resolve back to primitives in order to understand our options for re-use and redesign, yet almost everything in the real world will be some kind of composite.

For example, on its own a ‘capability’ is almost meaningless: until it’s combined with a function (Zachman ‘How’) into a service, it literally has no function. But by modelling capabilities separately, as distinct primitives, we enable alternate combinations of capability and function to give different effective services (and hence support different processes). This also gives us a better understanding of what’s needed when we substitute one capability for another whilst maintaining the same nominal function, such as in process-reengineering or disaster-recovery.

To me, capability is a nominal primitive, though it has some characteristics of a kind of ‘compound-primitive’. On one side is the asset-type(s) to which it applies: physical, virtual, relational, aspirational, abstract, or any combination of these. (For example, a sales-capability applies primarily to relational assets, but is usually linked to other asset-categories as well – information, brand, product and so on.) On the other side is what we might call the ‘skill-level’: rule-based, analytic, heuristic and principle-based. Crucially, machines are only well-suited to the first skill-level, and IT to the first and second; IT can be used for decision-support (but not decision-making) in the third; and is all but unusable in the fourth. Capability-modelling allows us to determine the extent to which IT should and should not be used in a given context, and what human skills will be needed to fill in the gaps.

I would agree that any move up and down the Zachman rows is a transformation rather than a construct. As described in the framework summary – http://tetradianbooks.com/2008/12/silos-frame-ref/ – each row upward is another level of abstraction, and each row downward adds another component to the modelling-requirements. The vertical dimension is also in effect a spectrum of time, from nominally infinite (row-0) to unchangeable past (row-6). So the same nominal ‘capability’ can be viewed in multiple ways, sometimes as “one owner’s viewpoint”, sometimes “ANY owner’s viewpoint”, depending on the chosen level of abstraction – much as the multiple perspectives in data-modelling, from business to logical to physical and so on.

I do take Nick’s point that we could view a (business) capability as “a transformation above a composition of people and process”. Yet if we do so, we’re actually using the same word – capability – to mean two very different things: a primitive of “ability to act on something” (hence ‘capability‘), contrasted with the complex composite of people, business structure, business-relation, function, process, service and capability that we would describe as “the capabilities and role of a business unit”. We can get away with such blurrings in everyday business conversations, perhaps, but we can’t do so in a taxonomy for enterprise-architecture: we need the precision of proper usage of terms, or we’ll end up in an unworkable tangle.

Nick also dropped in a final comment about dimensionality of a taxonomy:

IMHO: The only real limitation of the ZF is the arbitrary notion that any three dimensional representation has to be in the shape of a cube.

I don’t agree that we have to presume a cube (or equivalent ‘pure’ n-dimensional structure) for an architecture taxonomy. For example, the modified Zachman I use is more like a wedge: that ‘asset-categories’ dimension (physical, virtual, relational and so on) is crucially important at the real-world levels (rows 5-6), but we deliberately focus and de-focus on those categories in reviewing the logical-to-physical trade-offs (rows 3-4), whilst the categories are often almost irrelevant in the true abstract layers (rows 0-2).

Some of these points might sound pernickety – as indeed they probably are for basic-level IT-architecture in information-centric industries, for which Zachman’s simple two-dimensional overview is probably adequate enough. But once we extend the architecture to other industries or contexts that deal more with other types of assets – such as manufacturing, logistics, sales, defence – we must cover the full range, or we end up with an artificially restricted scope that is riddled with gaps labelled ‘Magic Happens Here’, because we have no means to describe what needs to occur there.

This also applies to any business-oriented view of IT-architecture, such as SOA, security-architecture or Enterprise 2.0, or enterprise-scale uptake of cloud-computing capabilities. A true enterprise architecture is the architecture of the enterprise as a whole – not solely the architecture of the enterprise IT.

An interesting (well, interesting to me, anyway ) enterprise-architecture discussion on the position of ‘capability’ in the Zachman framework.

This was triggered by a post by Microsoft architect Nick Malik: “Why Business Capabilities Are Not In The Zachman Framework”. (My thanks to Bart Leeten for the initial link.) Nick uses the common analogy with the Periodic Table of the Elements to point out – correctly – that there’s no primitive for ‘capability’ in Zachman (though he doesn’t actually explain why…). The result, as Malik warns, is that some architects think that there’s no need to model capabilities:

But here’s the rub: business capabilities do not appear in the Zachman framework.  This causes confusion among new architects first learning the Zachman framework.  The confusion goes like this: If the ZF is comprehensive, and defines everything that an architect needs, then why does an Enterprise Architect need a capability?  Are capabilities non-architectural?  Should the notion of capability mapping be disregarded by Enterprise Architects because capabilities are not part of the comprehensive Zachman framework?  Should the development of a taxonomy of capabilities be considered a pointless exercise because it isn’t architectural?

As he explains, capabilities are an essential part of architecture: “capability hierarchies are necessary, nay, essential to modern Enterprise Architecture”. From here, though, he draws the conclusion that because ‘capability’ isn’t a primitive in Zachman, it must therefore be a composite, and that we should necessarily model it as a composite: “are business capabilities part of enterprise architecture, even though they cannot be seen on the Zachman framework?  Yes.  For the same reason that molecules are part of chemistry.”

But one possibility he doesn’t seem to consider is that Zachman is just plain wrong. It’s not a viable taxonomy: the rows – ‘Owner’, ‘Designer’, ‘Builder’ and so on – make practical sense, but for the columns he starts with a set of interrogatives – ‘What’, ‘How’, ‘Where’, ‘When’, ‘Who’, ‘Why’ – and then seemingly hunts around at random finding real-world things that vaguely align with those interrogatives. The result is a kludge that sort-of works for a basic and now rather out-dated approach to IT-architecture, but falls apart as soon as we try to use it as a proper structural taxonomy – a ‘Periodic Table of Elements’ for any true enterprise-scope architecture.

Others have pointed out some of these problems: Jean-Paul Vooght, for example, commented on Twitter that Zachman “misses intra-row cross-tables”, whilst CapGemini’s Mike Turner was a bit more sardonic:

Zachman vs business capability is a bit like “why doesn’t my 8-track have I-pod docking station?”

But the problem here isn’t that Zachman is outdated, like an 8-track tape-player: it’s that it’s structurally flawed. To make it work, we need to replace the crude interrogatives with proper taxonomic categories. As I’ve described elsewhere, my recommendation for the respective categories is as follows:

• Asset (‘what’)
• Function (‘how’)
• Location (‘where’)
• Capability (‘who’)
• Event (‘when’)
• Decision/Reason (‘why’)

Each of these ‘column’-categories will crosslink to a set of Zachman-like rows and at least one other distinct dimension of action-categories – physical (‘things’ etc), virtual (information etc), relational (people etc), aspirational (brand, morale etc) and abstract (finance etc). For capabilities, we need to add crosslinks to another set of categories, for skill-levels: rule-based, analytic, heuristic, and principle-based. Linking capabilities to functions defines services; a business-process is a choreographed pathway through sequences of services; and so on.

A ‘business capability’ can be either the same as ‘capability’ in this sense, or merged with organisational structure (in essence, a map of relational locations) as the capability of a business-unit, and so on: the term is often too blurry to be usable reliably within an architecture taxonomy. But by layering different composites of the underlying primitives, we can build up different views of the enterprise that enable us to describe whatever structures may be needed.

So yes, ‘capability’ is not part of Zachman; but Zachman is not usable anyway – not for enterprise architecture, at any rate. We need a better, more robust taxonomy than Zachman to describe the context and scope of each aspect of an enterprise and its architecture.