Many organizations are putting themselves at a deep disadvantage by continuing to manage and think of their service oriented architectures (SOA) as a singular product, instead of treating it as a collection of business-aligned IT services. This is important because the highly distributed nature and capabilities of SOA means that the tactics and policies used to govern SOA will differ--sometimes significantly-- from techniques that are more usually associated with monolithic and siloed legacy applications. Unfortunately, this flat-earth view is vastly more familiar to most IT managers throughout the business world, and thus good SOA governance remains less intuitive than many in the industry would have us believe. As with all popular technology paradigms--the devil runs rampant in the details; SOA is no exception. Fortunately, many companies have recently taken steps to mature their IT governance portfolio by officially adding SOA governance to the mix of existing methodologies and policies. Often this is done by the establishment of an SOA Center for Excellence (COE) that may be overseen by the enterprise’s Project Management Office (PMO).
When the industry speaks of alignment between IT and the business, SOA is always discussed as a primary means to achieve this elusive unification. However, changes to business processes are usually much too dynamic and fast-paced for IT to perpetually accommodate them on a timely basis. And although SOA helps bridge the alignment gap, creating better time-to-market support for all business segments, SOA scalability issues will be encountered almost immediately after initial the implementation of services. One of the biggest decisions that will drive a company’s SOA landscape will be deciding on the number supported interfaces that a service will be allowed. The catch here is that if business services are created too modular—too tightly coupled to one business segment or department—redundancy of process logic will inevitably occur and there will be many more services to manage in the overall SOA portfolio. Such a scenario goes against the spirit of SOA. Nonetheless, a more loosely coupled approach—where one service supports numerous business areas—could potentially create a quagmire of multiple versions of each service (in order to support different nuances of similar business processes) on an inter-department basis. For example, the sales and marketing departments may want to leverage and share the same financial forecasting service; however, they both will likely interact with the service in different ways; this will result in the service having multiple versions because differing service interfaces must be supported, depending on who will consume the service. Maintaining, supporting, iteratively regression testing, and continually making changes to a core service, could potentially damage any SOA return on investment and make IT managers yearn for the flat-earth days once again. While setting standards on the modularity and maximum number of supported interfaces on services will always involve tradeoffs, a consensus must be achieved by the Center for Excellence and the decisions must be codified by policy. The responsibility for achieving this consensus must fall on the shoulders of both business and IT managers—the consumers and providers (in a rough general sense) of enterprise services. Ultimately, many services will be driven by just one consumer, yet satisfy the needs of many diverse consumers. Designing a good service will be a mixed bounty: Many consumers will be lining up to use the wonderful new service, yet requesting that unique interfaces be maintained for them based on their divergent needs. Knowing how to strike a balance between desired levels of consumption and maintainable levels of consumption can be more art than science, much like other tradeoff-laden tasks such as database design or creating effective KPI’s for a performance dashboard.
Defining Services - The SOMA Way
The good news is that there is at least one robust and trusted modeling framework that will help SOA architects get their arms around the issues of service modularity and interface versioning. Foremost, IBM’s Service Oriented Modeling and Architecture (SOMA for short), continues to gain favor from both SOA industry insiders and large enterprises alike. The SOMA methodology is a flexible standards-based framework that offers broad (yet targeted) support of an enterprise’s tactical, and strategic business processes and goals. As with any worthwhile modeling framework, SOMA helps companies define their services logically as well as provide insight into how existing technical architecture can best support optimum operational continuity for a business’s required service components. In addition to helping organizations gain better visibility into their mission-critical processes, the businesses start to understand how to achieve better time-to-market with their services by managing modularity and versioning. IBM boldly states its SOMA value proposition: “A company no longer needs to guess at what services will add the greatest value — SOMA provides a systematic approach to building the an optimized roadmap to implementing a service-oriented architecture — leading to faster realization of business value — the leading requirement for IT investments today.1 SOMA’s analysis and design methods more or less extend traditional object-oriented analysis and design (OOAD) precepts while extending OOAD practices to address concepts that are more particular to SOA. What I like about SOMA is that it helps analysts and architects better address service modularity and granularity within a larger context, i.e. looking at services within the context of a non-linear supply chain and service delivery lifecycle. (Although supply chain logic is usually thought of as being linear in nature, it is important to understand that services components don’t always fit neatly into such a linear and ordered value chain, due in part to the distributed nature of each service’s provider, consumer, and broker.)
Despite the beneficial machinations of SOMA, there will still be many subjective decisions available to the SOA architect. Consequently, many would argue that there is still no hard and fast rule on limiting the number of versions that a service interface should support in production—it all depends: Some services will be more prone to change than others: One consumer may be functioning quite nicely with highly optimized business processes that resist change while another business area will be exposed to monthly compliance mandates that will effect how they need to use a service. If business better alignment to IT and normalized and non-redundant business logic are promised blessings of SOA, change management (CM) may well be an inevitable curse, as some services will become obsolete and brittle by the time they are put into production.
Inevitably multiple versions of a service will be deployed in production simultaneously. And thus, IT departments need to have an elegant and standardized way to govern and manage the universe of routing requests for each different consumer of a specific service and all its supported versions, regardless of whether the version needed is hard-wired into the service request (i.e. specified as part of the service request by the consumer) or enforced by another means at run time via a service contract which will dynamically associate and match the correct version of a service with its proper consumer. Service contracts are vital in capturing and formalizing the relationships between a service and its consumers, establishing which service interfaces will be associated to which consumer and the preferred method of service invocation. Thus, issues of access control and security (so important to a highly distributed platform such as SOA) will inevitably have to be addressed by service contracts as well. It will be very important that the method for inferring and checking the identities and credentials of a requestor will be clean, consistent, secure, and quick. Analyzing message payloads associated with a service call to see if the service can be invoked or consumed by the requestor can become a troublesome performance bottleneck and negatively affect throughput in the service architecture. Therefore, it is vital that special attention is paid to this area and that exceptions are raised, logged, routed, and addressed at the speed of light. One common problem encountered in SOA exception management is that service providers and service consumers often store their error logs in different locations (not surprising given that a service may interact with a multitude of applications across business boundaries.) However, when service providers and consumers record exception and error activity in separate and non-centralized locations, it becomes more tedious and costly to remediate problems with service access control, code bugs, network outages, and beyond. As one would guess, the biggest issue such non-centralized exception management is that information about run-time errors in the SOA will wind up existing in different formats or schemas with different meta data and semantics that describe errors from both a system and business perspective or lexicon. Defining an XML schema to be used enterprise-wide for service exception management and logging is something that should be budgeted for by IT directors early in the SOA implementation and adoption process. This schema will be supported with meta-data that describes the location, nature, type, severity, and other pertinent information about exceptions so that maximum traceability can be achieved seamlessly by all interested parties. It is important that errors are reported back the consumers of a service in a way that makes sense.