Service, function and capability (again)
How can we distinguish between service, capability and function in enterprise-architecture models?
This is one of those perennial questions that keeps returning time and time again, and it’s one of the key confusions that Enterprise Canvas aims to resolve. But in a series of great discussions earlier this week with enterprise-architects Nenad Antic, Gerold Kathan and Vitor Mendes, I realised I still hadn’t explained it well enough: there’s one particular clarification that I need to add to the overall description.
Quick background: business-folk tend to use the terms ‘business service’, ‘business process’, ‘business function’ and ‘business capability’ as near-synonyms, which leads to all manner of confusion when we try to build common understanding across an organisation or enterprise. To get round this unwelcome chaos, Enterprise Canvas builds on the idea of ‘everything is a service’, which leads to the following assertions:
- everything in the enterprise is or represents or signifies a service
- a process links services together in some way to achieve some kind of outcome
- a function is an external view of a service – in effect, a description of its interfaces (‘black-box’ view), often together with a summary or overview of what it does and how it does it (‘white-box’ view)
- a capability is the ability to do something
- a function needs to be linked to a capability in order to do anything
- on its own, a capability literally has no function
- in a service-architecture, we link together a function and a capability (and various other service-content items) in order to create a service
Another way to summarise this difference is to describe it in terms of the structure of service-level agreements:
- the function describes the parameters of the service-level agreement – which should remain essentially the same for all implementations of the service
- the capability determines the parameter-values to be assigned to those parameters in the service-level agreement – which are likely to be different for each implementation of the service
One complication here is that for IT and machines, ‘function’ and ‘capability’ often have a one-to-one correspondence, and are so deeply intertwined that many people would fail to recognise any difference between them. But the picture is very different for real people: there, there’s very definitely a many-to-many correspondence between capability and function.
[By the way, one of the fundamental reasons for the inefficiency of Taylorism as a work-design model is that it treats people as machines, assigning just one capability to each human business-function, as a ‘role’ or ‘job-description’ – in effect locking out all other capabilities that that person might possess.]
So to build an architecture that makes use of people’s skills and capabilities, and to enable load-balancing and business-continuity and suchlike that switch between automated and ‘manual’ implementations of a process or service, we need to treat function and capability as distinct facets of service-content.
For much of our routine modelling, we’ll only model the service as service, perhaps with summaries about its various flows and exchanges with other services, but without much interest in any of its internals:
But once we do want to know more than just a basic ‘white-box’ summary about what the service is and does, and how it works, we’ll need a more detailed description of the service-content – including the functions and capabilities of the respective services. In effect, the function is a more-detailed surface-layer view of the service, whilst the capabilities are hidden away somewhere within its internals:
Yet notice the catch here: from the outside, and to the unaware eye, the function looks exactly the same as the service. Which leads all too easily to the mistake of thinking that they are the same thing, that the function is the service – which it’s not. On its own, a function is just an empty shell, a kind of declaration of desired intent; it’s only when it’s combined into a complete service, with all the other service-content components, that the function can then actually do something useful towards that desired intent. Function is not the same as service, which in turn is not the same as capability: and it’s best all round if we’re clear about those distinctions.
Yes, I know all of this might sound like Yet Another Piece Of Tetradian-Tom’s Prepackaged Pedantry, but seriously, this kind of precision really does help when we’re trying to tease out the tangles of miscommunication around services and the like in our various architectures. If you keep consistently to the definitions in Enterprise Canvas, it really will make that part of your enterprise-architecture work a heck of a lot easier – I promise you that. Fair enough?
Spot on Tom.
You can also visualise a Service as being a realisation of a Function, i.e. the people/resource/capability, process, application data and technology to make it happen.
There is also a lot of value to be gained at working at the “atomic business function” level, i.e. the smallest level of useful work.
For an atomic business function, in addition to recording the name, objective, description and measures/emergent properties, we can specify a) the structural business rules/requirements (i.e. semantic/logical data model and or business ontology) and b) the information flows between them.
Thanks, Andrew.
“You can also visualise a Service as being a realisation of a Function” – brilliant! Of course! (It’s so obvious that I’d, uh, completely missed it… duh… 🙁 but at least I do know it now, thanks to you. 🙂 ) It’s exactly correct, and makes the relationship a heck of a lot of easier to understand. Need to bring that pairing out from here in the depths of the comments and up centre-stage where it belongs.
“‘Atomic business function’… the smallest level of useful work” – agreed, though the boundary indicated by the qualifier ‘business’ is always going to be an arbitrary choice, because every level of work is ‘useful’: each level builds upon the levels below, until it reaches a point where we decide that it’s both ‘visible’ and ‘useful’.
“For an atomic business function…” – that’s pretty much what I do with the simple-notation for Enterprise Canvas: the raw shell of the Service (which in essence is the function’s interface-protocols and service-level parameters), plus the Exchanges between this and other Services (which may be flows/interactions not only of information, but of any Asset-types, including physical, relational, aspirational and composites).
Also given your own pairing of function and service above, it’s possibly safer/less-confusing to describe it not as a business-function but as a prototype for a realisable business-service, because it’s a partial/intentionally-incomplete description of the service-content. To paraphrase one of my earlier aphorisms, “a Service-prototype is realisable to the extent that it is architecturally complete [in the description of its service-content]; a Service-prototype is re-usable to the extent that it is architecturally incomplete [in that we can still change some of the components of the service-content]”.
Hi Tom,
My first post! Over the last few weeks, I’ve immersed myself in your head – thanks! Have read 4 of yours books and many, many of your blog posts. Still absorbing everything….
Anyway, one question here from the comments – “You can also visualise a Service as being a realisation of a Function”
Is it a realisation or a composition, in the context of this post (http://weblog.tetradian.com/2011/09/10/simplifying-ecanvas/)?
Let’s take the example below. Assume we are on Row 3 (Logical layer, implementation independent)
Service – Transporting a vehicle over water
Function – Transporting a vehicle over water (CrossingType, …). CrossingType may be Bridge or Ferry
Capabilities – Bridge, Ferry
The above is all Logical row-3 layer, right? Therefore, it’s not a realisation? Is it some type of composition?
If so, then we can stay on row-3, and recursively look into Bridge or Ferry as a service?
Service – Ferry
Function – Ferry (EngineType, SeatType, ….)
Capabilities – Engine, Seats
If we then recursively look into row 4 (physical) for Engine
Service – Caterpillar 300 horsepower
Function – Caterpillar 300 horsepower (UniqueEngineID,..)
Capability – Rotate Engine,…
Would you agree with Service/Function/Capability for row-4 engine?
—————————
Generalizing
Let’s say we start on row-3 / Logical.
Service – ABC
Function – ABC (…) where ‘…’ Asset Type (Physical, Virtual, Relationship, Aspiration).
Capability – Manual/Human, IT-based, Machine-based
Would you agree?
———————
Also, one other quick question. In the IT world, would you agree with the following?
Row-3/Logical:
Service – CRM
Function – CRM(AddContact,…)
Capability – Contact Management, Deal Management etc..
Row-4/Logical:
Service – SalesForce
Function – SalesForce (AddContact,…)
Capability – Add Contacts
Thank you!
Back to my first question above.
Wouldn’t a Service be composed (not realized) of the ‘columns’ in the extended zachman?
Eric: “Back to my first question above: Wouldn’t a Service be composed (not realized) of the ‘columns’ in the extended zachman?”
In essence, yes (once we allow for that other dimension of asset-types and/or decision/reason-types).
(Fractalities can make it kinda tricky, though: we do need to be careful to keep track of just how far down the rabbit-hole we’ve gotten at every single step of modelling this kind of stuff. 🙂 )
One useful trick is to remember that the more ‘complete’ a service-description is (in terms of having a full set of ‘columns’), the more usable it is; the less ‘complete’ the set is, the more re-usable the service-description is. For example, if we don’t hard-wire the Where, we can configure the service to be used at different Locations; if we don’t hardwire the Capabilities, we can set up fungible (interchangeable) implementations inside the black-box; and so on.
No, it doesn’t quite work that way. I’ll admit I kinda confused it in the ‘Simplified Enterprise’ by using the same term for a different purpose (closer to what you mean, in terms of Zachman etc). Probably a better term for “You can also visualise a Service as being a realisation of a Function” would be something like “You can also visualise a Service as being an implementation of a Function”, or “You can also visualise a Service as being a means of actioning for a Function”.
What I suspect you’re trying to do is mix at least two different types of modelling-concepts in the same space, and it just doesn’t work.
The key thing to understand about this approach to modelling is that each entity exists at only one Zachman-level. ‘Realises’ in the Zachman sense – and even more so in the Archimate sense, which is what I suspect you’re also adding into the mix – is between levels, not in them: and that’s an absolutely crucial distinction.
In the modelling-concepts I’m using here, a Function is just a prototype (in coding terms): it provides the interface spec, and the parameters and parameter-types for that spec – but that’s it. It can’t do anything, because there’s literally behind it. In a Service, we plug a given Capability in behind the Function, so as to make the Function actionable: our service-level and suchlike is a combination of how the Service presents itself (via the Function) and what it can actually do behind inside the Service’s ‘black-box’ (via the Capability).
In other words, the Service ‘realises’ the Function in the sense that the bundling-together of all the elements (Function, Capability, Location, Event, Asset, Decision/Reason and so on) is what turns the abstract prototype of the Function into something that is actionable. It does something – which the Function alone doesn’t, and can’t. (In these definitions, anyway.)
The reason why this is important, and useful for architects, is that it provides a consistent means to map out alternative delivery-options behind the same nominal service-interface – which is what we need to do for load-balancing, business-continuity, disaster-recovery and a whole swathe of other key architectural concerns.
If you try to mix this up with Zachman, you’ll get completely confused between alternative implementations versus logical-to-physical mappings.
If you try to mix this up with Archimate, you’ll get completely tangled up in the latter’s inherent IT-centrism.
The confusion here is partly my fault, and I apologise – I’ll need to fix it somehow. But overall, and in short, it’s really important that we don’t mix them up! 🙂
Continuing, to quote you above:
— Service – ABC
— Function – ABC (…) where ‘…’ Asset Type (Physical, Virtual, Relationship, Aspiration).
— Capability – Manual/Human, IT-based, Machine-based
Yes, that’s pretty much what we’re aiming at here. (A quibble is that for the Capability, you’ve only described the Agent-type; we also the Asset-type worked on – which would typically come ultimately from the Function-prototype – and the Skill-level for decision-making in the Capability.)
And on:
— Row-3/Logical:
— — Service – CRM
— — Function – CRM(AddContact,…)
— — Capability – Contact Management, Deal Management etc..
— Row-4/Logical:
— — Service – SalesForce
— — Function – SalesForce (AddContact,…)
— — Capability – Add Contacts
Yeah, again, that’s pretty much it. (In the Zachman sense, Row-4 realises Row-3. In the Archimate sense, we sort-of make it work that way as well, because Archimate arbitrarily conflates Row-3 with Business, and Row-4 with Application – but it’s a mess, because we have to kludge it horribly if we need it implement by a machine or a human ‘application’.)
Let me have another go at defining what I mean by “atomic business function”… It is the smallest unit of business functionality that can be potentially realised as a business service and thus “sourced” (in-sourced or out-sourced) and have a service level agreement as part of the Client ←→ Service Provider relationship. For an external-facing business function it approximates to a “user-goal-level” Use Case, e.g. Customer: Check-out Shopping Items.
Nowadays we often see two realisations of this business function in supermarkets, 1) the traditional cashier-mediated method, and b) the newer customer-self-service method.
Capturing, at the business function level, all metadata items that are common across its realisations can be very useful in its own right.
Great post. To Andrew’s point, a “Service” should be defined, independent of technology, as what is rendered, a discrete performance, which can be contextualized per delivery.
This is everyone’s favorite part of a human service, when someone recognizes a person and/or set of circumstances and tailors a response to that ‘event’. Dynamic adaptation promotes re-use of Capabilities.
This does go beyond the conventional SOA notion of ‘coarse-grained’ (generic) and ‘fine-grained’ (specialized) Services, in which the interface is static.
Technically, this is a shift towards a Functional Programming model with notions of formulas with variables resolved at run-time. This late-binding ‘generalizes’ the interface definition to increase expression and re-use of the Service.
We’ve developed an enterprise application platform that delivers adaptive Services that can be chained for adaptive Processes, while improving governance and scalability.
This was a bit hard to read coming from ITSM terminology, where a Service Desk is a “function” and I do not get the point of “everything in the enterprise is or represents or signifies a service”.
But I have been pondering the difference of infrastructure and service or service and self-service and reading this gave me some ideas. Here is a trivial example: If you live on and island a ferry is an important service. You need it because you do not have the capability of transporting a car over the water. Then they build a bridge. The bridge gives you the capability of reaching your outcome without any service. So the bridge is not a service, not even a self-service. The same thing happens in IT all the time. IT gives people capabilities, they do not require help (i.e. service) to reach their outcomes. What I’m trying to say is that wouldn’t it be useful to reserve the term “service” for actual service.
Thanks Aale
The key point about the assertion ‘everything is a service’ is that it’s just a means to introduce some consistency into an otherwise often-chaotic mess of confusions and miscommunications on terminology. I don’t pretend it’s ‘the truth’, just that proceeding as if it’s ‘the truth’ is useful.
The exact statement we use is that ‘everything is or represents a service’. In your island example, the actual service is the transport of the vehicle across water. (This is what you’ve termed the ‘capability’, which in this termonology is the means via which the service is delivered – not the service itself.) That service is the same in both cases – the ferry, or the bridge. The service-interface (the ‘function’) is essentially the same in both cases – there is an entry-point and exit-point for vehicles, a size-weight limit, and so on; the parameters of that interface are essentially the same in both cases (i.e. as associated with the function), but the parameter-values that each implementation of the service (via ferry or via bridge) are somewhat different (i.e. associated with the capability – the means of delivery).
I do indeed reserve the word ‘service’ for service – but it’s a much more precise and explicit and implementation-independent definition than the one you seem to be using.
The problem I’m seeing here all the time is that we have different definitions of all of these terms dependent on whose perspective (especially in the business-context) and/or the implementation-method (IT versus non-IT), which creates absolute chaos when we try to handle issues such as interchangeable implementations, load-balancing and disaster0recovery planning. The set of definitions we use here allow us consistency across all of that space.
You’re welcome to use different definitions if you choose: you’re not ‘wrong’ in doing so, and in a sense it’s none of my business. The catch is that if you do so, I can almost guarantee that you’ll create serious terminology-confusion problems for yourself and others as soon as you try to communicate with anyone outside of your own specific domain. That’s all that this is about: creating definitions that do make sense across all the different spaces – which is what enterprise-architecture is tasked with, after all.
Don’t get me wrong. I have just started to think about this. I realize the risks of terminology confusion. I see it all the time. I have been trying to find somebody interested in this specific question, so thank you!
My viewpoint is service operation. Do I get you right in the ferry case that the ferry operator has the capability to provide the service. The ferry is the function but the 7:30 run is the service?
The ferry service needs specific rules and processes to operate. The customer can only use the ferry when it operates. There is no 5:30 ferry.
Of course one can say that my drive over the bridge is also a service.
What I am trying to say is that the “service operation” of the bridge is quite different. Maybe an inspector visits the bridge once a year to check there is no corrosion etc. While the ferry operator will react to each service instance, the bridge operator does not.
Let’s think about the day when the new bridge opens. I can accept that from the customer point of view, only the parameter values of the service changes. The major difference is on the service operator’s side. The ferry people lose their jobs and all their processes are useless.
Thanks for the additional detail, Aale – and yes, you’re right, of course the service-operation is radically different in each case.
What this point around the terminology for service versus function versus capability and so on is about is that we want to be able to use the same terms consistently to describe the same types of things, regardless of the context or implementation or whatever.
This then links to what Dave Duggal above describes as ‘coarse-grained’ versus ‘fine-grained’ services – a kind of hierarchy from abstract-service to concrete (and very specific) service-delivery.
From what you’re saying, your own focus is more at the service-delivery end, and the related service-management. And at that level, yes, everything looks very different, dependent on implementation – exactly as you describe. Your work needs to focus on the differences – and be very clear about those differences, too.
In my work, as an enterprise-architect, I need to focus on the samenesses – which is why I tend to look ‘upward’ towards the abstract-service of ‘transporting a vehicle over water’. A literal customer-journey here would hold much the same view, too: they just want their vehicle transported over water by some means, and at the coarse-grained level of that process (a series of interactions with services to deliver the overall outcome of moving from one point to another), the exact details of the ‘transport my vehicle over water’ don’t matter all that much, as long as there is some means to transport my vehicle over water.
So as an architect, I need to be able to hold all the various trade-offs between implementations in mind. If the only option is a ferry, we need to look at the architecture of the ferry-based service, and how that would fit in with customer-needs, versus ferry-operators’ needs, and so on. If the only option is a bridge, then we need to do the same architectural assessment (though it’s probably a lot easier assessment, unless it’s a single-track bridge, or a lift-bridge across a sea-lane, in which case there’ll be all manner of complications around signalling and bridge-operation and suchlike. Then we’d also look at risk-assessment and capability-re-use: for example, if there’s a significant risk of damage to the bridge, or we need to preserve the skillsets and/or existing livelihoods of the ferry-operators, we need to keep the ferry going somehow, such as by repositioning it to serve another nearby pair or set of islands. (One of the key differences in service-characteristics is that a static bridge can’t move its start- and end-points, whereas a ferry-service can.) For example, if we don’t allow cyclists or pedestrians on the bridge, the tourist-board or some other body might fund the ferry to keep going for those users, and so on. There are lots of options here, and yes, a lot of human issues here too, and at the overall service-architecture level we need to be able to assess all of them – which is why we need consistent terminology across all of that, to be able to do like-with-like comparisons and so on.
We also need to draw a distinction between service versus service-instance. The abstract-service is ‘transport vehicles and/or passengers over water’. In our example, we deliver this ‘coarse-grained service’ via the ‘finer-grained’ service of the bridge or the ferry: each of these still fits the definition of ‘service’, because they represent (or, more specifically, enact) a service, with an identifiable interface (function), means of delivery (capability), assets, events and so on. A service-instance is the actual service-delivery: a traverse of the bridge, or transit on the 5:30 ferry. From the service-operator’s perspective, service-delivery is (probably) continuous on the bridge, so it’s hard to see the individual service-instances; service-delivery on the ferry depends on the schedule of the ferry, and hence it’s more evident that there is what we would call a ‘service-schedule’ – a series of ‘packagings’ of instances of service-delivery.
There’s a lot more detail that we can go into in this: it really depends on how far ‘down the rabbit-hole’ you want to go. 🙂 But the point I’m making here is that we’re able to use the same terminology in a consistent way, at every level, for every viewpoint and every implementation, regardless of how deep we go. That’s what the real aim is here: the rest of it – and the use of that terminology – is literally is just detail.
This makes sense, I hope?
There are differnt perspectives on a Service. My view is that a Business Service is something seen from and external viewpoint. A customer expects or buys a Business Service. The Business Service represents the ‘what’.
A Business Capabilitiy is the ability to do something. A Capability is then the internal realisation of an external Business Service. The Business Capability presents the ‘How’.
A Business Capability is in turn implemented by a collection of various internal elements which includes Business Functions, Business processes, Application Services and the Applications that realise those Application Services, with internal Application Functions.
@Adrian: “There are different perspectives on a Service” – yes, strongly agree.
“A Business Service is something seen from an external viewpoint” – that’s a view, yes. My point here is that if we’re looking at the same thing (here, a ‘service’) from different directions, we should be able to identify it and work with it as the same thing, surely? A door remains a door regardless of which side we come from; we should be able to do the same with service.
Another key point here is that Business Service is a label that’s applied to a somewhat arbitrary choice of view of service with somewhat arbitrary boundaries at a somewhat arbitrary level of abstraction and/or granularity. What I’m aiming for here is a consistent means to describe the nature and structure of service at any/every level of granularity and from any viewpoint. Doing so takes the arbitrariness out of qualifiers such as ‘Business’ versus ‘Application’ versus ‘Infrastructure’ and the like. Once we have clarity about the service itself, we can put the qualifiers back, if they’re useful – but at least with a far better understanding of just how arbitrary and potentially-misleading those qualifiers are.
To illustrate: your Business Service represents a ‘what’ and a ‘how’ and (perhaps more importantly) a ‘why’, in different ways and in varying combinations, depending on who’s seeing it and from which perspective. The end-customer usually doesn’t view it as a capitalised ‘Business Service’, for example: it’s just a collection of services that they see, built on top of services that they usually don’t see. The ‘Business-‘ qualifier just serves to confuse things: it gives it a sense of certainty and boundedness that is entirely spurious – much like the dreaded TOGAF-style ‘layers’, which mislead almost everyone into thinking that those arbitrary and often-fluid boundaries between them are somehow ‘real’.
If we strip it right back, then a service is the active, available encapsulation of the ‘what’ and ‘how’ and ‘why’ and ‘where’ and ‘when’ and ‘whom’. A capability, as you say, represents the ‘how’ that enacts that service; the assets provide the ‘with-what’ of that service, and so on. The danger with qualifiers such as ‘Business-‘ versus ‘Application-‘ versus ‘Infrastructure-‘ is that we end up putting more emphasis on the qualifier than on the service or capability or function or whatever that it qualifies. The simplest test is that if the sense or meaning changes with a different qualifier, or if it signifies a fundamentally different aspect of service with a different qualifier, then your terminology is all but guaranteed to be misleading.
The qualifier (Business, Application etc) is arbitrary; the component (service, capability, function, location etc) is not. We need to be very clear as to which is which.
Hello Tom and Andrews,
Les’s take an example.
I am a cook on a boat (or in a restaurant): cook is my function.
I know how to cook, it’s my capability (ability to do).
The service I provide is to prepare meals.
If I have the cook function without having learned to do (I do not have the capability) I am unable to provide the service. Therefore a function alone, without the capability does nothing.
Without capability you cannot provide the service (prepare a meal)
We can visualize a service as a realisation of function (with a capability).
Does it make sense ?
@Jacques: “Let’s take an example” – yes, good example.
In my view it’s slightly easier to visualise if we think of function as a declared-interface: I declare that I can deliver the service of ‘prepare meals’. In the classic Taylorist form, my job-description is also my function-definition: it’s my declared interface with the rest of the overall business-system.
“If I have the cook function without having learned to do … I am unable to provide the service.” – mostly, yes. For machines and IT-systems, if they don’t have the required capability built into them, they often can’t deliver the service at all: a distinct boundary between ‘can’ and ‘can’t’. With humans, the boundary is often much more blurry: I may not be able to cook a cordon-bleu meal, but I can probably cook up something that’s vaguely edible. 🙂
One way to make sense of this is to say that:
— the function defines the parameters of service
— the business-decisions that underpin how the service is brought together will define the expectations (the ‘promise’ or ‘value-proposition’) of service in terms of those service-parameters
— the capability will in effect determine the actual quality of delivery of service against those parameters and expectations.
(Re the remainder of your example, yes, I strongly agree: that’s exactly what I mean.)
Tom
Sorry to bother you with this again but I have been thinking about IT service catalogs and SLA’s and keep returning here (I do read your newer stuff too;)
IT services are complex and many are far from the end users. A person is doing valuable work but the benefits materialize far away with no direct contact.
Is there some benefit in trying to create a service catalog which is complete and serves both the customer and the service provider’s staff?
Do all services need a SLA? A complex SLA chain requires some (lot) effort. Is it worth it?
Hi Aale: “Do all services need a SLA?” – the formal, exact, technical answer is ‘Yes’. But in practice only real answer is a combination of ‘It depends…‘ and ‘Just Enough Detail‘.
And what it depends on, and the amount of detail you’d need in the SLA, is determined by the boundary and scope and scale of the service. And you decide what those are; which means that you decide what SLA you need in each case, and what level of detail you need. There’s no preset answer that always applies.
SLA design is not my field – in fact I’m certain you’d know much more about it than I do – but I believe there’s some guidance on this in ITIL, for example?
The only point I’d add is that sometimes it is worth the effort following through the whole of an SLA chain from end-to-end: it’s a really good way to catch ‘forgotten’ issues or nasty responsibility-gaps. But you’re right, for most business-cases it’s certainly not worth doing it for everything: the only exceptions would be very much special-cases such as very-high-risk security, or space-missions and suchlike where there’s no way to fix it if it goes wrong. Again, those always-tricky principles of ‘It depends…’ and ‘Just Enough Detail’ are the most important principles here: and it is worth while making those principles explicit in relation to the content for your IT service-catalog.
Thanks Tom
I am involved in a heated discussion on the usefulness of ITIL. My presentation (Unlearning ITIL) in itSMF UK Confence in London earlier this month created a lot of discussion.
People seem to have a high failure rate in trying to use ITIL and one reason might be that the problem is in ITIL. There is a lot of questionable stuff in ITIL but I have an idea that it might be as fundamental that the concept of service is misunderstood. ITIL talks about managing the lifecycle of services but in fact means the lifecycle of tools or applications.
One specific problem is the you as in “And you decide what those are; which means that you decide what SLA you need in each case”. When IT decides their services, the business has no idea what they are talking about.
It seems that it is quite hard to define IT services in a useful way. Either they are too technical or too vague.
Hi Aale
“ITIL talks about managing the lifecycle of services but in fact means the lifecycle of tools or applications” – ouch… I’d agree that that’s not the way to do it.
“It seems that it is quite hard to define IT services in a useful way. Either they are too technical or too vague.” – if that’s the case (and from my own experience as well as your comments here, I fear that you’re right), then that’s a challenge that must be faced. If we don’t have an adequate definition of IT-service, then by definition IT service-management will be going nowhere.
To me the ITIL principles (or rather, my view into those principles, which may not be the same…) do seem to work well if they’re applied to ‘services’ as I’ve described the term – literally, ‘that which serves’. But they probably won’t work well if we misdescribe capabilities as ‘services’ – which is what’s implied if we look only at tools or applications, without enough crosslink to the human and other aspects that make those tools or applications or applications usable in real practice. It’s the interweaving of the various service-components that form the crucial factor in service-management: the components themselves are often largely interchangeable. (The critical factors occur where those components are not interchangeable – and that’s often more around the human aspects of services rather than the technical ones.)
My feeling here is that you’re up against an ‘invisible elephant’ – something that’s both huge and important, yet no-one else seems to be able to see. Right now I don’t see it anything like as well as you do, but I can at least recognise that there’s something important there that definitely needs to be addressed. (And yes, I do know how frustrating it is when others can’t see something that’s seemingly obvious to you – witness my struggles against IT-centrism in enterprise-architecture, for example… 🙁 ) So yes, let’s keep talking about this: I’ll help as best I can.
And thanks too for continuing to push me on this: it does matter.
“Invisible elephant” is a good metaphor:) I don’t know how closely you have followed the evolution of ITIL so I explain my view of how it has gone. Original ITIL had 10 processes and one function, the service desk. In V3 the view was changed to service life cycle and the number of processes more than doubled. V3 books had a lot of errors and were partially rewritten in 2011 Edition. I find it quite questionable that IT should be able to design and plan the service life cycle. I can see IT planning infrastructure component life cycle but that is
In practice people are still struggling with the basic processes and just last week there was an interesting discussion concerning the service catalog, which is a central element in ITIL. It seems that it is quite difficult to create a working service catalog which would be basis for service level agreements and service improvements.
One approach is to make a long list of services like this:
1.01 Support for IT Services 9
1.02 Access to IT Services .10
1.03 Information and feedback about IT services 11
1.04 Orientation to University IT services.12
1.05 Internet access 13
1.06 E-mail services.15
1.07 Electronic file storage .17
1.08 Networked printing for staff.19
1.09 Networked printing for students 20
1.10 Desktop environment for staff 21
1.11 Desktop environment for students.22
1.12 Calendar services 24
1.13 Wireless services.25
1.14 Remote access services.26
1.15 Telephony services 27
1.16 Mobile voice and mobile data services.28
1.17 Local data services 29
1.18 Audio Visual Services 30
The whole catalog is 70 pages long and btw lists Enterprise Architecture as one IT service!
The problem with the service catalog seems to be that it is either quite vague or very fragmented and it seems hard to solve the problem. The IT department might be meeting all SLAs but the customers might be quite dissatisfied with the service.
On solution is to create a well defined and standardized service product with clear boundaries but that is hardly the ideal solution in all situations. The service product will have limitations.
Another approach might be to reject the IT service approach, i.e. stop trying to define IT services. In that case IT would be just one component of the enterprise-level service.
How do you see enterprise-architecture, is it a service? If it is a service what is the SLA? If it is not a service, what do you call it?
There is an unfinished sentence: I can see IT planning infrastructure component life cycle but that is a different story!
Hi Aale (and apologies for the delay in reply)
— “I don’t know how closely you have followed the evolution of ITIL”
Almost certainly not enough… I did note the key transition from ITIL v2 (rigidly IT-centric) to v3 (probably too generic?), but that’s about all I know. Does kinda seem to me that your struggles with ITIL are similar in many ways to the struggles I’ve had with TOGAF etc… 😐
— “One approach is to make a long list of services like this …”
Yes, it’s one approach, and would probably be useful – if not essential? – at the organisation-level (or more accurately context-level). But if the aim is to document every possible IT-service etc, I would see it as a pointless and futile exercise: almost by definition, it will always be in some part out-of-date-, incomplete and probably inadequate. Another variant of the ‘Just enough detail‘ challenge, really.
— “The IT department might be meeting all SLAs but the customers might be quite dissatisfied with the service.”
Which provides a really simple test as to whether they’ve described their SLAs properly, don’t it? 🙂
— “One solution … another approach …”
This feels to be both yet another variant on ‘Just enough detail’ and also yet another variant on the theme of ‘backbone versus edge’ – see ‘Agility needs a backbone‘, ‘Architecting the enterprise backbone‘ and ‘Backbone and business-rules‘.
— “How do you see enterprise-architecture, is it a service?”
Yes: it’s a support-service for decision-making relating to cross-enterprise integration and change.
— “If it is a service what is the SLA?”
I’ll wriggle out of that one a bit by saying ‘It depends…‘! 🙂 What it depends on are factors such as the focus (eg. IT-centric versus business-centric versus whole-enterprise) and the maturity-level (eg. as per my book ‘Doing Enterprise Architecture‘, plus all of the business-context and business-needs within that context.
— “If it is not a service, what do you call it?”
A mess. 😐 Or, more likely, a ‘solution’ looking for a problem. Oh well. :wry-grin:
Hope that makes sense, anyway?
Thanks, I had been worried that I had pulled too hard my Brio train and lost you 😉
Yes, I think this is starting to make more sense. I have been having a number of discussions round this and I think I start to see the light. The Service Catalog model is too simplistic and in many cases at the wrong level. It is just that this Service Catalog – SLA has been so central structure in ITIL and I have been teaching it so the transition is a bit hard.
I think that instead of just looking at service components, one should concentrate more on the business outcomes. An IT service component is good only if it helps to produce the expected outcome.
In that sense the SLA goal of entarch should be the success of the enterprise goals it supports.
Hi Aale
— “Thanks, I had been worried that I had pulled too hard my Brio train and lost you 🙂 ”
No, it’s just that I’m Mr Erratic – too many things on my mind, I tend to wander from one thing to another at random and, uh, sometimes don’t notice what I’ve missed… 🙁 If you need an answer on something, just kick, okay? 🙂 (Or kick harder, if need be…)
— “In that sense the SLA goal of entarch should be the success of the enterprise goals it supports.”
Yes, I’d strongly agree with that as the SLA goal. The hard part is finding the SLA-detail for all of the bits in the middle… 😐 (Much as you know with ITIL, I presume?) But I’d certainly suggest that keeping the overall goal and business-need front-and-centre of any SLA-description would be the essential: everything else is just detail, really. (As per the ‘Just Enough Detail’ post, in fact.)
Tom
Thanks for this articulation – very helpful in “sorting things out”. I absolutely agree with you on the need for clarity on intended meanings in this space.
Two thoughts that arose from reading this:
> On its own, a capability literally has no function
I think you could equally have said, on its own, a capability literally has no purpose. I wonder if it is function and service that bring purpose to a capability? (I could add more but will leave it at this point to keep the conversation open-ended).
> the service-interface (function) is essentially the same in both cases (water crossing service)
Not so sure about this. The bridge offers a continuous service (barring major maintenance). The ferry offers a discontinuous service, and depending on the operation – may require a “request interface”, a “loading interface”, a “queuing interface”, to name a few additional aspects.
I might not be using the right terminology, but, depending on the capability being used, the service interface could vary significantly, could it not?
Thanks for this, Peter.
“I think you could equally have said, on its own, a capability literally has no purpose.”
Very good point. 🙂 There’d usually be some intended purpose when the capability is created, but even that could well become lost as time goes by: look at all the ‘capabilities’ represented by all those abandoned military structures and hardware from past ages still scattered across most nations’ landscapes… 😐
“Not so sure about this. The bridge offers a continuous service … The ferry offers a discontinuous service”
I went into this in some detail in one of the long responses to Aale above, though you do raise an important additional point about ‘child-services’ and levels of aggregation or composition.
At the highest, most-abstract level, the function-interface is the same: it’s a point on a road. The parameters for the service-interface are the same: the nature of the service, and the qualitative factors that determine the content of the service-contract, service-level agreement and suchlike. The parameter-values are different – continuous-service on the bridge, discontinuous service on the ferry – but those are derived when we link up the capability with the function, to deliver the respective service. In effect, that difference of linkage to capability is what underlies the difference between function and service.
What you’ve added here is that once we’ve linked the capabilit(ies) to the function, the capability itself may impose its own ‘child-services’, each with their own function-interfaces and capabilities. Hence, as in your example, ‘a request-interface’, ‘loading-interface’ and ‘queuing-interface’, which each represent distinct service-delivery requirements.
If we compare the ferry to the bridge, we’ll actually see that the same ‘child-services’ do still exist for the bridge: it’s just that they tend to be rather less visible. For example, if it’s a toll-bridge, there’s a ‘request-interface’ and probably a ‘queuing-interface’ at the entry to the bridge; and the ‘loading-interface’ is the bridge-ramp, which might itself be controlled via traffic-signals, such as for a single-lane bridge.
Hence it’s useful to run up and down the layering, first to the highest level to identify the similarities, and hence substitutability and suchlike; and then down into the ‘child-services’ and ‘sub-child-services’ and so on, to identify the details for the trade-offs and for the respective service-contracts.
The distinctions between service, function and capability do still work in each case there, and help to introduce some much-needed rigour for architectural concerns such as substitutability.
If you write:
– everything in the enterprise is or represents or signifies a service
– a process links services together in some way to achieve some kind of outcome
– a function is an external view of a service – in effect, a description of its interfaces (‘black-box’ view), often together with a summary or overview of what it does and how it does it (‘white-box’ view)
you are exchanging the terms ‘service’ and ‘function’ with respect to how I’ve seen it used so far (e.g. in ArchiMate but also elsewhere).
I’ve seen service more often described as the external ‘side’ of some behaviour (such as a process or a function). Service is what the user of the service sees (uses).
I’ve also often seen a process described as linking together functions to produce some sort of outcome. Anyway, there are many, many ways to do this and there is no agreement between practitioners, also because in today’s modern complex landscapes there is both IT behaviour and human behaviour closely intertwined and the IT-culture and the Business-culture have separate languages on the subject.
I like to see a service as ‘the usable part’ of a function/process. The service cannot exist separately from that what makes it happen (unless you define service as the ‘requirements’ and not the ‘actual service provided’).
Hi Gerben
Looks like this one’s going to take a lot of explanation… – an explanation that really should be out at the front level of this blog, not deep down in the basement of a three-years-ago post. May I use your comment-text above as the start-point for a new post?
For a quick summary here:
– I use ‘service’ as the label for ‘the active whole’ because that’s what’s used pretty much everywhere else as a generic. For example, we’d talk ‘product or service’, not ‘product or function’. We’d talk about ‘IT Service Management’, not ‘IT Function Management’.
– Quoting Archimate as a source of ‘correct’ terminology is a bit of a red-rag-to-a-bull for me. I’m going to be really blunt here: I’ve never seen anything resembling sense, or consistency in any of Archimate’s terminology. It’s a mess. Even at first glance it’s a mess; digging deeper down into its anatomy, as I did in that long post a few years back, demonstrated just how much a mess it really is. It started off with a couple of very good ideas, got dragged off into the IT-centric booby-trap early on, consistency and logic falling apart very quickly after that, and downhill all the way since – especially since Open Group barged into the story. Oh well.
– My core concern here was to make a terminology-set that would work at every level, in every usage in every aspect of the enterprise, and for every instance in every form of fractality. Virtually every other attempt at service/function/whatever terminology has thrown away at least one of those concerns, and often all of them. I don’t claim that it’s perfect (it isn’t, and it never can be), but at least it’s a damn good try, and it is consistent throughout the respective context-space. Which is a lot more than can be said for anything else that I’ve seen so far. Sigh.
Anyway, more on this in that upcoming blog-post – if you’ll let me use your comment-text above, that is.
My penny:
1. Function: the interface.
2. Capability: the performance of the function.
3. Service: the implementation.
From Systems Engineering: The Functional Requirement is the Verbial action. A Functional Requirement means nothing unless it has one or more Performance Requirements or Constraint Requirements attached to it. This therefore specifies how much, how many, etc. The Service is the implementation (or specific instance) that provides the Function with the attached Capability.
One possible example mentioned before:
Function – Cook
Capability – Fish (or meat: medium rare, etc). Could be a set of capabilities. Could also include the preparation time for each, etc.
Service – the Function/Capability or set of Functions/Capabilities as implemented by a restaurant with its cook, oven (and other facilities), including recipes, etc.
Corrections:
A better description of the Function would be “Prepare food”.
The Service is actually not implemented by the restaurant, but by the kitchen.
“The Service is actually not implemented by the restaurant, but by the kitchen.”
Actually, both are true 🙂 – it depends on what level of abstraction we choose.
From the outside (the street, the newspaper-advert, the menu-flyer dropped at your house), the Service appears to be delivered by the restaurant as a whole.
Once you’re inside the restaurant, the Service is delivered by the kitchen.
Or delivered by the waiter, if you focus the Service-boundary on you and your table.
(Oh, that dreaded phrase ‘It depends’…! But important, nonetheless. 🙂 )
Thanks, Freek – yes, that’s pretty much exactly what I’m aiming for in the definitions I use. One of the key confusions that can (and do) arise from this is that, from the outside, Function and Service appear to be the same thing (because Function is the exposed/visible interface for the Service). Which they’re not: as you indicate, the Function can’t do anything without some kind of Capability plugged in behind it, and the two together provide the core of the Service. (There’s also the need for the ‘with-what’, ‘where’, ‘when’ and ‘why’, but as explained in my definitions, they’re somewhat distinct from Function and Capability.)
A key point that I need to re-emphasise is that any appropriate Capability might be plugged in behind the Function. For example, if the Service is ‘travel between cities’, and the interface (i.e. Function) for the Service is that start- and end-point for the journey, then we might use any means (Capabilities) – rail, air, car, taxi, bus, bicycle, ship, walking – and in any combination, in order to deliver that service. In effect, the Function provides a structured wrapper around the Service as ‘black-box’.
For ‘travel between cities’ service, what is the function in level 3 (implementation independent) vs. level 4 (implementation dependent)?
How does the function change from logical to physical in that example?
Since writing this in 2012, with 9 more years of experience in the trenches, how would you describe it now?
I’d reply that my views remain essentially the same. Do note that there’s a lot more detail and worked-examples in the other comments in this post – do look at those as well as at the initial post itself.