For sometime now I have been working on a few papers on the subject of SOA. This is the first, my definitive definition of what is SOA Governance.
‘SOA Governance’ is perhaps the hotest of topics in the SOA world currently but it seems that almost everyone with an opinion has a different definition of what it is and how to do it. I have attempted with this post to distill these definitions into one document which you can take away and use as part of a policy statement to help you with your SOA’s construction.
Introduction
Enterprise or corporate governance is the ability for executive management to create policies that apply to their organisations, communicate those policies, provide employees with the tools they need to comply with those policies, enforce those policies, obtain visibility into levels of compliance and mitigate any deviations from corporate policy.
SOA governance, in addition to the more traditional human-based software development life-cycle (SDLC) checkpoints and role-based review signoffs, focuses on the creation, communication and enforcement of service policies. Service policies are metadata that consist of a set of constraints and capabilities that govern how services and their consumers interact. Simple policies typically include rules describing who can access a service and what credentials they need, how messages should be routed to the service and what service-level agreements (SLAs) apply to the service.
SOA governance requires that organisations take business policies, typically in written form, and transform them into metadata-based rules that can help automate the process of validating and enforcing compliance with those policies in both design time and runtime environments. Companies must then manage policies through their entire lifecycle. In general, policy lifecycle management within SOA focuses on ensuring the quality, performance and applicability of available services, enabling service consumers to discover and reuse services as well as other artifacts, managing service versions, handling the security of services and other SOA artifacts, and assessing and managing the impact of change across all service consumers. Managing policies also includes providing visibility into whether people are following policies, as well as handling policy infractions. Such policy management tasks are also an inherent aspect of IT governance.
What a SOA Governance consists of,
- Organisation Changes
- Polices
- XML Schemas
- WSDL documents
- Documentation
- Management of SOA artifacts
Organisation Changes
There is a common misconception that SOA governance is governance of a SOA, as though SOA were one more IT asset in need of governance in the organisation. That belief, however, indicates a fundamental misunderstanding of the role of SOA. Fundamentally, SOA is enterprise architecture — when an enterprise adopts SOA, it should approach the organisation of all of its IT assets from an SO perspective. As such, Service orientation provides a broad organising principle for all aspects of IT in the company — including IT governance. That’s why we say SOA governance is IT governance in the context of SOA, rather than governance of SOA.
Furthermore, SOA requires a reorganisation of IT personnel and the users of IT into domains. The need for governance highlights the importance of such reengineering, but is not its cause. On the contrary, the need to break down silos and organise a company’s efforts based upon the core needs of the business is as old as the term “reengineering” suggests. SOA enables the enterprise to organise IT functionality into Services that meet the needs of the business, finally enabling companies to achieve the long-desired business goals of breaking down silos and focusing on the needs of the business and the customer.
The IT governance process begins with setting objectives for the enterprise’s IT efforts. Traditional IT governance processes then distribute these objectives to each department within IT, for example, applications, networking and development. SOA governance, however, introduces the notion of domain ownership, where domains are managed sets of Services sharing some common business context. In many cases these sets of Services are business Services, such as customer information, order processing, or product analysis.
Each domain is responsible for maintaining the applications that support its Services and for maintaining the interfaces to its Services for other domains. The owner of each domain must therefore handle such issues as Service management, business logic encapsulation, location independence, and the data format issues associated with its Services. When the people in charge of some product area want access to a Service from a domain, they make a request to the owners of the domain and the two groups determine the relationship between their respective spheres of influence, creating a Service-level agreement between them. Such relationships and agreements also exist between domains.
SOA governance also introduces new roles that the company must provide for:
• The domain owner — manages the direction of the domain and the business relationships between the domain and business units, as well as other domains. The domain owner also helps business process owners in various business units understand the business application of the Services within the domain. This person also tracks the usage of Services for management purposes and ROI calculations.
• SO domain business analyst — identifies abstracted, normalised business Services. Translates business requirements into Service definitions. Works closely with IT personnel to direct Service implementation.
• Line of business representative — communicates business requirements and identifies business Services for each of the domains.
• Domain developer — builds and maintains Services consistent with the SOA lifecycle. Implements Services consistent with implementation guidelines and the SOA.
• Service tester — certifies that each Service conforms to the business requirements that apply to that Service. Builds test cases for the Service interface.
Each person working within a given Service domain is responsible for developing the business Services that are shared across the lines of business. This shift in responsibility introduces a change in the organisational structure for application development, as people shift from developing functionality within an application to developing functionality within a particular Service domain. These new roles should work in conjunction with the enterprise architecture team.
Polices
Policies are design rules specify interfaces, eliminate certain paths from consideration, and delineate boundaries between subsystems. A primary goal of architecture is to increase modularity and create well-defined abstractions based on service APIs. After those choices have been made, they must be recorded, communicated, and enforced.
Creating palatable policies
Effective governance hinges on the processes that produce policy decisions — that is, the methods by which you make, communicate, and enforce choices.
The decision-making process can be organised in various ways, but ultimately it’s a social process that has to work in an organisational culture. The rise of social software systems like ‘LinkedIn’ has helped gained an appreciation for SOA governance. It’s about recognising that people are socially organised. SOA governance must incorporate best practices around organisational dynamics and how human beings behave in organisations.
It is easy to create animosity toward governance for example, for developers to adhere to policies that they aren’t aware of up front. Policies have to be set down on paper. Awareness created, expectations set, and clearly stated but it is important that the policy isn’t overwhelming.
Many organisations create a centre of excellence or some other group in the enterprise architecture group to provide resources and guidance, to serve as a repository for best-practice information, and to operate tools that support the SOA governance process.
The idea is to build schools, not prisons with the goal being to help people conform to best practices, not police them.
Policy No. 1
Policies can affect every aspect of the service lifecycle, including design, deployment, and operation. For example, a design-time policy might set out a corporate namespace, whereas a deployment policy might require that production-level services meet requirements laid out by the WS-I (Web Services Interoperability) organisation. Or an operational policy might require all deployed services to be managed and use the corporate security infrastructure.
But in most organisations, it makes sense to begin policy-making efforts with standards. After all, standards make SOA possible. Each enterprise must determine which standards are used where and when. For example, will WS-Security and WS-Policy be used? Under what circumstances will they be required?
You could call out specific standards in individual policies, but a better strategy is to create an IF (interoperability framework). An IF is a special policy that lists the standards that your organisation will use, points to reference information, and indicates the status of the choice: approved, de facto, emerging, sustained, sunset, or in process.
These indicators are largely self-explanatory, but two deserve special mention. “Sustained” indicates that even though the organisation has decided to support another standard in this area, use of the older standard is supported. “Sunset” indicates that developers should migrate from the standard as soon as practical.
An IF separates references to quickly changing standards from individual policies, making them easier to manage. Overall, an IF is a great place to begin, if only because agreeing on standards will probably be the easiest policy task you’ll face.
Creation of Registries
Registries are the primary tool organisations use for managing and communicating governance artifacts, as well as automating key governance activities. A registry provides a central reference or “system of record” for services. Think of it as a place where services can be advertised by providers and discovered by consumers inside an organisation — a control point for governing service availability, versioning, and compliance with internal and external requirements.
Some vendors offer what they call “repositories” — registries that also serve as places to store metadata for services that go beyond WSDL documents. Because registries and repositories are so important to the development process, look for software that deeply integrates with your development environment. For example, if you’re an Eclipse shop, be sure that the registry you choose has a plug-in for Eclipse.
Registries also have APIs that are used by applications at run time to find services and associated policies dynamically. Additional metadata might, for example, tell the service consumer what security policy the service requires so that the client can dynamically adjust to changing service offerings.
Run-time policies are most effective when they can be expressed in a WSM (Web services management) system, such as those provided by Actional, AmberPoint, Blue Titan for example. Most WSM systems provide a means of enforcing conditions on the SOAP envelope at run time. For example, a WSM can ensure that services use a particular security protocol or that enclosed XML documents conform to a particular schema.
Look for systems that not only allow you to manage, version, and discover policy at design and run time but also provide for policy reuse. Being able to create and manage policies independent of a specific service allows you to fully leverage policy assets.
In general, enterprises should automate as much of the governance process as possible. That requires a centralised investment in people, organisations, and tools to establish the appropriate context for SOA. Properly done, your governance process and its associated infrastructure may be the only centralised elements in your entire SOA deployment.
