The relationship between IT Service Management and Service Oriented Architecture keeps bubbling up to the surface. It is a gold mine of confusion for senior IT executives, whose infrastructure and engineering leadership is talking to them about "Service Management" while their enterprise architecture braintrust goes on about "Business Services" and related SOA terminology.
You can do this Google search and find various platitudes that "if you are good with ITSM that will help you with SOA" and similar non-provable generalities. Serge Thorn has written some better stuff. It's notable to me that both ITSM skeptics and SOA skeptics (e.g. Rocky Lhotka, Jeremy Miller) have emerged.
Regardless of the overloading of that hapless word "Service," the distinct history behind the two usages is relatively clear. The genesis of ITSM is found in the success of the ITIL Service Support and Service Delivery volumes, two volumes that have had a primarily operational audience and interpretation. (Notice that I do not say they are operational in intent - it is clear the authors had more in mind.) Think large British mainframe service bureau, circa 1992.
SOA, on the other hand, is rooted in the history of software development, with origins traceable to re-usable transactions in mainframe environments, and an entire subsequent history involving developments such as the emergence of object orientation, component based development (e.g. CORBA and COM/DCOM), and the standardization of the IETF specs and the realization that a URL could be seen as simply a (slightly clunky) function call.
But, inevitably due to the common term "service," the question keeps coming up: what is the relationship? Distinct origins do not imply a distinct destiny. So, where are the two today? Can we discern any commonalities, or intractable clashes?
Those of you who follow my work may have seen the conceptual IT data model I've proposed both here and in my book. In attempting to standardize terminology, I was faced with the question of whether an ITSM "service" might in fact be identical to an SOA "service." As usual, it all depends.
The definition of exactly what constitutes an ITSM "service" is still unclear. There has been a fair amount of interest in service catalogs and such, but the examples are still very inconsistent. ITIL v2's example of a Service Catalog is primarily an application portfolio, with examples such as Payroll System and Customer Database. (Internet and Intranet are also included.) Clearly, monolithic "applications" at this level run counter to much of the SOA thinking, in which finer grained "services" are emphasized, and the larger grained applications are seen as legacy.
On the SOA side, there is a line of argument that emphasizes that SOA must not be confused with Web services or any particular technical implementation; instead, it is an overall architectural "style" emphasizing loose coupling, interoperability, platform independence, and business motivation traceability.
The last requirement in particular leads to an interest in defining what the large grained business "services" are that might be enabled through SOA type automation. I recently attended a talk by Proact's Art Caston and he suggested that the end game here was what he calls the "service function" analysis of the business's operating model - essentially, IDEF0 analysis, resulting in approximately 150-200 discrete business services for the typical large enterprise.
Interestingly, when Troy DuMoulin and I debated the question of service granularity and naming recently, the granularity Troy suggested was the same. Troy makes a strong case that the best concept of "IT Service" is larger grained than the "Application" concept. His definition is interesting:
- A service always refers to a capability and not a specific technology
- A service does not make reference to an organizational function, department or structure.
- A service is supported by one or many systems.
Now, these principles are similar to those used by Art Caston in his modeling approach - a most interesting convergence!
I am beginning to reach the conclusion that indeed, SOA "services" and ITSM "services" can and should be considered identical, with a granularity of between 150-200 for the typical large enterprise. Applications are too fine grained, and individual service components even more so.
Problems will emerge in the issue of organizational coupling; it is all well and good for ITSM theorists and architects to desire that services are "organization independent." But this I think is a bit misguided. One of the reasons we decompose these things is for manageability.
Some relevant quotes from my book:
If IT functionality is increasingly to be implemented via choreographies of encapsulated services, how can these be managed? The key here is to realize that the application concept again is subjective. It is simply a management framework of a certain granularity imposed upon a complex reality in order to make sense of it. Whether the underlying technical reality is COBOL with CICS, C++ with CORBA, or BPM choreographies of Web Services is not really relevant – there is a certain level of granularity, continuity, and sunk cost that will remain a sweet spot for management attention, and the need for financial accountability will continue to play a big part in driving this.
SOA and Change and Configuration Management
At a more detailed level, SOA certainly proposes challenges for ITSM practice as it is beginning to solidify especially in the areas of change and config. Consider infinitely recomposable, dynamic choreographies mutating from day to day in various value network configurations. How do we assess change risk if service dependencies become as transient as envisioned? Today, the value chain is A calls B calls C. Tomorrow, it is A calls D calls E, automatically re-configured with little or no human intervention, let alone a Change Advisory Board. How can service providers even notify their consumers in the event of an outage? (My design pattern solution for this is that the service consumer owns the dependency.)
Maintaining such dynamic dependencies challenges the CMDB concept at a philosophical level. Does every potential interaction in an SOA environment constitute a dependency to manage? Or only those that have been exercised?
I could say much more but it's late. Thoughts?
Charlie
