One of the important aspects of SOA Governance that we have been discussion is that of Service Domains: rather than having a lines of business own systems, Service Domain Owners choose Service Domains which group a set of related services. These affinity of these services are often of a business nature, or originating from a buisness perspective at the very least.
Decomposing a business domain into its sub-domains and functional areas enables a set of natural boundaries that can be a good starting point for Service Domains.
The Service-oriented Modeling Approach uses this strategy to identify domains, decompose them and then put governance around them.
Every domain owner will provide a set of services and wil in turn, itself require a set of services for consumption.
Thus the publication of the servcie descriptions of both these sets of services are critical to get the service eco-system going in your enterprise.
This allows the Domain Owners to make decisions about implementation changes to Service Implementations without changing the Servcie Description, if the change does not affect the SLA (service level agreement) and QoS (quality of service).
A set of base services can be instilled into an organization as the primary business functions it provides and decide which ones it in turn requires from its business partners. (the DNA approach we discussed earlier , recognizing the fact that there are three approaches to this paradigm, each of which may fit your enterprise.
Instill, let go and observe the evolution of services as they are adopted at various levels of maturity (or not), exercise governance for communication of the services, obtaining feedback to ensure they are relevant and to check for compliance.[Read More]
BPM, APIs & Service-oriented Architecture: Insights and Best Practices
From archive: December 2005 X
Ali_Arsanjani 120000D8QB 1,260 Views
Back to the discussion of Service Domains: changes and ownership through governance.
Two readers have responded with interesting considerations.
MMahesh, your response brings about an important element of SOA: that of the separation of description from implementation and to IoD's point, if the change in question is only one of functionality and not SLA change or QoS change, then the Domain Owner has less of a say in this.
It thus appears that the service consumer expects a certain function (Service description) and a certain QoS. If these are satisfied, then the consumer if typiclaly happy.
Thus the change might not even affect the consumer, in which case the question is whether non-consumer affecting changes should be reported.
In some cases, I would like to point out that this may be warranted: where there is a deviance from a reference architecture, and i.e., of compliance. Now if the change makes sense then it must be propagated through the governance process of vitality which ensures continued relevance of the compliance criteria (eg a reference architecture or reference model) .
1. provider and consumer roles have their own concerns and governance applies to each individually and then to both to maintain a healthy service eco-system.
2. Change the implementation if you want (provider) or change it if you have to (consumer) and you are not getting your QoS or functionality. This ability to have the power to choose from various providers who suit your needs (functioanl and operational (QoS)), is a key feature of SOA.
3. Service Domains define a sphere of responsiblity, both functionally, operationally and financially.[Read More]