SOA: Bridging the Divide Within IT
By Ronald Schmelzer
We often refer to information technology (IT) as if it were one cohesive department within the enterprise. However, for most businesses, IT really consists of at least three separate organizations each with their own technologies, best practices, approaches, and terminology: the systems and network people, the application development and integration team, and the data storage and information management group. It should come as no surprise that this siloed approach to organizing IT leads to inflexibility, and limits IT’s ability to meet the changing needs of business.
For people who construe Service-Oriented Architecture (SOA) narrowly as applied directly to the application development and integration arena, SOA would be of little help in addressing these broader issues of siloed IT organizations. However, to be most compelling to the organization, SOA should apply to all groups within the IT department. It is important, therefore, to explore how to apply the principles of Service Orientation to the various groups within IT using the language specific to each.
SOA and the IT Infrastructure Library (ITIL)
The mantle for well-conceived and executed architectural practices might actually go to the operations part of the IT organization. The most widely accepted source for IT Service Management (ITSM) best practices is the IT Infrastructure Library, known as ITIL®. Developed by the United Kingdom's Central Computer and Telecommunications Agency (CCTA) in the late 1980’s, ITIL has rapidly become the de facto standard for managing the most important services that IT provides the rest of the organization. ITIL has become a godsend to companies looking to improve the quality and cost-effectiveness of their IT operations by providing well-documented processes, procedures, and approaches for dealing with the most common business needs of IT. Now managed by the UK Office of Government Commerce (OGC), ITIL consists of a set of documents and a customizable framework of best practices for ITSM.
The ITSM context for “services” that ITIL applies to are processes and functions that provide IT service support (including configuration management, change and release management, incident and problem management, and service desk), facilitate IT service delivery (including management of service levels, capacity, financials, availability, and overall IT continuity), and provides other operational guidance (security management, application and software asset management, infrastructure, and general business imperatives). What has made ITIL popular is that the specifications meet the needs of a very broad constituency. Enterprises utilize ITIL to organize their large, heterogeneous, and often chaotic IT systems, while small organizations use ITIL as a way of instilling best practices without having to reinvent the wheel or make mistakes too early in their company’s development. Another key to ITIL’s success is that it is adaptable to the particularities and differences among ent erprises and doesn’t attempt to establish a single mechanism for any of the services it attempts to standardize.
As ZapThink explored in our Subtleties of Service Convergence ZapFlash, the ITSM context for “service” is converging with the SOA context for “Service.” As ITIL-focused services become composable, loosely-coupled Services as part of a SOA implementation, ITIL should instill best practices for managing each of these IT service support and delivery functions. In other words, SOA can learn a lot from ITIL, and vice-versa. After all, ITIL espouses that an organization should move from a technical focus to a service focus. As companies implement SOA, services developed under ITIL should be able to be represented in a Service-oriented manner, leveraging the abstraction, loose-coupling, and composability capabilities of SOA for meeting ITIL needs. In fact, if it’s not possible to apply SOA to ITIL, then we face an impasse – the fact that SOA will be relegated to solving only some of the needs of business.
Furthermore, architects looking to implement SOA can also learn from ITIL. ITIL defines a set of artifacts, processes, and documents that help to describe, define, and detail various IT processes, but in an abstract way. In other words, ITIL doesn’t provide the specifics for how to implement those processes. After all, ITIL is not a methodology, but rather a framework for specifying process details. It should be possible to borrow some of the artifacts and documents created for ITIL and repurpose them to meet SOA-specific needs for specifying a range of business processes in an implementation-independent manner.
In particular, one of the elements of ITIL’s success is its use of common vocabulary, consisting of a glossary of well-defined and widely agreed upon terms. Another key element is the idea of the Continuous Service Improvement Programme (CISP), which takes an iterative approach to meeting changing business requirements and IT capabilities. Proponents of SOA would be well-advised to take under consideration these same ideas in order to strengthen the overall value and depth of their SOA implementations. In addition, any linkages in vocabulary or process to the way in which ITIL proponents see the world can only serve to improve the overall state of enterprise architecture in the company by unifying the disparate and complementary views of how IT should meet the needs of business.
SOA and the Masters of Data
To the people who manage databases, support data warehouses, integrate information, and perform semantic modeling, the business is the data, and the various systems and networks that operate on data are simply tools for manipulating business information. Dealing with data heterogeneity and meaning is just as challenging, if not moreso, than dealing with the integration of heterogeneous systems and networks. In order for any composite application to be a reality, the interacting systems must be able to understand the data that underlie critical business information. In this regard, what is most important to the data specialists are the data and information models that identify how information propagates through the enterprise and how systems can extract meaning from data.
To solve these data-specific issues, the data masters in the IT organization craft their own approaches, methodologies, and vocabularies. The data warehousing field spawned many of these efforts, as did various efforts to reach the nirvana of semantic integration in which disparate systems with no a priori knowledge of each other could still understand data passed between them. A number of major data-focused IT initiatives have evolved over the years to deal with disparate data in the enterprise ranging from the Common Information Model to efforts around the Semantic Web and The Open Group's ISO 11179/UDEF (Universal Data Element Framework).
Just as it makes little sense to consider ITIL as covering aspects of business and IT outside the scope of SOA, it also makes little sense to consider data and information outside the bounds of Service Orientation either. After all, SOA is enterprise architecture, and as such, provides a broad umbrella that includes approaches to addressing semantic issues. As a result, semantic integration is where the conversation begins with the data-centric IT folks. Rather than isolating them as a separate group, Service contract design and composite application development must happen as a collaborative effort with both the application development as well as the data/information team. Stronger inclusion of semantic and data awareness would considerably strengthen SOA efforts, and vice-versa. Furthermore, the use of and exposure to Services in the enterprise would significantly improve data integration efforts.
The ZapThink Take
In a Service-oriented enterprise, there’s no reason to keep the different disciplines of IT separate any longer. IT service, network, and systems management can be involved in the SOA conversation every much as the application developers and data masters. Indeed, SOA actually enables the business to bring together these domains with a single cohesive approach for the first time. A true enterprise SOA will have an IT resource and data perspective on Services, and a Service perspective on IT resources and data. For this vision of convergence to be successful, however, each side will need to work with the other – and working with people in different groups is one of the greatest challenges of SOA today.
Comments