“… the major difference for SOA governance is an appreciation for the cooperative nature of the enterprise and its reliance on furthering common goals” - SOA Reference Architecture [1]
SOA Governance is one of the hottest and most delicate topics in SOA nowadays. About two years ago many enterprises just approached SOA and could work from the so-called “greenfield”. Why was there no attention to SOA Governance in place? This may be explained in different ways, but the situation reminds me of a “golden” rule of SW developers – try it, if it does not work, take a look at the instructions afterwards.
That time organisations were assured that SOA was new IT technology for integration and reuse of existing assets. Integration and reuse had to (magically) enable meeting business needs faster and easier. Some organisations built hundreds of Web Services and finally got stuck at the point where they ran into exceptional difficulties in managing that many integration points. Other organisations failed in gaining promised ROI and time to market (well, can a truck move faster if you put more wheels on it if it still has the same engine?). Very few succeeded and went forward. Why has this happened?
I can see one of the main reasons of these difficulties in that service-oriented design, implementation, and usage were either not governed at all or governed as traditional SW development, i.e. without understanding of service orientation specifics. This article observes SOA governance specifics from the enterprise perspective and illustrates them with several examples of SOA Governance policies.
What is SOA in SOA Standards?
First of all, I need to set the common grounds and define the things we will be talking about. One, probably, can find many definitions of SOA from W3C, IBM, Wikipedia, etc. I will use another one, which was published in the end of 2006, in the first SOA dedicated standard from OASIS – SOA Reference Model (RM) [2]. The standard has positioned SOA as a business-centric architectural paradigm. That is, in SOA, we’re talking about business first and only then about technology as the major service-oriented environment.
SOA RM:
the central focus of service-oriented architecture is the task or business function - getting something done
This article utilises the SOA RM standard and the SOA Reference Architecture, Public Review of SOA-RA v1.0, Draft 1 (SOA RA PRD 1) [1] from OASIS. Both documents emphasise the business-centric nature of SOA and its flexibility in adapting to business changes.
SOA RM:
… in SOA, services are the mechanism by which needs and capabilities are brought together
Of course, OASIS SOA is about services. However, a service in SOA gets defined as an implementation agnostic abstraction which helps customers in obtaining a Real World Effect (RWE) that satisfies their needs. To provide customers with a RWE, a SOA service utilises its capabilities related to the independently existing resources.
SOA RM:
defines execution context as: …a set of technical and business elements that form a path between those with needs and those with capabilities
A SOA service operates in an “execution context,” which comprises business and technical contexts. Business context includes business model, rules, and regulations where the RWE gets its specific interpretation. Technical context is a technology environment where the technical parts of the services execute.
As we see in majority enterprises, business and technical contexts exist and evolve separately (unfortunately). Such separation is rooted in the traditional relationship between business and IT, and it hides a serious danger for SOA. Here is an example: assume we have a service performing simple numbering of the building floors in the UK. A business, i.e. ”those with needs”, decides to apply the technical service implementation, i.e. ”those with capabilities”, in the US and expect the same RWE. One can imagine business dissatisfaction when it finds the service provided different results in the US than in the UK. The reason is trivial: the service executed in a different business context, where there are no ground floors in the buildings and floor number 12 is followed by the floor number 14.
For the last several years, SOA became associated with marketing clichés such as “SOA’s goal is a better integration between IT assets”, or “SOA is about service reuse”, or even “a legacy application wrapped by a Web Service becomes a SOA service”. I can only ask – “Really?”[3] All of those clichés are oversimplified technical interpretations while SOA models business via business architecture, technology architecture and solutions. As Anne Thomas Manes of Burton Group said, “SOA is a style of systems architecture, not integration architecture. It’s about refactoring capabilities into services, not about integrating application silos”. I can add that even the legendary service reuse is not the best candidate for SOA marketing because trivial reuse of Web Services may turn an enterprise either into a market leader or into a nightmare. It depends on how SOA governance defines and regulates service reuse [4]. We talk about service reuse for 2-3 years already but about service governance – just now; this is the root of SOA adoption difficulties.
SOA Governance
Standards-based Governance Basics
The SOA RA PRD 1 has recognised the role of enterprise social structure within SOA. Indeed, actions of the participants of the service interaction – service consumers and providers – have business or technical meaning only to the people and organisational units “with needs” and those “with capabilities”. As a consequence of this, we may say that if a social structure changes, the same actions may get different meaning than before. Even more, if a consumer expects the same meaning of the service actions in different social structures, it is likely that the service has to behave differently and provide different results (or RWE) in different social structures to meet such expectations.
SOA RA PRD 1:
The actions undertaken by participants… are normally performed in the context of a social context which defines the meaning of the actions themselves.
SOA RA PRD 1:
social structure: the embodiment of a particular social context
The notion of social structure crosses the boundaries between business and IT parts of the organisation. This builds the ground for SOA governance as an enterprise-wide governance model covering business and IT together. This is a very natural approach because the major goal of technology in SOA is to help organisation in achieving the RWE for the business benefits. In other words, SOA and its governance have the “head” in the business, and the “legs” in the technology.
SOA RA PRD 1:
…it is important that organizations that plan to engage in service interactions adopt governance policies and procedures sufficient to ensure that there is standardization across both internal and external organizational boundaries to promote the effective creation and use of SOA-based services
An enterprise-wide concept of service orientation leads to the distribution of business and technical capabilities that may be under the control of different ownership domains, as SOA RM states. This is a special topic that we discuss later. Now, we just outline that the structure of ownership domains and an enterprise itself get a reflection in the hierarchy of SOA Governance. Thus, we recognise the following SOA Governance structure:
- Enterprise SOA Governance as a part of the Enterprise Governanc
- Enterprise SOA Governance includes:
- Business SOA governance
- IT SOA governance
- IT development SO governance
SOA Governance is concerned with decision making based on policies and regulations. It is the management who is concerned with execution of policies and controls. This is why SOA via its Governance has the unique capability of crossing administrative ownership domains in the enterprise, which no other architecture, rooted in the technology, could do before. The areas of SOA Governance influence in an enterprise are illustrated in Figure 1.
SOA RA PRD 1:
Given that SOA mediates an important aspect of people’s relationships, it follows that there are commitments entered into by participants that require enforcement by the community and that the SOA itself must reflect the requirements of the community itself. Both of these are aspects of the governance of Service Oriented Architecture. The key elements of our model [M.P. – SOA RA] that relate to governance are the constitution of the social structure, the policies of the social structure, authority in a social structure, and the associated mechanisms of enforcement.
Nevertheless, SOA Governance does not replace Enterprise Governance, or Business Governance, or IT Governance. We have to remember that there is a world besides SOA.
SOA Governance and Ownership
Ownership domains play one of the most important roles in governance structure. In a single ownership domain the governance is usually hierarchical including corporate, line of business (LOB), business unit (BU), technology, IT, and architecture governance. In an environment with multiple ownership domains, governance cannot be executed in the same way as in the single ownership domain but has to be based on accepted governance authority. For example, in a Fund Management company, a Retail LOB has developed a Fund Deal business service; the Retail LOB is the owner of the service and may be the service provider. The Institutional LOB of the organisation may reuse this service in the Institutional Client Web sites having just contractual relationship with the service owner and admitting Retail LOB governance authority over this service.
A constraint imposed by an ownership domain is very well known in IT. Such a constraint on resource accessibility leads to a duplication of development efforts in IT, to a disbalance of IT product releases, to the troubles in the enterprise architecture and technology roadmap stabilization and to multiple P2P integration mess. Only vertical governance through the business and IT together, which is setting the policies and defining the rules that provide an operational context for policies, can positively influence management in both business and IT. For example, a business Governance Body could set a policy saying that all business Clients have to have individual entitlement to the related business data. The IT Governance Body states the Rule that the first step of entitlement has to be user authentication service based on PKI technology. The IT Management can specify now who it deems to be a recognized PKI issuing body and how actual authentication has to be conducted.
Figure 1. SOA Governance areas of influence
Setting rules and regulations does not ensure effective governance unless compliance can be measured. Based on these measurements the rules and regulations can be enforced. Metrics are those conditions and quantities that can be measured to characterize how well the service actions are compliant with policies and contracts. Rules and regulations must be based on collected metrics or there will be no way for management to assess compliance. The metrics ought to be available to the service interaction participants and to the Governance Body to ensure that the results of measurement are clear to everyone.
It is important to note that effective dealing with different ownership domains, even in the enterprise, is one of the most serious challenges of governance. SOA Governance, in this regard, requires a service-oriented style in service development and maintenance, which differs from traditional application governance. Service-oriented policies require business/technical groups, individuals, consumers, and developers to consider much more relationships and dependencies that simultaneously combined with narrowed ownership for each service. This is the price to be paid for SOA flexibility and adaptability to market needs.
In effective SOA Governance, policies and regulations have to be balanced. To cross ownership domains, the balance may be achieved through expressing policies in a more advisory manner in several grades like mandatory, highly recommended, recommended, restricted, prohibited, and so on. The procedure of balancing requires a process and appropriate discipline in executing it; this also includes validation of exceptions from the policy compliance. The major requirement for such balance is the consideration of today’s and tomorrow’s business needs addressed via flexibility of governed services and entire SOA eco-system.
IT SOA Governance Concerns
One of the major benefits of employing SOA principles in the enterprise is the ability to quickly recruit and re-allocate resources to deal with unexpected and evolving situations in the business and, correspondingly, in IT. It also requires considerable flexibility in the ways these resources can be employed and a great deal of confidence in the services capabilities.
Figure 2. Business application and service organization
Figure 2 illustrates a concept of a business service which meets the aforementioned requirements and may be implemented in IT. The fundamental difference of this concept from others is in that it combines Model-Driven architecture principles with Component-based design into a vertical dedicated structure (VDS). Such a VDS accumulates a cohesive set of functionality addressing one business task end-to-end.
A VDS represents a business service, or business function, or business feature, or may be used in more complex aggregation implemented as a business process. The layered organisation of each VDS supports quick re-composition and reuse of resources, plus, some layers may be accessed directly by external components or services (e.g., Service Interface and Process Connector) for business application integration purposes. A business application in this approach comprises one or several business services orchestrated via Business Process Connector Layer with none or minimal programming efforts (minimal time-to-market). While more detailed review of such business service model is a topic for a separate discussion, we can see several subjects for SOA Governance in it, such as policies on separation of concerns between layers, on internal and external interface accessibility, and on sharing entities in the Technical Service and Resource Layers.
Thus, SOA Governance applies to four major aspects of service structure and service use:
- Service structure – the minimal set of elements that constitute a service within element relationship and operational models (development, integration and deployment policies)
- SOA infrastructure – the “plumbing” that provides utility functions that enable and support the use of the service (deployment and run-time policies)
- Service inventory – the requirements on a service to permit it to be accessed within the infrastructure via public interfaces, manually and automatically (management policies)
- Participant interaction – the consistent expectations with which all participants of the service interaction are expected to comply (reachability and run-time policies)
SOA RA PRD 1:
… service functionality… describes what can be expected when interacting with a service.
Service Functionality, is an unambiguous expression of service function(s) and the real world effects of invoking the function. The Functions likely represent business activities in some domain that produce the desired Real World Effects.
The Service Functionality may also be constrained by Technical Assumptions that underlie the effects that can result. Technical assumptions are likely related to the underlying capability accessed by the service.
Elements of Service Functionality may be expressed as natural language text, reference to an existing taxonomy of functions, or reference to a more formal knowledge capture providing richer description and context.
While SOA Governance of service development is out of scope of this article, the following sections discuss the mentioned aspects in more details.
Service structure is transparent to the outside world though some structure elements are dedicated to the consumers and have to be visible. In particular, visible service structure elements are:
- service functionality
- service interfaces
- service reachability
- service communication/invocation policies (may be just referred)
- service execution policies that important to the consumer and affect service RWE, service behavioural characteristics and related metrics
Service functionality, as defined in the SOA RA PRD 1, is one of the major elements of a SOA service. Functionality is used by the service consumer for making the decision whether the service meets consumer’s requirements (needs). Other such elements are behavioural characteristics and related metrics.
All visible service structure elements are described for public use in the Service Description document. SOA Governance defines policies that regulate life cycle of the Service Descriptions, places where they are advertised and stored, rules of usage, as well as their content.
Service providers use Service Descriptions for announcing available services while service consumers use them for the service discovery. Depending on the service, the discovery may be manual or automated. There is a hope that Semantic SOA interoperability [5] will help in mutual understanding of the expressions of the service functions and RWE in the Service Descriptions among service consumers and providers.
Figure 3 illustrates a model of a Service Description document. As we can see,
- service reachability defines physical points of service access
- service interfaces group logical interfaces offered by the service
- service function conveys the RWE
- policies define service execution context (EC)
Commenting on this model, we can outline that
- a Service Description may identify a set of functions (i.e. functionality)
- a Service Description may identify several service interfaces
- service behaviour is promised in the specified EC; if a service to be reused in another EC than specified, the service has to be re-tested to verify it provides the same RWE
- Service Contracts origin in the Service Description
/filters:no_upscale()/articles/poulin-governance/en/resources/image2.jpg){kind=link}
/filters:no_upscale()/articles/poulin-governance/en/resources/image3.jpg){kind=link}
Figure 3. Elements of the Service Description document
Service functions may be reflected in the service interface operations but it is not necessary. For example, a service (Service Description) can promise performing an audit logging for each service invocation and a consumer may rely on this feature. Logging is not represented in the service interface but it can save consumer’s efforts in its own audit support. In the simplest case, one function corresponds to one interface operation and the interface contains only one operation. Generally, SOA service interfaces may differ both in the operation semantics, behaviour model, and information model as well as in the reachability (protocols and end-points). A simple example of a service with multiple interfaces is an infrastructural service built on an EJB with RMI, CORBA, and Web Service interfaces.
SOA Infrastructure
From the SOA Governance perspective, the SOA infrastructure has to include, at least, three components – a service execution or run-time platform, a Repository of Service Descriptions for the available services, and a Repository of Service Policies applicable for service announcement and run-time. There may be other infrastructural elements like Service Registry (e.g. UDDI), service intermediary like ESB, service run-time monitoring systems and alike, but all of them are optional. A Repository of Service Descriptions contains Service Description documents mentioned in the SOA RA PRD 1 and can be combined with the Service Registry.
One of the highly recommended usability aspects for SOA services is a Service Contract. It is important to notice that Service Contracts are derived from the Service Description. The major difference of the Service Contract is that it is the subject for mutual agreements between the service provider and one or several service consumers while the Service Description is the announcement of the service by the service provider only. A Service Contract represents a subset of the Service Description elements. Also, Service Contract is supposed to contain/refer to a Service Level Agreement (SLA) for particular consumer. Different consumers may agree on having different SAL for the same service depending on, e.g. different communication protocol.
It has to be regulated by the SOA Governance policy whether the Service Contracts may be available as a part of the Service Description because Service Contracts are private agreements with individual consumers. Another consequence of this private nature is that inheritance or cross-reference between Service Contracts may be a very complicated matter or simply prohibited (a consumer may not be dependent on a non-disclosed contract with another consumer). At the same time, inheritance or cross-reference for policies is a common thing.
In some cases, it is reasonable to have the same Service Contract for all consumers. Also, a Service Description may play the role of a single shared Service Contract with special policy, which defines the authoritative rules of the service usage. For example, a security service may be equally applicable to all and it does not require agreements with individual consumer. A Repository of Service Contracts is a recommended but optional element of the SOA Infrastructure too.
Service Inventory
Some governance models address a tightly controlled environment where a primary concern is to avoid any service duplication, or more accurately, duplication of services’ functionality. Other governance models suggest a market of services where the consumers have wide choices. For the latter, it is anticipated that the better services will emerge from market consensus and the availability of alternatives will drive innovation.
At the same time, if an important (even not mission critical) functionality gets accessible through only one service, this obviously raises a serious risk for the enterprise. Instead of talking about redundant resources in IT, in SOA we have to take care of functionality reachability, i.e. it makes sense having several different ways in SOA to reach the same functionality (while service capabilities may be not necessary the same). The functionality, therefore, becomes an important informational element of a service Inventory – just listing a service ID, interface and name is not enough any more.
A SOA inventory may be based on the already mentioned Repository of Service Descriptions. The Governance Inventory policy may specify, for example, service versioning model, rules for new version announcement, service retirement process and EOL events.
Participant Interactions in SOA
Participants interact in SOA in accordance to the policies set by SOA Governance. Each service provider may have individual local policies announced in the Service Descriptions. For a consumer to reach a service across local boundaries, we need a form of global governance. However, I see an obvious challenge in having sharable semantics and ontology for the policies crossing ownership domains even for one enterprise.
SOA RA PRD 1: …the goal is to avoid global governance specifying criteria that are too restrictive or too lax for the local needs of which global governance has little insight.
Global governance in SOA is possible in the same manner as we see this in regulated financial markets – there may be a minimal centralised standardised set of policies like WS-I Basic Profile [6] for Web Service interoperability. Nonetheless, an expectation that governing policies would be equally enforced everywhere is unrealistic. Thus, an effective way for global SOA Governance may look like this: participants, who want to interact, have to become compliant with locally agreed governance policies. This highlights the role of the Service Contract in SOA interactions.
As we saw, service governance comprises governance policies aggregated from all interacting Participants. It has an interesting consequence rooted in the model of aggregated services. The SOA RA RPD 1 states that at least two participants are needed for the service interaction and there may be more than two. Let us assume we have a case with one service consumer and one aggregate service, i.e. the service, which engages other services to fulfil its functionality. That is, we may have several service Participants. Each engaged service may have its own governing policies that may influence the RWE promised by the aggregate service. It becomes a non-trivial task for the governance to identify a rule on how to select and represent all policies that can affect the final service result in the Service Description and guarantee quality (completeness) of the Service Contracts.
SOA Governance Policy Examples
We mentioned before that SOA Governance in IT affects both the development and production stages of a service. The governance may start small and concentrate on the development stage first. However, it has to form the ground for future SOA Governance policies promoting flexibility and scalability of the service at run-time. Following are several useful examples of SOA Governance policies:
|
Areas of Applicability |
Policy Examples |
|
Governance Process |
|
|
Development Stage |
|
|
Production Stage |
|
Conclusion
SOA RA PRD 1:
There is not a one-size-fits-all governance but a need to understand the types of things governance will be called on to do in the context of the goals of SOA. It is likely that some communities will initially desire and require very stringent governance policies and procedures while other will see need for very little. Over time, best practices will evolve, likely resulting in some consensus on a sensible minimum and, except in extreme cases where it is demonstrated to be necessary, a loosening of strict governance toward the best practice mean.
SOA Governance is an integral realm which includes governance of the customer-centric business and technical services. SOA Governance is not explicitly standardized, but the OASIS SOA RM standard, together with SOA RA PRD 1, dedicates significant attention to this aspect of SOA.
The SOA RM and SOA RA PRD 1 recognise a social effect of SOA and identify SOA Governance accordingly. In this respect, SOA Governance is viewed as a part of Enterprise Governance, covering related areas both in the business and in the IT crossing ownership boundaries.
This article observes basic SOA service structural elements, SOA infrastructure and service interaction from the governance perspective.
SOA Governance has to encourage service consumers to rely on, and service providers to provide the ability of services to meet business needs in modern dynamic business market. To achieve this, SOA Governance promotes concepts of flexibility and adaptability from the top to the bottom of the enterprise and from the business to the technology, all together.
References
-
Reference Architecture for Service-Oriented Architecture, Public Review of SOA-RA v1.0, Draft 1, OASIS
-
M. Poulin. “Does a Web Service Make a Service for SOA?” , SOA & WebServices Journal, May, 2006
-
M. Poulin. “Service Reuse and Entitlement”, SOA World Magazine, March, 2008
-
Dmitri Ilkaev. “Recent Trends in Semantic SOA”, StickyMinds.com
About the Author
Michael Poulin works as an enterprise-level solution architect for different Financial Institutions in the UK and in the USA. He is a Sun Certified Architect for Java Technology, certified TOGAF Practitioner, and Licensed ZapThink SOA Architect. Michael specializes in distributed computing, SOA, and application security for last 10 years. His recent publications may be found at Sys-Con Media.