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."
Over the past few months I have been on a journey to deepen my understanding of the term "service," and to test for some level of consensus among a number of interested parties.
The unclear semantics of "service," "IT service," and related constructs has been a recurring matter of debate in various forums. Some service scholars have despaired of any common definition achieving general acceptance. However, my view after doing this work is that a common definition appears achievable.
I am compiling a list of the ITIL v1 titles for future reference. Thanks to Martin Erb for many of these, and for pointing me to AbeBooks.com where I found most of the rest. Some are from a picture of book spines so may be inaccurate (I am questioning the SSADM one).
Bill is a database administrator in a large enterprise. Or a Unix administrator, or a security architect, or any of a number of similar positions providing shared services. There are three primary ways that demand for Bill’s services appears:
Project managers come to his boss and ask for a percentage of his time. Once he is designated as a project “resource” he has deliverables: requirements and design assessments, perhaps actual construction of infrastructure. He also finds himself responding to lightweight project workflow for “issues and risks” and “action items.”
He is assigned incidents, service requests, work orders, changes, and the like through various enterprise workflow systems, especially the integrated IT service management system.
He also is tasked by his manager with responding to various “initiatives” that occupy a middle ground between projects and workflow: audits, compliance efforts, capacity assessments, root cause analyses, key system reviews, and more.
On Wednesday, he gets called into a Tier 2 incident involving the organization’s marketing campaign system. On Thursday, he has a deadline of responding to an audit finding for the organization’s payroll system. And on Friday, he has a critical path deliverable due for a strategic enterprise project. Fun life!
I invite you to join me at IT Management Architectures, the new LinkedIn group replacing the erp4it Yahoo group, which will be sunset soon.
Wordle is a gratifying creative outlet and I spent some time honing the above diagram based on the group description. But the use of a Wordle diagram is more than just eye candy. It reflects my intent that IT management framework development should be empirically based. It's also a good way for you to tell at a glance if the group is of interest to you.
Anyone know how to download an entire group's discussion history from Yahoo?
What I find interesting is the emphasis on science.
"Relying on common sense to make such decisions is unreliable, as the effects of graphic design choices are often counterintuitive."
Moody here is criticizing statements by the originators of the Unified Modeling Language. I think similar observations might be made of the existing IT management frameworks' choice of terms - the all important concept of ontology.
What can we learn from this paper in developing a reference architecture for the business of IT? Moody makes the case that the human factors implications of symbolic choices are well understood; there are applicable theories. I would suggest similarly, we need more rigorous insight into semantic choices, the process by which they are made, and the effects they have.