Prabhakar Mynampati, an Advisory Architect at IBM, published last week an article detailing 6 SOA Governance business processes. The article includes a BPMN-like process definitions for:
- Service identification
- Service creation
- Service testing
- Service versioning and change management
- Service management
- Service security
These scenarios were defined in response to potential challenges likely to be encountered in a SOA Development Lifecycle without SOA Governance:
- Struggling to identify new services and prioritize them.
- Significant issues with service creation and reuse, such as creation of redundant and inefficient services.
- Adoption test strategies and standards are haphazard.
- Governance of changes and versions for services are crude and unrefined
- No systematic way to enforce governance policies for service management, quality of service (QoS), and services security.
Prabhakar argues that a Service Identification process is required because:
There are a variety of project risks due to inconsistent approaches adopted in the identification of business and IT services. Services might be noninteroperable, and after the identification of services many of them might be redundant. There might also be a situation where there's no responsible owner of the identification and delivery of services. Ultimately, all these risks can result in increased project costs and the inability to meet delivery time.
He suggests using a Service Identification Process such as this one:
Similarly, a Service Creation process is required because:
Currently, an organization is suffering from the development and deployment of redundant and inefficient services built across different lines of horizontal and vertical domains without regard for other repositories. Some of the services are getting realized in an inconsistent way of recognizing system functions. The maintenance costs are increasing because multiple copies of similar or the same services are being maintained, and there's no control over such services, which halts further development.
In the case of Service Testing, Prabhakar sees:
situations where a variety of groups are using different tools and test strategies for testing their services. There's no uniform approach for using tools, plug-ins, and test strategies for realization of services in the organization. This is attributable to the fact that compliance tests among some of the services were developed in vertical units, and some issues were raised that business requirements aren't correctly met with realized IT services. Some units aren't able to meet integration and system-testing deadlines in the stringent project schedule. And few project teams have trouble handling change in business requirements to systematic realization of IT services. All these issues have brought challenges to governance in a testing scenario.
He argues the necessity of a Service Versioning and Change Management process when:
there's no authority in the organization to decide whether required changes in the business processes needed to be implemented in IT and whether that change should be implemented in an existing service or as a next-version release. There's no common body in the enterprise to study and know the impact of these changes with respect to other service consumers. And there's no authority to decide runtime policy for versioning of services. System nonavailability complaints from the customers are arising due to production disruption when changing service versions.
He also sees some critical SOA Governance activities in the Service Management process area:
In this service management scenario, you look at an organization that's facing difficulties in monitoring and managing the services that are exposed to different service consumers. ... The architecture and development team is not aware of the services and resources that need to be monitored based on service level agreements (SLAs). There's no uniform approach for adoption of management tooling that covers the end-to-end view of business application, and there's no uniform approach for providing detailed information about performance and availability metrics for individual resources.
Finally, he also sees problems when
an organization has no common strategy for attacking security threats and protecting services from external access. Multiple authentication and authorization of services are frustrating operators. There's no security policy management framework in place for adopting policies and tracking these policies from inception to implementation, and there's no responsible body for interacting and communicating with enterprise boundary organizations to maintain a common set of security standards. There are no agreed-upon security standards for interacting with other services and data, and no defined roles and responsibilities for policy administration.
SOA Governance requires to be very methodical when identifying, implementing, securing or managing services. Are you using similar processes in your organization? if not, have you experienced some of the issues that the author presented here? would you consider implementing some of these processes?