About Governance in an SOA Strategy
Whenever I have been asked about the key success factor of an SOA strategy, my response has always been quick: Governance.
And most of the time I noticed in the gesture (or absence of gestures) of my interlocutor the feeling that I had just thrown one of those terms that seem empty of content, or one of those buzzwords that are fashionable and used without really knowing what it is.
And I’m worried that this idea is so widespread, because it is not so difficult to find online very good explanations of what it is and its importance.
For a start, I highly recommend this link. For my part I am going to do my bit, trying to help you use this term correctly and above all, knowing its importance.
We have already said sometimes that SOA focuses primarily on how to do things, and not so much on what tools should be used. But dealing with how to do things necessarily requires establishing what things are to be done, and which are not. Establish the order in which they are made, the moment they are made, and finally, the way they are made.
In a first very simplified approach we are already sketching out the concept of Governance. It is all the definition of what has to be done, what has not, when it has to be done, who have to do it, and how it has to be done. And this action must be constant, and must be very present at all times in the Committees of Change Management, Monitoring Committees, Steering Committees, etc., etc. It must support the decisions of the ICT departments.
Its importance becomes evident if we think about the consequences of its absence or deficiency. It is very well explained in the link I just shared with you some lines above:
- One team decides to publish a service, considering it’s interesting to have it available to third parties. No one tells them how they should do it, so they define the service the best they can for the use they think it may have. They may design it prioritizing its quick deployment, or its compatibility with the technology they are using, etc.
- Regardless of whether that service is used by someone or not (in fact they do not know precisely), one day they have to turn it off, or even just change it. Maybe because they have to replataform their system, maybe because there is a change in scope, maybe because the team behind that system changes and the new team does not know that service exists or what other systems may be using it.
- An indeterminate number of systems begin to fail. They had based some of their functionality in that service they found posted, and now that service is down, they have problems.
Disaster as you can imagine is important, and disaster recovery is another equally important disaster. Some may think that what has been lacking here is coordination. And you would not be wrong, there has been a lack of coordination of course, but not only that. Much more has been missed, starting with a strategy. The mere existence of a strategy (whatever) is already a step forward in any IT scenario. A phrase that struck me as I prepared for BPMN certification said something as obvious but as important as this: “A strategy allows aligning efforts to achieve goals.” It seems obvious, right? Well think about it, you will surely find examples in your experience where surprisingly there is no clear strategy defined (and if there is, it is not noticed, which has the same effect).
When it comes to interoperability, the existence of a strategy is an essential basic requirement. And SOA as a strategy brings everything else that is needed for that strategy to be optimal. And that “everything else” defines and conforms SOA Governance:
- Interoperability rules, precisely defining how the interoperability requirements in the organization’s IT projects should be addressed, what the approach is, what different information systems should take into account in order to fit into an SOA scenario that allows cost reduction and streamline processes. Which practices are prohibited, which practices are recommended but not mandatory and which are obligatory.
- Life cycle of services, procedures, methodologies adapted to an SOA strategy, mandatory templates, security policies, error management, etc.
- Indicators to be measured and audited to ensure compliance with established regulations, mandatory test plans, etc. Trace of all published services, providers and consumers of the services, their versions, their status, etc., etc.
You might be thinking that all this is necessary in any case, not only in an SOA strategy. Well, maybe you’re using an SOA strategy and you do not know it. I doubt it, but I would understand that you think I’m not discovering the fire or inventing the wheel, it’s totally true. I remember what I said at the beginning of this blog: when you list the good practices promoted by an SOA strategy, they are surprisingly obvious, but also surprisingly absent … at least with the appropriate approach in an interoperability scenario that aims to be viable, sustainable, scalable and economically profitable. Here is the difference.
When we visit the anti-SOA patterns we will have occasion to see clear examples, but even taking into account everything we have just said, it is possible that we are misusing these good practices. We will try to concretize it in future entries, to avoid the effect “of course”. Yes, I just invented this: with the effect “of course” I mean those times when someone explains something, and ends up asking “did you understand?”, And everyone nods with a “of course.” Then everyone goes back to their workplace, and then something happens that shows too late that there were as many interpretations as there were people present. And no right one. Minutes help to avoid this, but even that has to be done right, because a bad minute is of no use. We will return to this in future entries.
Resuming Governance, let me once again emphasize that it is an indispensably continuous, uninterrupted process that cyclically must be capable of self-monitoring and updating as the organization’s context, progress, and maturity evolve. Here you have a proposal based on the work of Open Group that shows this endless cycle:
The need for this constant regulation, in constant review and monitoring, the need for such monitoring of compliance, and specially the need to ensure a correct approach in abstraction, granularity and orientation to business processes (what should become a service and what should not become a service), imply the need to form a high-level strategic team, with an optimal approach both to the business and the SOA mindset, to be a binding decision-making team for all projects, that implements the strategy ensuring the coordination and perfect orientation of all IT projects involved in interoperability scenarios. In the links that I have included in this post they call it “Center of Excellence” and I think it’s not a bad name, because that’s exactly what it should do: guarantee excellence in executing the SOA strategy.