Service Lifecycle
A service lifecycle comprises activities right from service identification through service operation. Various design-time and runtime policies need to be defined around these lifecycle processes.

The primary objective of design-time policies would be to ensure that truly reusable and interoperable business services are being developed.

Reusability - Identifying which business functionalities are the right candidates for service enablement is a difficult task. Without a proper approach to service identification, project groups will end up identifying services that don't have enough reuse potential. The policy related to the service identification process should enforce the use of a business process-centric, top-down/bottom-up analysis approach to identify genuine reusable functionalities.

Interoperability - Interoperability policies should focus on building technically and semantically interoperable business services. For example, as a part of the Service Interface Spec/Design process, a high-level policy for semantic interoperability can be defined to enforce the adherence of the business service interface to the enterprise-wide canonical format. This can be followed by more specific policies aligned to domains or functional areas. Similarly on the technology interoperability front, policy can be defined to enforce compliance with the WS-I basic profile to achieve Web Service interoperability across platforms, operating systems, and programming languages.

Runtime policies should be defined and enforced to govern the behavior of a service once it's operational. For example, a runtime policy for SLA monitoring and non-compliance reporting should be defined and enforced with the intention of getting visibility into the compliance issues and subsequently taking remedial action either in an automated or manual way (automatically instantiating an additional instance of service in case of performance degradation is an example of automated remedial action).

Examples of runtime governance include:

• Managing security aspects such as access control and data-level security through encryption
• Managing service level agreements (response times, availability, etc.) through compliance monitoring and reporting
• Managing auditing, logging, and exceptions

It's important to govern the runtime concerns or issues related to service behavior as it will help preserve the trust between service providers and service consumers and create a sustainable SOA environment.

Collaboration
Policies around collaboration should be targeted at accelerating the adoption of business services. This would involve defining policies around key areas such as discovery, trust, contract, and so on. The policy around service metadata would enforce use of clear business-technology-operational taxonomies for describing the service. Use of proper metadata and taxonomies will enhance service visibility across consumers. Similarly, defining the strong policies around trust and contract will help overcome the barriers of mistrust and hesitation present among service consumers. Agreeing to service levels and the integrity of service through a formal contract is necessary to gain consumer confidence. Providing historical compliance data on aspects such as SLA, support will elevate the trust further.

Sustenance
SOA is an ongoing phenomenon. Some of the key aspects around sustenance that need governance are:

• Consumer expansion needs-scalability - It's important that business services should scale to embrace new consumers on an ongoing basis and support the expansion needs of existing consumers in terms of increased volume

• Technology innovation - Migration of applications-business functionalities to a newer standards-based platform is inevitable for reasons such as reduced licensing and maintenance costs. While this is happening at the providers' end, existing consumers should be protected against the risk of changes in SLA in terms of performance, supported volumes and availability.

• Funding - There should be continuous funding to support and maintain business services and SOA infrastructure

Unless these sustenance-related challenges are thought through upfront, confidence in SOA's ability to sustain will diminish.

Models and Metrics
It's necessary to define a robust enforcement and compliance model. Some of the key considerations are:

• Deciding how various policies should get enforced - as part of the process or using tools technologies. For example, most development policies will be candidates for automated enforcement through tools
• Defining validation and review processes to ensure compliance
• Certificate of compliance for business services through various stages in the lifecycle to make the process more robust
• Exception management and impact analysis

Behavioral and cultural changes are necessary to get SOA right. The conservative, inward nature of an organization can lead to SOA failure. People have to stay away from the traditional mindset of "develop it myself." Being an enterprise-wide strategy, SOA's success depends primarily on the productive and effective participation of service providers and consumers. In short, to succeed SOA needs a culture of openness and healthy relationships. Creating such a culture requires organizations to promote positive behavior by providing rewards, recognition, privileged funding, and such. At the same time the negative tendency of reinvention-duplication should be discouraged.

Metrics provide the basis for measuring SOA success. Plan to measure success through indicators such as time-to-market for new product-process, cost-savings, and number of processes streamlined. Metrics can also be used to determine the effectiveness of governance. Define metrics to collect statistics on factors such as successful negotiation, reusability, and the interoperability compliance rate. This will help in understanding the loopholes and rigidity in current governance processes-policies and improving it further.