The evolving domain language of IT... and more on Application versus Service

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

Comments

[Gabriel Morgan]

Great blog. I'm glad to hear that we are not the only ones struggling with defining terms as common and simple as Application :).

With regard to understanding the word Service within an IT context, or Business Application Services to be more specific to how I'd like to respond, I see Services not as applications per se but rather a description of what it provides with a very specific definition to ensure uniqueness.

In some ways a Business Application Service is merely a public, well defined application interface that is flexibly built that automates a business process activity. Of course this definition requires that Services have one or more applications to perform the function the Services describes but isn't directly synonomous with Application - it is focused more on the interface and function description the Application provides and not the components, bits and bobs that do the work.

For this reason, I lean toward your definition of "A Service is composed of Applications." and painfully recognize the challenges of actually implementing this definition in my day-to-day activities. The danger of assocating Service to Application is assuming that Services are synonymous with Applications and this approach is largely responsible with getting us into the situation of muliple siloed applications/services we so dearly want to move away from. We need to design systems so that they are not ripped and replaced with the business process change or a new IT platform is changed. We need System Flexibility to buffer the impact of these changes in our IT systems.

Although I recognize the challenges of managing an inventory of Services separate from managing an inventory of Applications, it is necessary in order to evolve and provide System Flexibility with the purpose of improving business agility to our IT and Business stakeholders.

Please note that I don't think that there is a right and wrong answer here. Each of us deal with the cards we are dealt. There are situations where either of these definitions work, and appropriately so. In my current situation, we are entertaining a number of techniques and I thought I'd just share my thoughts. :)

[Mike S.]

I work for a large insurance/financial services company and we also are struggling with this. I joined an architecture team less than a year ago and the first thing they gave me was to "define Application and get everyone to agree." I have been struggling through questions like this ever since. Finding this blog and the "Shoes for the Cobbler's Children" book has been a tremendous help to me.

With regard to this specific question we are also going with the "Service is composed of applications" approach. An example of where we this applies is the "Agent's Auto Quotes" service - where we have a mainframe-based app and a web-based application that both provide the agent a way to quote auto. I just don't think I can convince others that these two things are the same application, although I could suppose I could argue they are two software systems supporting the same application. But most of our services are larger-grained than this example - it would just be hard to equate them with apps in our environment.

[alex]

Developing a taxonomy in a field where terminology is used casually and new words are coined nearly every day is indeed extremely difficult! In the end, when people review the terms of the new taxonomy, they should easily recognize the terms from their own contexts and arrive at the same meaning as intended by the taxonomy's author. Unfortunately, words like "application", "service", and "server" are so abused that they can in some cases be seen as synonyms (imagine an http daemon being called any of those three words). Nevertheless, I agree that you should start with the "current state of the practice and its terminology".

One problem with early attempts at a domain model (e.g, DMTF) is the enormous size of the basic model. Hard to understand schemas (too many classes, too many relations) only lessen the chances for adoption. The taxonomy's metamodel should be very small and intuitive. Higher level, more specific domains should be developed from this simple metamodel. This compositional nature, I believe, is just as important as picking taxonomy terms that are correctly understood by users.
It's an important concern because until there is an industry wide adoption of a standard model, we will rely on making meaningful translations between the first ones that emerge.

Alex
---
dev2ops: Driving change from dev to ops in a software as a service world. A view from the trenches.

[Dr Dox]

Congratulations on a thorough blog post. I am very interested in the growth and use cases of ontologies within ITSM.

It's not a glamorous or well understood discipline yet, but I do believe it is unavoidable. Some day soon, ITSM practioners are going to realise that they cannot do meaningful integration at the "knowledge base" level without common ontologies.

The CMDBf is working on standardising CIM. That is a great start. We co-orindated effort to create a process ontology with ITIL as a foundation.

I'm sure we'll get there, but not after much scratching of heads, gnashing of teeth and copious dollars poured into unproductive enterprise toolsets.

Good luck in 2008, one and all.