Part 2 of this series (Part 1)
(updated thisimage 3/16)
Longtime readers will know I always care about semantics. Questions of definition have been a staple of this blog. Might be why I don't get as many readers as some others, but I'm happy with the quality of the audience I attract.
In the last post on this topic we discussed the distinction between service and service offering, in light of recent service definitions, for example Steven Alter:
"A service is an act performed for the benefit of another."
The key word here is *act." The Online Etymology Dictionary defines it thus:
act (n.) late 14c., "a thing done," from Old French acte "(official) document," and directly from Latin actus "a doing, a driving, impulse; a part in a play, act," and actum "a thing done," originally a legal term, both from agere "to do, set in motion, drive, urge, chase, stir up," from PIE root *ag- "to drive, draw out or forth, move" (cf. Greek agein "to lead, guide, drive, carry off," agon "assembly, contest in the games," agogos "leader;" Sanskrit ajati "drives," ajirah "moving, active;" Old Norse aka "to drive;" Middle Irishag "battle").
As in the previous blog - "act" is clearly a dynamic, ephemeral concept - a sequence of interactions, and not equivalent to either their desired outcome, nor their performers.
- I look up my bank balance on 25 May 2014 to determine if I can afford to go out to dinner.
- I join an online (computer screen sharing and audio) conference for 30 minutes on 10 December 2012 between 10 and 1030 AM CST.
- I edit a blog post for 90 minutes on 9 March 2014, and successfully publish it.
Clearly, the idea of "act" is ephemeral, but how is it that the act comes to be? At least in the case of desired and intentional behavior, there is some means by which the act and its desirability is characterized, e.g. a service offer.
To have a legitimate offer is to have a capability and so for now I would equate service offer with service capability:
- A bank with online and/or mobile banking offerings
- An online conferencing service offering
- An online blog hosting service offering
And finally, the capability is not the implementation, at least as I understand the term "capability" and its use in enterprise architecture. A capability may be enabled in various ways by underpinning systems.
Jim Spohrer has proposed that "The service system is the basic unit of abstraction of service science" with the following definition:
we define a service system as a dynamic value co-creation configuration of resources, including people, organizations, shared information (language, laws, measures, methods), and technology, all connected internally and externally to other service systems by value propositions.
The act, and the offering, are important concepts. But the act is ephemeral, and value propositions shift over time. Service systems are (in my experience) the persistent subjects of actual investment. They are what enterprises manage in portfolios, and are suitable for (e.g.) Total Cost of Ownership analysis. And although Spohrer defines them as "dynamic," I think the systems are relatively more stable than the offerings or (especially) the acts.
To me, "service systems" are first and foremost systems. Examples would include:
- A customer demand deposit system, run as an operational service by a bank, based on the Hogan software product from CSC
- A unified communications system, run by my company's networking group, based on Microsoft Lync
- A hosted blog system, based on Wordpress
These service systems do not equate to the software (Hogan, Lync, Wordpress). They are operationally supported and include people, process, and technology. They also do not equate to the offering, as the system can be exchanged while the offering remains the same. I believe they *can* (not *must*) have the following subtypes:
- Application Service System
- Infrastructure Service System
(Broader definitions and types of service systems can be seen in the Wikipedia definiton, which I came across after I drafted the majority of this post.)
What does this buy us? Well, if we equate Service Offering with Capability, and accept that Service Systems may be Applications (assuming we do not equate Applications with mere Software), we can link services science and service theory (and hopefully by extension IT service management) to enterprise architecture and IT portfolio management.
It also imposes a requirement for some semantic precision. In many quarters, "IT Service," "IT Service Offering" and "IT Service System" are confused. Because they have such different connotations, the three aspects generate a lot of circular, religious discussion that I for one have spent too much time on. Common usage won't change overnight, but if these concepts prove useful in untangling some debates you're having, then I have succeeded.
As I've seen over the last 24 hours on Twitter, there is a lot of passion out there on these topics and especially on service-dominant logic and its (potential) influence on IT Service Management. My objectives are simpler and perhaps more practical: I am just trying to put together a workable conceptual data model that (when translated into its own service system) IT organizations can maintain at scale.
I will be talking more about this in the context of the IT4IT Consortium in the months to come.
Postscript: I recently discovered the BORO methodology which is why I am providing examples of every major concept I propose. I increasingly require this of anyone who wishes to discuss such topics with me. My experience, and that of other ontologists working at scale, is that unless you ground your discussions in examples, the debate turns religious and unhelpful.