IT World Canada is pleased to offer research from Meta Group Inc. This content will be featured on ITWorldCanada.com for three months from the article’s publication date.
Service-oriented architecture (SOA) is a concept that nearly every organization is striving for. However, the path toward an SOA is often unclear, and the promises of that architecture can seem very far off. However, it is possible to progress toward an SOA incrementally and the benefit from that progression that is in line with the additional skills, costs, and efforts that new technologies and architectures require.
META Trend: By 2005, a new set of meta-architectural principles, currently referred to as “service-oriented architecture” (SOA), will be broadly diffused throughout the IT environment in the form of service-oriented business architecture, service-oriented security architecture, service-oriented management architecture, etc. By 2006, SOA will be widely understood and treated as a metadata (or model) interoperability architecture, given its emphasis on interoperable identifiers (namespace metadata), formats (information models), and protocols (process models). By 2007, composite applications will be based on the SOA principles of dynamic, extensible, federated interoperability and enabled by XML-based technologies such as Web services.
SOA is a significant shift in the way organizations will design business systems and the applications that support them. This shift will affect not only the applications, but also the roles and the responsibilities of the firm and the various tools and techniques that are used to build them. The changes associated with service orientation can seem daunting, and the vision of the future (highly adaptable services connected via an easily changed model that parallels the business process and that can be related to it in a manner that is meaningful to a business user) seems well beyond what existing systems and organizations are capable of. Many vendors and publications will talk about the end vision in a manner that makes it difficult for a typical firm to plan a road map.
However, many firms have planned the road map and are indeed progressing toward an SOA. Although not all organizations did exactly the same things to begin this progression, such firms have numerous common activities on that road map. Such activities are all well within reach of the typical corporate IT organization and will deliver significant benefits almost immediately. Although none of these steps is truly a service-oriented scenario, most of the following will deliver some of the benefits of service orientation:
Organizations must begin creating services and using models-based development techniques: One of the significant attractive features of an SOA is that it holds out the promise of creating applications and systems using models. Because services can be completely described by their metadata (in theory at the moment, but becoming more practical all the time), one should be able to construct a system by linking together the invocation of services in a defined sequence. Of course, the sequence itself (and any attendant logic that goes along with it) can be described in metadata as well. (Pi calculus has given us a good foundation for how to construct the basic series of reference actions that are needed to describe sequencing.) The act of creating metadata to sequence the invocation of services is known as “composition.” (The terms “orchestration” and “choreography” are also sometimes used.) This composite is often thought of in terms of a model (e.g., the model is the visualization of the sequence metadata). Therefore, composition (building composite applications) is often associated with the business process modeling capability of a tool or a system (see Delta 2838). The models that are used to create this metadata are business process models, in the sense that they represent sequences and decisions about what to implement, when, and for whom. Business process execution language is the standard by which such models can be made interoperable with each other.
Using business process modeling and the tools that can make such models into executables is a good start for an SOA. The parts of the system that are represented by such models will be relatively easy to construct and simple to modify compared to (usually code-based) alternatives. However, it is unreasonable to expect that most existing systems and applications have exposed services at the correct level of granularity to be composed in this fashion. In early implementations, this limits the use of the business process-based system to newly constructed applications, integrations between various applications, and human-based processes that currently have only limited automation. Business process modeling of this type has not reached a level of sophistication where it can substitute for code to describe many of the interactions between components and services.
Firms must build standards for common business reference objects, patterns for service, and system designs: The most common project to build a business-level service is the creation of services around common business reference objects for the organization. What such objects are will depend on the organizational alignment and the industry. However, in almost every case, there is agreement about the aspects of such objects for customers and products. Basic objects are part of nearly every process within the organization, and thus have some representation in nearly every system that the organization uses. Creating a set of common definitions of basic objects (nouns) and a set of well-defined services (verbs) that identify their use enables the organization to tolerate the distributed implementations of the actual objects and to compensate for their inconsistent implementation. The model that should be used is one that draws on federated data principles. This should be a generic data model that can be enhanced by individual groups for their particular purposes, but in a way that maintains minimal consistency across the elements. This is not a simple process, but one that takes place naturally as the result of many integration projects and that can be done incrementally. The technology to create such services, though non-trivial, is often not overly complex. The bigger issue of generally creating the process by which the organization reaches some agreement about what such objects are and what they mean is by far the bigger task (see ADS Delta 1245).
Organizations must focus on integration that uses standards-based mechanisms: In addition to building basic reference objects, there must be an infrastructure present that enables the use of such services in any application environment. This infrastructure should be based on current Web services standards so that future upgrades of the technology can be streamlined. It should be noted that standards-based does not mean the same thing as “open source” or “free.” Most organizations will purchase implementations of standards-based integration from a vendor of integration products.
Firms must use appropriate standards to reduce technology dependencies: Along with standards-based integration mechanisms, users should exploit all other standards as they find them. For integration mechanisms, users can isolate from the specific transport by utilizing SOAP messaging and binding it to the transport of choice. This will ensure that coding considerations are minimally impacted by any change in transport infrastructure. Similarly, users can simplify the coding of the various components that must know the contents of the header or message by using XML messages. Messages should be composed from existing public standards or from internal standards for the representation of information.
Organizations must work toward an interoperable middleware platform: The goal of all this is to end up with a consistent set of services that is exposed using a set of technologies and accessed using a diverse set of tools and frameworks. In most organizations, this will take some time to achieve. However, as organizations plan their application deployments, they should be working toward reducing the number of middleware components involved in the architecture. Combinations of capabilities that have been proven to work for similar applications, or pre-integrated sets of capabilities from vendors, should be sought out. In many cases, there will be corporate standards for such capabilities (e.g., application servers, integration servers, portal frameworks). Sets of technologies should be defined and used as a corporate platform for future system development. There is likely to be some degree of variation around this platform, because different types of applications may need different capabilities (i.e., some applications may not use a content management capability or an Internet commerce capability). However, having a strategic direction and governance over this platform will enable the organization to create more highly leveraged skills and more reusable patterns, components, and services.
Bottom Line: To begin the journey toward SOA and to gain some of the benefits of that architecture, organizations must begin creating services and using model-based development techniques. They must build standards for common business reference objects and patterns for service and system design. Organizations must focus on integration that uses standards-based mechanisms, exploit appropriate standards to reduce technology dependencies, and work toward an interoperable middleware platform.
Business Impact: Small steps on the road to an SOA can create direct benefits for the organization.
Copyright
