8 years, 9 days ago

On function, capability and service

Link: http://weblog.tetradian.com/2011/11/13/on-function-capability-service/?utm_source=rss&utm_medium=rss&utm_campaign=on-function-capability-service

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:

service-content checklist

The relationships between the asset-types and everything else – the orange section of the checklist – is what we covered in those assettypes 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?