Part of the SOA Governance@Work series
Conventional wisdom holds that there is a lot of confusion about SOA. I cana??t understand why -- I googled a??What is SOA?a?? and found more than 27,000 definitions. I also googled a??What is truth?a?? and found 333,000 definitions, which puts the whole SOA thing into perspective.
But leta??s ignore, for a moment, the definition of what SOA is to look at what SOA is supposed to do. After all, this series of posts is dedicated to an examination of SOA governance, and governance is all about making things happen the way they are supposed to happen.
Achieving the A-words
At the highest level, SOA is supposed to deliver the two big A-words: Agility and Alignment. At a nuts-and-bolts level, SOA achieves those goals by replacing rigid, monolithic applications and multiple instances of redundant, static software assets with a consolidated matrix of dynamic, reusable services. These services can be shared across the enterprise, and assembled and re-assembled into a variety of applications, in much the same way my little brother used to switch the heads on his G.I. Joes. Thata??s the big picture, anyway.
But simply having an SOA doesn't guarantee that you'll achieve the A-words. You need effective SOA governance to make that happen, and policies are the nuts-and-bolts of governance. In this installment of SOA Governance @ Work we'll take a high-level look at how policies relate to various aspects of SOA.
Basic Ingredients
If we boil away everything but the most basic ingredient of a successful SOA, wea??re left with one thing: an inventory of accessible, reusable services. A service-oriented architecture without services is worth exactly zip. Your service inventory must include at least one service before your SOA can start doing what ita??s supposed to do. It's important to remember that any single service is comprised of and/or related to a variety of other software assets in your inventory. The success of an SOA is tied directly to the accessibility and reusability of the services and other assets in the inventory. Access and reuse certainly arena??t the only success criteria, but their importance is equal to that of a parachute when skydiving.
A Question of Access
Access is a straightforward issue: a service or any other software asset is of little value if no one can get to it to use it. (Visibility , the subject of the previous post in this series, is an important aspect of accessibility.) The appropriate SOA governance policies must be created and enforced, and the right tools put in place, to both guarantee and control service access.
But insuring and managing accessibility alone is no guarantee that your SOA will one day make you famous, or at least more popular. Easy access to unusable services is like a pass to an all-you-can eat buffet stocked with rotting food.
The Right Stuff
In SOA, usability is synonymous with reusability, which itself is one of the defining characteristics of a service. The motivation for service-enabling some chunk of functionality is to allow it to be consumed by any application that requires it. Thata??s part of the equation for the big SOA payoff -- one service, shared by multiple applications, multiplied by the number of services in the inventory.
Reusability, therefore, is something else that SOA governance must enforce. That means creating and applying the policies necessary to insure that the right services are developed the right way at the right time -- using, whenever possible, other software assets available in the inventory. Therea??s no reason, for instance, to develop a service no one needs, just as therea??s every reason to avoid developing a service that duplicates the functionality of one already in production.
Performance Anxiety
But governance over reusability must also extend to service performance in the operational environment. A service that cana??t live up to its performance requirements, or otherwise behaves like a binge-drinking frat boy, is unlikely to get reused, and should be put on double-secret probation, if not expelled.
SOA governance must include the means to monitor, measure, and report on service performance in order to insure service quality. Governance policies covering service performance will help to keep mobs of angry, torch-bearing service consumers from your door, and will help to insure that the inventory includes only those services that are up to the task.
Use it or lose it
While service reusability is vitally important, it cana??t insure reuse. Even the most accessible, reusable services may end up collecting dust simply because no SOA governance policies are in place to make sure that reusable stuff gets reused.
If an SOA without services is worthless (not to mention pointless), an SOA with services that arena??t being used is a highly effective cash incinerator. So the policies that represent the application of governance to your SOA must accomplish at least two objectives:
- Insure that the organization has services to use
- Insure that the organization uses the services it has.
Little Pieces - Big Picture
Those admittedly broad, wildly generalized objectives cover a sashimi-thin slice of the overall SOA governance picture, but they are important. That doesna??t mean that any service is better than no service, just as it doesna??t mean that any service use is better than none. But if youa??re going to do SOA, you need to achieve at least those two objectives.
If you do, it wona??t matter which one of the 27, 000 definitions of SOA you choose to accept as true -- youa??ll still come out ahead. But if you fail to meet those objectives, if you dona??t define, apply, and enforce the necessary governance policies, your SOA is likely to pull a Britney.
In upcoming posts in this series wea??ll take a look at policy tooling, and dig deeper into the creation, application, management, federation, and enforcement of SOA governance policies.
Other posts in the SOA Governance@Work series:
