Despite increased adoption, many of the SOA projects are still failing. Things are often getting so bad - there was a recent article with a catchy name SOA or DOA, where DOA stands for "Dead on Arrival". One of the ways to improve this situation is proper proper SOA governance
Rescent Muhammed Yaseen Muriankara’ article - SOA governance framework and solution architecture defines 3 basic level of governance. Enterprise governance is
establishing chains of responsibility, authority, and communication to empower people and establishing measurement, policy and control mechanisms to enable people to carry out their roles and responsibilities
The subset of the enterprise governance is IT governance
aspects of governance that pertain to an organization's information technology processes and the way those processes support the goals of the business
Finally SOA governance is defined as
a specialization of IT governance that puts key IT governance decisions within the context of the life cycle of service components, services, and business processes. It is the effective management of this life cycle that is the key goal to SOA governance
The article presents methodology and model for adopting SOA governance from IBM which is called the SOA Governance and Management Method (SGMM). The methodology documented using IBM Rational® Method Composer and is available for download.
. SGMM is build around service lifecycle and covers the following:
Service definition
The most fundamental aspect of SOA governance is overseeing the creation of services. Services must be identified, their functionality described, their behavior scoped, and their interfaces designed.
Service testing
SOA increases the opportunity to test functionality in isolation and increases the expectation that it works as intended. However, SOA also introduces the opportunity to retest the same functionality repeatedly by each new consumer who doesn't necessarily trust that the services it uses are consistently working properly. Meanwhile, because composite applications share services, a single buggy service can adversely affect a range of seemingly unrelated applications, magnifying the consequences of those programming mistakes.
Service deployment life cycle
Services don't come into being instantaneously and then exist forever. Like any software, they need to be planned, designed, implemented, deployed, maintained, and ultimately, decommissioned. The application life cycle can be public and affect many parts of an organization, but a service's life cycle can have even greater impact because multiple applications can depend on a single service.
Service versioning
Service versioning enables users satisfied with an existing service to continue using it unchanged yet allows the service to evolve to meet the needs of users with new requirements. The current service interface and behavior is preserved as one version, while the newer service is introduced as another version.
Service ownership
An SOA should reflect its business. Usually this means changing the SOA to fit the business, but in some cases, it may be necessary to change the business to match the SOA. When this is not possible, increased levels of cooperation are needed between multiple departments to share the burden of developing common services. This cooperation can be achieved by a cross-organizational standing committee that, in effect, owns the services and manages them.
Service security
SOA creates services that are easily reusable, even by consumers who ought not to reuse them. Even among authorized users, not all users should have access to all data the service has access to. Some consumers of a service have greater needs than other consumers of the same service for data confidentiality, integrity, and nonrepudiation.
Service monitoring
A composite application, one that combines multiple services, is only as reliable as the services it depends on. Since multiple composite applications can share a service, a single service failure can affect many applications. SLAs must be defined to describe the reliability and performance consumers can depend on. Service providers must be monitored to ensure that they're meeting their defined SLAs.
An article describes not only a methodology for SOA governance, but also a set of tools (Governance platform), allowing to support and automate, at least partially, many of the governance processes.
Some of the minimum required automation capabilities for a startup project include:
- A centralized registry and repository to find and publish the service related artifacts and metadata. This is necessary to:
- Find the right authorized service.
- Avoid duplication of effort.
- Encourage reuse.
- Identify the current state of service in the SOA life cycle.
- Provide visibility to subscribers of the services.
- Find related services and the impact of changing a service.
- Communicate changes done to the service.
- A mechanism to relate and enforce policies applicable for a service. The policies are defined by using the governance framework.
- A customizable life cycle-aware system that triggers validations on the change of phase within the life cycle so that phase-by-phase governance validations can be automated.
- The registry should ideally be SOA run time optimized so that the metadata stored in the registry can be used to provide enrichment via dynamic routing during run time.
The article itself and a list of references are a good read for everyone involved in SOA implementation and more specifically in the SOA governance.
