On function, capability and 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 ResourceCapability – Disaster Management:Alert / Notification Management
Capability:Actor – Disaster Recovery Lead
Function – Disaster Recovery:Disaster Recovery Triage
Service – Alert / Notify Disaster Recovery TeamPerhaps 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?
Tom,
What would help me in your attempt to clarify here would be some worked examples over your (implicit) metamodel.
I equate service, capability, and function because the community talks that way. Process is a different animal; I think that the strong verb-noun naming standard makes a true process inventory very different from a function/capability/service inventory. But in clarifying function/capability/service, I think you are correct that it needs to reflect some kind of type/instance relationship (e.g. your “realizes” relationship) or else it’s an exercise in arbitrarily “fixing the levels” in a fractal structure. The former is interesting, the latter is where pedantry comes in and I get uninterested.
In my architecture approach, I tend to focus on “trainable” distinctions. That’s why I like process vs. function, as it’s a variation on glass box vs. black box thinking that permeates software engineering. Same with distinguishing data from process, as that is founded on the core CSCI distinction between data structures and algorithms.
But more nuanced distinctions become problematic. I always ask, “what are the chances that a significant set of the practicing community will embrace this in a consistent way.” That’s why I don’t have a lot of patience when my friends in the BPM community start arguing over whether activities contain procedures or vice versa. Those kinds of fractal arguments are only relevant within a very bounded context and we’ll never get industry consensus, IMHO.
I don’t think that is what you are trying to do here. But how about some pictures and worked examples?
Charlie
Hi Charlie – thanks for the challenge. 🙂
Quick answer for now is that for software the distinctions between ‘function’, ‘capability’ and ‘service’ are often all but moot: as described in the post above, function and capability get bundled together, and typically presented as a service. The only extras that are needed are part of the service-definition proper, but usually outside of software – such as contracts, service-level agreements and so on – hence, again, those distinctions between the three become somewhat moot.
As you say, there is an obvious difference between those three and ‘process’ – in effect, a process is a sequence of interactions with services (or functions, if you like) – so that’s a ‘trainable’ distinction that has direct application for software-development and IT-based automation. Like you, I have no interest in any “exercise in arbitrarily ‘fixing the levels’ in a fractal structure’, other than that the cavalier way in which the terms are used to distinguish between levels makes discussion of abstraction and the like unnecessarily difficult, and problematic in practice, too.
Where the distinctions between function, capability and service do is anything which involves real-people. Hence, for example, manual-process segments in an overall end-to-end process; or disaster-recovery, where a real-person has to take over from out-of-action IT; or load-balancing, where we balance the load across multiple implementations, using any mix of machine, IT or manual-process. (I originally got into this when working on a process-architecture for parcel-sorting in logistics, where we had exactly that type of problem.)
As I say, this kind of nuance probably isn’t all that necessary in a pure IT-only context, though it’s certainly useful in some types of process-redesign. What this is really about is to give the ‘practicing community’ something to fall back on, and make sense of what’s going on, when the IT doesn’t work, or doesn’t apply. Which is a lot more of the process-space than most IT-folks seem to recognise, and will become more and more important as enterprise-architecture expands further outward beyond the ‘classic’ IT-specific constraints of current TOGAF and the like.
“But how about some pictures and worked examples?” – uh… yeah… sure… You heard that phrase “a picture is worth a thousand words”? – well, a picture often takes about a thousand-words’ worth of time to draw… may take me a little time to get there… 😐 🙂
But yeah, good challenge: thanks!
Tom,
Thank you for the response. Need to be clear that while my background may be technical, my interest in the application of these semantics is not limited to software engineering – my interest is in full-on EA and BPM applied in enterprise domains. I’m just looking for some sort of grounding.
There’s a very active thread on this over on the BPM LinkedIn group; would love to see you and Roger Burlton take this up. http://www.linkedin.com/groupItem?view=&srchtype=discussedNews&gid=1175137&item=61632470&type=member&trk=eml-anet_dig-b_pd-ttl-cn&ut=3HT7_407O00501
Charlie
Thanks Tom for taking the time to post this and I think we are straight… On a side note Archimate never passed the blink test for me and everytime I go back and take a look I quickly move along. Not sure why, but it just doesn’t do it for me.
Perhaps I’ll take a stab at overlaying your metamodel with some work I am completing now as mentioned before, but only one row 🙂 Row 2 might be doable
Hi Tom, and lots of thanks for excellent work!
I wonder about the relationship between a function and a capability.. may the same capability occur in several functions?
Another thing that confuses me – Services are often defined as with a need of a contract… but when I put a capability in a function, is it ok to define it as a service even though the service might be missing an explicit contract..?
Hi Andreas
“may the same capability occur in several functions?” – yes, that’s the whole point. And likewise different capabilities may be used with the same function (in effect, swapped in and out of what is nominally the same service) – as we would often need to do in disaster-recovery or some types of load-balancing.
If you’re coming from an IT-background, one way to think of this is that the capability is actually the software-development system: we use a function-template – including a contract – to define a software-service. The separation between capability and function is sometimes hard to see in software-applications (or physical machines, for that matter), but is extremely important when we need to swap capabilities around for different services, or get real people to take over service-delivery.
About contracts, the way I see it is as follows:
– capability isn’t involved in the contract as such, other than in terms of delivery of the needs (requirements) of the contract
– function defines the parameters for the contract
– service defines the values applied to the function-parameters in the contract (hence ‘Service-Level Agreement’)
In effect, the function defines the contract-template for services that will become implemented via that function. In quite a few cases, even at the web-service level, the exact parameter-values of the service will only be negotiated and verified at run-time. (Again, think in terms of software-engineering: a function presents an interface, which in some development languages may allow dynamic-binding: it’s much the same principle at larger levels too.)
Hope this make sense? – if not, yell at me? 🙂
Thanks Tom!
This makes sense to me, even though my background is purely “non-IT”.. I’ve been working as an operational developer for seven years, and the latest three years been “into” EA and model “aided” business development. I am now ending up with these question because I am trying to verify and hopefully improve our meta model, and end up with a basic set of definitions independent of abstratction level (today it is a bit messy). Since my last post I’ve found some more questions, of course.. I dont expect you to have time for these questions, but I’ll pop them and hope for response from anyone. At least someone might help me express them in a better way or point me in a good direction =)…but I will first try to brief you about our current situation.
We are currently working with Business Services, Business Functions and “lower level” Capabilities. Business Services are realized by sub processes, and supported by “lower level” capabilities which relates to corresponding processes and activities. We also work with domains and sub domains (often derived through information and city planning) and Functional blocks. The former I have found to be what many other standards/framworks call Business Functions, and other organisations might identfy/derive them in other ways.
Since recently we are also implementing higher level capabilities derived from the business model as means to tie strategy down to our activites. So… we got Business Functions, Business Capabilities and Business Services and lower level capabilities (Process Capabilities).
On Function/Business function:
1. On the “business” side, how would an business function hierarchy look, and how would it be derived? (ofcourse I don’t want to build hierarchys if it’s not needed, but your thoughts on this would be helpful for my understanding). What would be the lowest function, i.e. on an “activity level”?
2. Since a capability can support mulitple functions (answer above) – does this imply the same for Business Capability and Business function as well? I was originally thinking about this relationsship as (M:1) and a “belongs to” relationship, but I was a bit off track here?
On Business Capabilities:
1. We have defined Business Services at our level 3, and these are realised by Sub-processes (at same level). We have a (M:1) relationship – one or several Sub Process may realize a Business Service. The sub-process is broken down to process components which are an abstraction of the actual activity flows. We have not yet defined services for lower levels, but this Sub-process breakdown is the foundation for our lower level capabilities (which in fact could be called business services as well I suppose)
…given this – how would you define the relationsship between a lower level capability and an activity? We used to define it as (1:1), but this seems a bit off if one would like to refer to capabilities as more stable than the process architecture, doesn’t it? Shouldn’t it rather be (1:M) – One or many activities realizes a capability.
2. I am also having trouble to define the relationship between a Business Capability and a “lower level” Process Capability (wich supports our Business Services). If there should be any relation, should it be a strict (1:M)-relation based on the MECE-principle – or should (M:M) be used (allowing for a lower level capability to support several higher capabilities in capability maps)?
hmm… I got a bit carried away.. I apologize for this long and somewhat blurry and detailed post. It might have been more useful for you to see the meta model right away.. But ofcourse I won’t hesitate to share it with you. Your feedback would obviously be worth a lot =).
Hi Andreas
I’ll answer all of this from a ‘service-oriented enterprise-architecture’ perspective – i.e. ‘everything is or represents a service’, where ‘service = function + capability’.
Function/Business Function: Your 1:
a) From an architecture perspective, there’s no intrinsic difference between a ‘business function’ and any other type of function: the ‘business’ label is literally just a label, just a way of viewing the possible role of the function. The only architecturally-meaningful notions of ‘higher’ or ‘lower’ are level-of-abstraction (e.g. Zachman ‘rows’) and composition/aggregation (e.g. ‘parent’-to-‘child’ relationships); be careful not to confuse arbitrary notions of ‘higher’ or ‘lower’ in role-labels (e.g. ‘business’ versus ‘process’) with level-of-abstraction or implementation-method or anything else.
b) We tend to create a sort-of hierarchy of functions, but it’s a hierarchy of aggregation (‘child’-functions and -services). It’s not a true tree-type hierarchy in the classic business sense because some ‘child’-functions may be used in multiple higher-aggregation – it’s a M:M relationship, not a M:1 relationship.
c) The lowest-level function could be right down at the molecular level – for example, ‘molecular tweezers’ in nanotechnology applications. Remember there’s no intrinsic between ‘business function’ or any other function: ‘business’ is just a label that we may or may not choose to place on a particular view of a specific function or aggregated-function.
Function/Business Function: Your 2:
a) The same applies as above: ‘business’ here is just a label placed arbitrarily on a particular type or clustering or aggregation of capabilities. Do not use ‘Function’ or ‘Capability’ or ‘Service’ or ‘Process’ to mean different layers of aggregation and/or abstraction of (usually) services: if you do so, you are guaranteed to cause confusion further down the track. I fear this is what you’re doing here? General business-folk can usually get away with being careless about this, but architects can’t: we need stable precision here.
b) A capability is literally the ability to do something; a function is a placeholder for where something can be done in accordance with an identifiable protocol and identifiable rules, principles or guidelines. On its own, a capability literally has no function: it’s just the ability to do something, not the actual doing of it. (A car engine has the capability to drive the car, but the car-frame and transmission and so on provide the functionality for the car to actually move.) Conversely, a function has no intrinsic capability. (In general, the car won’t move without the engine.) We bring them together as a service. (The services provided by a moving car.) Note that we can substitute alternate capability within the same function, to produce a somewhat different service, usually with different ‘non-functional’ attributes. (If the engine won’t work, we could tether a horse to the front: the overall service would still be deliverable, with [almost] the same function, but probably a lot slower!)
c) We typically assign a capability to a function, but again there’s an M:M relationship here – as you’ve suggested above. A capability may be used in multiple functions, and a function may (and often will) call on multiple capabilities. There’s another slight complexity in that a single function-interface may actually serve as a front-end for multiple services with different capabilities. The obvious example is escalation at a customer-service call-centre, where a problem will typically first be offered to a capability with basic rule-based skill-levels (e.g. web-based FAQ), then escalated to a different higher-skill-level capability (a real-person with some technical background or experience), and perhaps further onward to a higher-level capability again (subject-matter expert with deep experience).
Business Capabilities: Your 1:
a) I’m a bit worried because you again seem to be using ‘function’, ‘capability’, ‘service’ and ‘process’ as semi-interchangeable terms, and/or as labels for different supposed ‘layers’. Don’t do that – it’ll cause you endless trouble (as seems to be evidenced in some of what you’ve written above). Instead, use definitions that remain the same regardless of what ‘level’ you’re working on: either my definitions as in the post, or any other definitions you prefer – the crucial is that the definitions must be consistent throughout the whole of the architecture.
b) To clarify the specific point you asked: from a service-oriented perspective, an activity is the application of a capability within a function (and hence within a service). The capability is the ability to do something; the activity is the doing of that something. In practice, when most business-people use ‘activity’ in a model or whatever, it seems that what they actually mean (in terms of the definitions I’ve used above) is, in effect, a service, but without any usable definition and/or description of the service-interface – which isn’t helpful from an architecture-perspective…
Business Capabilities: Your 2:
a) (Thanks for the pointer to the ‘MECE principle’ – ‘mutually exclusive, collectively exhaustive’. Didn’t know the term before; I do now! 🙂 )
b) Once again, be very careful not to use ‘capability’, ‘process’ and so on as labels for layering: it’s guaranteed to confuse. At a more-abstract level, what we might describe as a ‘business-capability’ may be realised via specific more-concrete services, but those services in turn rely on the actual implementation-layer capabilities, without which the service that underpins the ‘business-capability’ cannot be realised. Hence implementation-layer capabilities aggregate into ‘higher-order’ (often more-abstract) capabilities, and implementation-layer services aggregate into ‘higher-order’/more-abstract services; but if we’re to be consistent about our terminology (and we should be!), capabilities do not actually aggregate into services or processes, nor services into capabilities, or anything else. I know it probably sounds very pedantic, but believe me, that level of precision is the only way that works in an implementable architecture.
c) Re M:M, yes, as per my 1(b) above, it’s a ‘sort-of M:M’. They’ll tend to cluster as a sort of hierarchy, so that it’ll look like an M:1, but in quite a lot of cases we’ll find implementation-layer capabilities being used within multiple distinct implementation-layer services, which in turn realise multiple distinct ‘business services’.
Hope this helps?
(Oh, and on your “Your feedback would obviously be worth a lot =) ” – depends what you mean by ‘worth’, but hey, a small consultancy-fee would be very welcome, of course! 🙂 On a slightly more serious note, I do work as an independent consultant in whole-enterprise architectures, so if your company wants my professional assistance in this, please let me know? – many thanks!)
I know this is an old thread, but here is my 2c…
A function defines the interactions and parameters, a business service requires capabilities in order to realise a function. (service = function + capability).
A service is made up of one or more processes, which consist of one or more tasks which are executed by actors (actors can be human or tech). Actors provide capabilities.
Thanks, Bret.
Agreed re your definition of ‘function’ (because in essence it’s the same as the one I use for Enterprise Canvas). I’d be wary of the ‘business’ prefix, though – the definitions apply to every type of service, not solely those at a ‘business’ level.
Re “A service is made up of one or more processes”, I’d be a lot more wary about that. From the definitions I use, it’s actually the other way round – a process is a sequence of calls to services for the respective interactions. Because of fractality, though, a service may encapsulate, within itself, processes that call other services. This then gives the impression that “a service is made up… of processes”, though those processes at the the next level down in the recursion.
Re “are executed by actors”, only a small wariness on that one: most people / frameworks / models seem to reserve the term ‘actor’ exclusively for anything human. For the generic you’re indicating (“actors can be human or tech”), I’d recommend ‘agent’ rather than ‘actor’.
Re “Actors provide capabilities” – well, yes, they do, but watch out for the recursion again: an agent provides capabilities and function-interfaces for services that are aggregated into capabilities that are used to enact within the service that is called by the processes at the next level up.
If we’re not careful about definitions and the like, keeping track of those recursion/fractality levels is hard – and it leads us into messy traps where people use ‘function’ versus ‘service’ versus ‘process’ versus ‘capability’ either for the same things but at different levels of recursion, or randomly mix-and-match with prefixes (‘business’ versus ‘application’ etc) as the only differentiators. Yet with the right definitions, it immediately becomes a whole lot easier, and the fractality becomes a whole simpler to disentangle – but the catch is that we do have to be consistent in our use of those definitions. That’s the choice, really.
FWIW, a lot of care and thought went into those definitions for Enterprise Canvas: there’s nothing arbitrary about them at all…