One of the hallmarks of mature professions is that they have a clear and detailed language - a domain (or universe) of discourse or an ontology.
In the development of a human profession (such as IT), the profession's language is rarely if ever pre-ordained - it is collaboratively and often messily defined, based on real world experience, with major codifications (e.g. GAAP for the profession of accounting) as historical watersheds, and essentially contested concepts as landmines.
Gabriel Morgan's conceptual model of business-IT traceability represents a fairly standard, stripped-down view of a "stack" of concepts showing business-IT traceability, similar to many I have sketched and seen presented by enterprise architects.
For example, here is one from my book:
While my model and his differ in some respects, they are both simplified models of a domain language. They are more than glossaries, because they also imply a hierarchical relationship; the boxes are richer than appear at first glance because (for example in mine) there is also an implication that Databases only interact with Networks via Servers.
But why do we even care about this? Is it merely academic? No. The position of the IT profession, circa 2007, is that it has multiple overlapping domains of discourse, along with badly overloaded terms. We can see a small example, if we contrast Gabriel's model with mine: his uses the concept of Application, while mine uses the concept of Service. (I have other models which represent Application as a subtype of Service).
Two of the major domains of discourse are architecture and IT service management. I use architecture generally to include
- Enterprise architecture
- Application architecture
- Software architecture
- Data architecture
- Network architecture
- Technical architecture
all in the general enterprise IT sense. (This is not a discussion of computer architecture in the rigorous EE/CSCI sense.)
IT Service Management (ITSM) is a loose term for a growing body of theory and practice revolving around the customer's experience and perception of IT interactions; the best known (but by no means only) example of an ITSM framework is ITIL (Information Technology Infrastructure Library), whose v3 release was one of the major IT events of the year.
Most architects, if they hear the word "ITIL," will say "That's just about operations, right?" Actually, no; ITIL has always covered the entire lifecycle of large scale IT operations, with the following key exceptions:
- Program Management
- Project Management
- Software Engineering Methodology
IT portfolio management, however, is definitely in scope, as are non-functional system requirements and a variety of other concerns that overlap with the architecture world.
In reviewing the domains of discourse for architecture versus ITSM, there are of course many points of consistency. However, one of the most troublesome terms is "service." It is of course confused with SOA, and in the ITSM world "service" is used as a surrogate for "application" as enterprise architects typically understand that term. (See also my long debate with Troy Dumoulin on this topic.)
The semantic debate is becoming sharp and specific, one that any good data or object modeler can understand. Either:
1. An Application is a subtype of Service
- OR -
2. A Service is composed of Applications.
I prefer the first, because it is simpler. One thing that the ITSM theorists do not seem to understand is that "Application" is itself a logical consensus concept. (Martin Fowler calls this the ApplicationBoundary problem.) Note that one of Martin's definitions is "A group of functionality that business customers see as a single unit." That definition takes the Application concept squarely into the territory inhabited by the ITSM Service concept.
Now, because "Application" is a logical concept, it is hard to standardize. Not impossible, just hard. You have to define a process with owners for establishing an authoritative application list, just as your company probably has a process for maintaining an authoritative chart of accounts (another logical list). Many mainframe shops had such a process, but some let it lapse in the world of distributed computing.
OK, so we have a master list of Applications. If we are following #1, we are done. But if we are following #2, we are only half way - now, we have to define another logical layer called "Service." That will also need an authoritative process, and we will now have to map all the Applications to Services (requiring, on the data level, an "intersection entity.") Because of this mapping, #2 is not twice as hard - it is at least three times as hard, with the potential of endless circular conversations about definitions and so forth.
Which of these two data structures would be easier to maintain? The inheritance arrow on the left means that you only need to establish an Application and then it is automatically a Service. The structure on the right requires deliberate population of all three entities - higher training costs, more opportunities for bad data quality, and so forth.
If we go with number 2, we now have two logical concepts. It's hard enough in my experience just getting the application portfolio right - establishing a process for maintenance and a good clean baseline data set seems beyond the grasp of too many peers I talk to. (It's a standard question I ask when presenting at conferences; I rarely have more than 1-3% of my audiences claim they have this settled).
As Steve Bellovin of AT&T Labs once said: "Any software problem can be solved by adding another layer of indirection." The ITIL/ITSM insistence on distinguishing applications from services represents exactly this. The trouble is that there is always a price to be paid for that layer. "Walk before you run." Even if there were utility in two concepts, it might be an advisable maturation process to focus first on applications AS services, and then elaborate (as needed) into services that are composed of applications.
However, there is no question the term "Service" has to be worked into the IT stack. There is far too much momentum around it, even to the extent of U.S. Congressional Legislation. (Really!) For better or worse, IT domain models, even at the level of the very simplest discussed here, need to incorporate it.
This is only scratching the surface. Other semantic minefields include:
- Business motivation (by far the most thorough treatment is here)
- Business Service versus IT Service
- Capability versus Service versus Function
- Business Process versus Business Function
- Data versus Information
and so forth.
In all my work, I have treated these questions a posteriori. I took the terms as I found them; reading various texts (e.g. all of ITIL v2) and attempting to synthesize a workable ontology through applying conceptually modeling hermeneutically. I'd contrast my approach for example with this IBM metamodel, which, while interesting and obviously the work of highly intelligent people, has "a priori" aspects - parts that have been synthesized. (For example, "Service Theme" is not a widely used industry term.) We have to start with the current state of the practice and its terminology - and any rationalization of these overloaded and slippery terms will require compromise.
All for now,
Charlie
