The term "SOA governance" has possibly become the most used phrase in the SOA community. However, through experience with the architecture community across
Product vendors, SIs as well as the Customers, is that it is also the one term that has been misconstrued to mean different things by individuals taking a very
silo–ed look at things. This article puts forward thoughts on the "What, Why, When and How" of SOA governance based on experiences working at the grassroots
level of organizations with a successful SOA story, as well discussions with the CXO organization on how they perceive the SOA story.
The First W – What?
SOA governance is an embodiment of many different aspects that are all crucial to the SOA story within the organization. Just as the standard "governance" (whether political or organizational), SOA governance is also as much about policies and procedures of conduct as it is about the actual implementation, monitoring and control of the same.
The idea of governance is to:
- lay down the operating framework for the various teams working on the different SOA initiatives
- work in a review mode on an ongoing basis ensuring that the initiatives are delivering in line with the end objectives
- monitoring the runtime of the services and their environment from a diagnostic as well as prescriptive point of view as the initiatives move into the implementation state
SOA governance is not a one–time system. It is not what an organization would put into place once and see it operational over a period before it turns into more of an ornamental piece than a
functional system. SOA governance is all about having continuity; it is about active participation in all aspects of the SOA journey and its various phases. Governance is mandated to take part in the
inception of the various projects as well as participate actively in the runtime part of the projects as well. These are the two parts of SOA governance – the "Design–time" and
"Design–time governance" is responsible for the activities in the Service Identification, Service Specification and Service implementation phases. The guidelines laid–down for the
identification of services and the standards and best practices set around how services will be specified; design and then implementation are not only instrumental in the success of these services
in the runtime environment, but are also critical from the perspective of qualifying and measuring the success of the SOA initiatives in the first place. Services identified and designed following
the best practices are the ones that will go a long way in helping the organization realize the benefits of SOA; it will bring them to the "Promised Land" as charted out when the journey was started.
In "Design–time", the governance body will extend and take under its fold the business analysts (domain SMEs), as well as the service architects sitting in the various projects.
Playing the central role of bringing all projects together, governance is also tasked with ensuring that while projects continue to deliver as per their requirements, the services do not conflict or encroach on each other, and that they maintain a clear boundary with each other in view of the functional capabilities. This active role of governance in the design phase will also ensure that projects benefit from the deliverables of other projects as well as the fact that interdependencies are clearly identified, understood and tracked.
On the other hand, "Run–time governance" is responsible for the behavior of the services and the environment they run on in the run–time environment. It is all about how well the services are delivering on their QoS (Quality of Service) parameters that they were designed for. This aspect of governance requires the usage of tools to monitor the run–time performance of the services, their individual components, as well as the platform and infrastructure they have been deployed upon. The responsibility does not end with monitoring of the run–time, but with the task of identifying potential areas of concern proactively to allow for prescriptive, instead of corrective action. Additionally, it is also in the purview of governance to take the lessons learnt from the run–time world back into the design time world in a constant bid to strengthen the service landscape.
In the run–time role, the governance body will extend itself to include the infrastructure and operations teams who are owners of the physical and virtual environments in which the services execute.
The Second W – Why?
Having gone through the first "W", the second "W" – why does an organization need to put in an SOA governance layer, also has also been touched upon. Broadly speaking, not having an SOA governance layer will adversely impact the organization with respect to the costs of service implementation and the returns on the same and the actual turnaround time for the returns. In other words, going by the expression "time is money", the absence of the SOA governance layer will result in adverse financial impacts.
The whole concept of SOA has been oversold; many times over. The naïve business has been sold SOA as the silver bullet that is an answer to all their problems and that it can help bring the IT closer to the business and it's a way of thinking. Unfortunately, what has not been conveyed is the proverbial "fine print" – the "terms and conditions" disclaimer hidden away below the dotted line on which the business signs.
Having had a ground–zero view of an SOA journey set–up and the achievement of the desired objectives, it is possible, if done right, SOA can actually deliver those benefits to the organization provided the journey is embarked upon with the right tools, a deep understanding of the landscape and it's hurdles, along with a well thought plan of navigation (including alternate routes, detours, camping breaks etc.). It is the prerogative of SOA governance to ensure that the tools, map and the navigation details are all in place, not just at the start of the journey, but the entire way through. Details of these tools and other aids that are mentioned are going to be the subject of a subsequent article in this series. For now, we will focus only on the "why SOA governance" aspects.
Going back to the original thought that SOA has been oversold without the actual thought leadership on how to realize the benefits, the business team are suddenly seeing this as just another of IT's flashy ideas which promise a lot but fail to deliver to the full extent. SOA governance is charged with the role of making sure that their thought leadership, armed with the awareness of the business and its function, is able to help realize the benefits of SOA within a defined period of time.
All of us who have been part of a project under an SOA initiative will confirm that the initial projects always take more time and cost to deliver the services as compared to the conventional way of doing things. In today's world, where every business wants to save on costs, especially running and operating costs, going back to leadership and saying that we are going to take more time and it will cost more is not an option.
Without proper governance in place, the fears of the business team will soon come true and that will be the 'bring–down' as far as the Business–IT trust and alignment is concerned.
SOA governance is the bridge between IT and business; it is responsible for ensuring the stakeholders for a successful SOA journey are continuously on the same page all through the journey.
Keeping the business–side in mind, SOA governance will be able to ensure that the services being identified, specified and implemented are in line with the business view of the world, and with boundaries and capabilities that will position them as candidates of reuse in more than one instance, thereby reducing the overall TCO for the services. It is also the responsibility of SOA governance to keep the business informed about how the initial costs and efforts will be higher with a detailed view of how these will be leveled out in the mid– term, and finally be lessened on an ongoing basis in the longer term. Business needs to be in on the game, as far as this initially spiked behavior is concerned; the expectation needs to be set with them along with proper justification.
From the IT perspective, SOA governance acts as the guiding force ensuring that the work is being done in–line with the expectations being set with the business. The IT team has a sense of buy–in from the business, as long as the operating guidelines and frameworks laid down by SOA governance are adhered to. The presence of SOA
governance gives the IT a feedback loop into the business, which can be used to not only voice back concerns but also present a conduit for positive communication from IT to the business. SOA governance also has something in store for the run–time side of IT (i.e. Operations). From an audit perspective, SOA governance ensures that solutions thought out by the IT team are following the basic tenets of identifying services and gauging reuse with, or without, enhancement. It ensures that IT makes a conscious effort to try and leverage existing systems and applications as much as possible instead of trying to buy a shiny new toy at the drop of a hat.
From an entire enterprise perspective, SOA governance works towards ensuring that the various capabilities and assets strewn across can be consolidated and better utilized in a coordinated and consolidated manner to present a coherent view of the whole and its parts.
The Only H – How?
SOA governance is personified into a group of individuals who bring a techno–savvy and business–aware view of the entire enterprise. They are the people who are in the know of what their organization does today, as well as the view it takes for the short–, mid– and long–term future. These people may, or may not, be the actual stakeholders who sign the cheque out, but they are no–doubt the key influencers to the folks who do.
The individuals need to be techno–savvy to be able to always be in the know–how of the developments happening on the SOA and Integration front. They need to know the tools, products, frameworks, patterns (design and architectural) and the capabilities of the various product stacks so that they can take a judicious decision when it comes to laying out their SOA landscape. Being in the know of these technical things, they will be able to apply them to the solution and service architecture across their SOA Initiatives.
They also need to business–aware so that they are able to play the role of a reviewer and critique when auditing their SOA initiatives and the services being delivered by them. An SOA governance team will have to work with the services teams during the critical phases of Service Identification and Specification, as being knowledgeable of the business will ensure that the deliverables are in the right direction. Another reason for this is to ensure that the SOA governance team is able to help with the prioritization of services, as well as defining the boundaries of each service when it comes to laying down the service architecture. It is very common to over–engineer the identification of services, thereby leading to either too coarse services (with overlapping boundaries with other services), or too fine services (leading to services not providing meaningful purposes). This demarcation of when to engineer and when to stop is an art that is best mastered with practice, but it is like a game where with every skill earned, the next level adapts itself to the new skill levels acquired.
The Third W – When?
Setting–up the SOA governance team should be the first thing that needs to be undertaken by the organization when it first thinks of embarking on an SOA journey. This team will be at the helm of the SOA journey, shouldering the responsibility of steering the course in the right direction, and taking care of the hurdles and obstacles on the way. Having read through the "what" and the "why" above, there should be no doubt that the best time to the act together on SOA governance is at the start of the journey. No one would want to start a journey, however short it might be, in an unknown land without navigation in place. Therefore, how does an organization think of embarking on a journey as long as an SOA journey without the guiding force of SOA governance with it?
At the start of the journey, the team will be able to actively participate in the initial activities as defined in the "what" section. However, once the journey is underway, this team shifts into an advisory role putting the journey on auto–pilot. This means that every "project" under the SOA initiative will have a role that will be the bridge between the SOA governance team and the project; the SOA governance team plays more of a review role at this stage. The active role that this team passes on is the
SOA Architect role. This SOA Architect becomes an active link - playing the eyes, ears and mouth of the SOA governance team within the project and vice-versa.
This enterprise–wide view of the SOA landscape along with the multi–faceted view spanning business and IT is the most important contribution that SOA governance brings into the scheme of things, thereby ensuring that the entire SOA story hangs together and is able to deliver on the promised benefits.
There are further resources available for additional areas in SOA at: http://soaandea.wordpress.com