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).
Modularity
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.
Exception Management
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.
Release Schedules
Service contracts may often go beyond policing the invocation methods and the rules that govern the service requests. They may also establish the guidelines for how and when a service is updated or decommissioned. This will be driven by and depend heavily on the capabilities of IT. For instance, it may be feasible that a service release is a three to four month ordeal once development, regression testing, and QA testing are taken into account. The maturity and capability of IT to respond to a request to change the functionality or interface of a service will also depend on the nature of the change request itself. Thus, even attempting to craft a standard release schedule for services in your SOA may serve as an exercise in futility. The bottom line is that it is difficult to postulate on how prone a given service consumer may be to making change requests. Murphy’s Law tells us that even the most undemanding of consumers will fall victim to a corporate merger or last minute regulatory legislation and have IT scrambling to “open the hood” on their services for quick tune-ups. Ultimately, a mixture of business market considerations (business rate of change) and the capability of IT will both have to be taken into consideration when devising a service release schedule for a company’s SOA. Eventually though, the whole agility and nimbleness of IT will come under fire—as it always does—from hungry service consumers starving for more changes to “their” services; the more consumers that a service has, the more this agility problem will be compounded. For this reason, some IT departments find that it makes their lives (and SOA governance and CM) easier to set a maximum number of interfaces for a service, rather than try to hold the service’s consumers captive to a release schedule that may or may not be rooted in reality. The realities of the business world are simple: If producers do not respond quickly enough to consumer demand, consumers will go elsewhere for their product. In the case of SOA, dreaded rogue services may start appearing, making time-to-market and governance issues even worse! Spending one’s time trying to seek out and discover rogue services hiding in the infrastructure will leave one with little time to develop, release, and maintain viable new services. In the end, IT must learn how to walk a fine line between the capabilities of the provider and the critical needs of the consumer. These goals may be conflicting at first glance, and political power struggles are not out of the question: Consumers will start to critically question the investment in SOA if they can not get what they want in a timely manner.
Decommissioning
Almost as vexing as the subject of service release schedules, is coming up with an effective plan on how to retire and decommission services—to pull them out of production with the smallest footprint possible. Some organizations will conduct a yearly audit on their SOA to determine usage patterns, while others will collect information on moribund services (from the SOA monitoring tool/dashboard) on a tighter schedule. Once retireable services have been selected, it is always good to have a discussion with the business consumers to find out why the service is not being used. Sometimes a shift away from a service means a shift to an undocumented rogue service; so a service decommissioning exercise can conveniently provide the fuel for a side-mission to discover rogue services. We can learn much about our SOA by going through the process of taking services out of production and having their consumers explain why they were ill-served by them. In this way, it is important to think of the effort to manage services in terms of supply chain management and product lifecycles. But as mentioned previously, unlike some common consumer products, service lifecycles will not necessarily be linear—with a clear beginning and end—due to the support of multiple interfaces and consumers.
Security
Because SOA makes an organization exponentially more distributed--business process logic and software resources can be quickly implemented shared all over the world in a fashion that was all but unthinkable a few years ago—the security risks that come with SOA are severely heightened. We now have a web of distributed consumers, providers, brokers, partners; each of these entities could unknowingly expose any of the other parties to a multitude of security threats that originate on their own local turf. Because every consumer and provider of service could bring a potential security threat to the table, the tangle of run time credential checks and verifications can get complicated and unwieldy. Currently, there have emerged a handful of accepted standards that tackle various components of SOA security. Some of the more popular standards that address web service based implementations of SOA are WS-Security, and SAMLWS-Trust. Like most mechanisms that enable security, each will have performance impacts that must be carefully studied and understood. Network calls made to authenticate and retrieve consumer credentials, and obtain other run-time policy/governance information have an effect on bandwidth (which still remains far too variable for some companies that are ambitiously forging ahead with their brave new world of SOA) well as system performance. Thus, SOA architects and managers must be overly cautious and conscious of decisions around SOA security, not just to better manage security risk, but because of potential performance degradation issues that come into play around the securitization of business logic assets. (Too much security thrown at SOA could breed a reactionary counter-culture where certain groups splinter away from the SOA agenda and start to manufacture rouge services that are undocumented and poorly supported.) What is comforting is that the newest breed of SOA governance dashboards currently coming to market are going beyond their predecessors in terms of performance measuring functionality, providing a better means to troubleshoot and improve the space where security and performance intersect. These dashboards are able monitor, report on, and mange enterprise services through a consolidated console that can connect-the-dots between governance and system/SOA efficiency.
In this article, I have touched on several topics in-depth topics related to SOA best practices and SOA governance. Because many aspects of SOA governance involve real-life tradeoffs in performance, agility, and change management, it is of utmost important that a written SOA best practices and governance policy be crafted and set in stone by corporate policy makers (i.e. the Center for Excellence) after reaching a consensus on these and similar issues. Policy will not only drive current architecture, it should also drive the evolution of future SOA best practices, moving everybody forward together, with a minimum of level of ambiguity.
1 IBM SOMA Press Release - Armonk, NY, USA. January 26, 2005
About the Author
A Contributing Editor for Dashboard Insight, William Laurent is one of the world's leading experts in information strategy and governance. For more than 15 years, he has advised numerous companies and governments on technology strategy, methodologies, and best practices. He is a regularly featured writer and columnist for DM Review where he writes about IT and corporate governance. William currently serves on the faculty of Baruch College, runs an independent consulting company that bears his name, and lectures frequently on various technology and business topics worldwide. He would enjoy your comments at wlaurent@williamlaurent.com
(Copyright 2008 - Dashboard Insight - All rights reserved.)