In his recent post David Linthicum has defined two major types of SOA governance:
There are two types of service governance technologies: runtime, or the ability to enforce service policies during execution, and design time, or technology supporting the design and implementation of service policies. Policies are placed around services to control who can access those services and what they can do with them.
In Dave’s opinion cloud technology, which is quickly becoming the most popular trend for many enterprises, will effectively kill design-time SOA governance in favor of run-time governance:
... the focus on runtime service execution provides much more value. Many of the existing runtime SOA governance players support enough design and implementation capabilities that separate design-time tools are not required. Cloud computing is simply accelerating the focus on the requirement for runtime SOA governance, and sooner or later design time will fall by the wayside.
Dave’s opinion is shared by K. Scott Morrison, who notes that:
In the big SOA era (before Jan 1, 2009), design-time governance was king. It fit nicely into the plan-manage-control discipline underpinning a large enterprise-scale SOA effort... Run time services governance, in contrast, was often perceived as something you could ignore until later... The cloud inverts this priority. If you deploy even one service into the public cloud, you must have runtime service governance in place.
In his opinion, design-time governance will not disappear completely, but it will be useful only as the size of SOA implementation grows (compare to my recent post ):
In the end, governance priorities in the cloud come down to a pretty simple precept: Duplicating a piece of functionality probably won’t get you fired; leaving an open door that was used to compromise corporate data probably will.
William Vambenepe takes this discussion further by defining a SOA++ model (service-centric approach to IT management), unifying frameworks, APIs, models, protocols, tools:
- the IT resources... can all be thought of as services being consumed (an "X86+ethernet emulation" service exposed by the hypervisor, a "JEE-compatible platform" service exposed by the application server, an "RDB service" expose by the database, a Web services exposed via SOAP or XML/JSON over HTTP, etc.),
- they can also be set up as services, by simply sending a request to the API of the service provider,
- not only can they be set up as services, they are also invoked as such, via well-documented (and often standard) interfaces,
- they can also all be managed in a similar service-centric way, via performance metrics, SLAs, policies, etc,
- your orchestration code may have to deal with all three categories, (e.g. an application slowdown might be addressed either by modifying its application dependencies, reconfiguring its infrastructure or initiating a new deployment),
- the relationships in all these categories now have the potential to cross organization boundaries and involve external providers, possibly with usage-based billing,
- as a result of all this, your IT automation system really needs a simple, consistent, standard way to handle all these relationships. Automation works best when you’ve simplified and standardize the environment to which it is applied.
In this model services/containers support well-defined operational contracts with the quality requirements defined through policies and SLA. As a result, they require a management framework, monitoring these policies and SLAs, a common security infrastructure, metering/billing framework, etc.- a full blown SOA runtime governance.
It is great that closer alliance between SOA and cloud computing is illuminating the importance of run-time SOA governance, but doing this at the expense of design-time governance does not seem right. At the end of the day, SOA’s promise is still to align business and IT, which is not possible without designing services based on the decomposition driven by an enterprise business model. This means that design-time governance is still a centerpiece of any true SOA implementation. The argument should not be which SOA governance is more important, but rather on how to implement both of them correctly.