All successful SOA implementations have one thing in common – Governance! Five years ago I shared my thoughts on my blog discussing the three major work streams required for successful SOA implementation. Establishing SOA Governance is one of them. The Open Group SOA Working Group have developed and published an SOA Governance Framework so that organizations adopting SOA can leverage best practice SOA Governance. Organizations will save time and money by adopting those governance best practices provided in the framework – i.e. do not have to re-invent the wheel.

You can download the framework from the Open Group site and also listen to the webinar recording on the topic – click on the link below.

Listen to the webinar recording here

The webinar provides an overview of the SOA Governance Framework and describes the value of adopting a standard method using the SOA Governance reference model and vitality model. You will gain an understanding of the framework processes, guiding principles, roles & responsibilities and benefits. You will also learn how to apply the framework to different organizational circumstances to enhance the usage and reuse of resources (people, technology, processes) and optimize business results.

Let me know what you think of the framework by commenting on this post.

Bye for now -:) Awel Dico

It is kind of common now to associate SOA with Service Reuse. Yes – reuse is a very good thing – why spend much more money and time if you can reuse. If a service is reusable, in addition to contributing to business agility, it is also “green service” – environment friendly as well. The question is – How exactly is service reuse achieved? Many have been disappointed by the results they see in their SOA initiatives because their primary measure (metrics) for their initiative is Reuse. They lack clear understanding of what the service reuse is and how to get there. They assumed that service reuse is a given thing once you initiate SOA. The reality speaks different language from the assumptions. I used to preach to my team service reuse is one of the primary goal and want the team to deliver reusable service from the start. Overtime, I tracked the services deployed and only few services had the potential for reuse. Why? – I tried to find reasons why Service reuse is such a very good thing but wrapped by illusion.

Some of the reasons I listed include: Service interface and data not propoerly designed, service components not well designed, service level not properly incorporated, requirements not understood creating issue with service granularity and functional limitation, etc… You know what? … these and many more could be a reason to the problem. But, is that really a problem? Can one avoid these pitfalls by doing everything perfect and achieve the service reuse needed? The answer is NO! Yes, for simple cases where you can do perfectly and get reusable service – say across multi-business domains or multi-channels. For large organizations with many lines of businesses (or domains) it is not easy to get reusable services for cross business domain reuse. I came to understand why Service Reuse is such an illusion in many cases and what the organizations have to do to achieve reuse.

Here is my learning in the field -

1. First recognize that achieving (or getting to) service reuse in SOA is a process – i.e. a service may have to go through some iterative cycles to be close to perfect for reuse across multi-channel and multi-business-domain. It is proved to be hard to arrive at reusable service by just one shot! For large enterprise, this is mainly because of the lack of proper understanding of the complete requirements across the lines of businesses. This is the case today as the projects are mainly driven by lines of businesses bounded by cost and time. You may argue that enterprise can invest in completing cross business requirement understanding and absorb the cost for making service reusable. If so, you may have to add a “market factor” to this – the business line has urgent need to enhance its business capability to meet customers’ demand and cannot wait horizontal enterprise requirement analysis.
2. Second, recognize the importance of good service design to achieve enterprise service reuse. The evolution of your service towards reuse ( or in other words, your path and speed to reusable service) depends on the quality of your initial service design. Taking the #1 above into consideration, if your service design is not done well to position for further evolution of the service for reuse, you will have to redesign the service or end-up with duplicate non-reusable services across the enterprise – defeating the overtime “green service” vision of SOA.
3. Third, understand that enterprise service reuse requires strong SOA governance to facilitate the service reuse process. This goes into Service portfolio and service life-cycle management for the enterprise and more…
4. Fourth, recognize that SOA infrastructure can play a major role in facilitating enterprise service reuse … more on this in my next blog postings

I will try to share some detail toughts on this later… Bye for now.

It seems there is still some confusion out there as to what a “Service” means in the context of Service Oriented Architecture. Just recently I came across a discussion where “service” is being communicated as just a simple web services interface. That is why I thought of sharing here the definition I used in a presentation about SOA over a year ago. I used some concepts from OASIS SOA Reference Model and added other aspects of service that I think are important. The diagram below shows the anatomy of SOA service – what it really means when we say “Service” in the context of SOA. The usual common picture people use to communicate SOA based service is by using the triangle that shows service provider, service consumer and service broker or registry. What is more important and most of the time not clearly explained is the other view of the same triangle I overlay in the diagram below. That is, service has a description, service has implementation and service is governed. 

Service Anatomy - What Service means in SOA

In short, the following aspects of “service” are implied or need to be considered when one speaks of service in SOA:

• The usual high level view
  • Service has provider
  • Service has consumer
  • Service has a registry
• The other view which is more important is:
  • Service has description. This includes tasks that the provider has to worry about to meet the consumer need and how service can be used by the consumer (for the definition of these terms please refer to OASIS model linked above):
    • Contract
    • Interface
    • Reachability
    • Metrics
    • Functionality
  • Service has implementation. This includes tasks that the provider has to worry about to meet the consumer expectation of the capability of the service :
    • Design (you know how this is important too -:))
    • Code (you know … this is where the meat is -:))
    • Test (yeah.. you think this is not important? In most of the cases this is where the money is spent – cost. You must deal with on the strategy on how to test SOA services)
    • Package (yeah… you think this is not important? Think again… this is related to service versioning, migration, change management etc.. issues. You better have a good strategy on how to package the services implementation before they get deployed)
    • Deploy (considerations of performance, scalability, availability, and other operational needs)
    • Secured (this is missing from my previous diagram – but i think it is important aspect that must be considered)
    • Monitor (why? you must capture some metrics to evaluate if the service is of value to the business as expected. This metrics comes from the top level business service design because that is where they identified as important factors to capture for business use (mostly referred to as KPI). There are also operational metrics that are collected to meet operational requirements – e.g. capacity planning, trouble-shooting, etc…)
  • Service is governed. This includes tasks that the Enterprise Architecture has to worry about:
    • Standards (i.e. service may have to be compliant with some industry standards. Those standards are best specified by enterprise architecture)
    • Guidelines (i.e. enterprise architecture should have SOA principles from which some measurable guidelines can be derived. Services need to be compliant with these guidelines, otherwise the principle is considered not applied)
    • Compliance assessments (i.e. services should be assessed against the specified standards, guidelines or principles for compliance by the governance team)
    • Exceptions management (i.e. it is a reality that a given standrd or guideline may not be followed in under some circumstances. For example the cost of implementing the guideline or standard may not be justified at the moment; and as a result a non-standard approach may be used to implement the same capability required by the business. This is about weighing the pros and cons of such a decision and if allowed then the governance team need to manage that exception. The exception is normally temporary. However there are cases where the exceptions reveal a defect in the principles or architecture itself.  This is mostly the case if too many exception is granted as a result of violation of a given standard or guideline. In such situations, the architecture or principle need to be reviewed and the broken guideline need to be updated accordingly.)

 In the above discussion, I did not mention where the service we talked about came from – I mean its granularity, usefulness from business needs perspective, etc. I assumed that a “service” we talk about here is based on top level service architecture as a part of enterprise architecture. See my discussion on Service Oriented Enterprise Architecture Framework which puts the “SOA service” discussed here in a bigger context.

From end-to-end perspective, I think when we say “service” in the context of SOA, we need to understand the above aspects of a SOA service – its complete anatomy.

Awel Dico