A primer on SOA governance
The ground rules
OK, but when you say that a service registry service and an asset repository should be the 'very first governance components put in place', doesn't this assume that an appropriate degree of organisational maturity and agreed governance policies have already been implemented? In other words, the implementation of good service management governance should start even before (and independently of) any technology purchases – is, perhaps, a 'governance committee' with appropriate responsibilities and reporting lines, the very first thing to put in place?
That's a great point. Many companies achieve this by creating an "SOA Centre of Excellence" that initially focuses on establishing SOA organisational guidelines and later assumes responsibility for coordinating technology selection as well as creating a delivery organisation for building the SOA infrastructure.
Martin Banks has asked me about the impact of all this on developers - SOA governance implies real time monitoring of events associated with service failures and equipment failures in a BSM (Business Service Management) framework. Do you expect SOA developers to have to build service-level instrumentation into their code and/or hook into operational management systems such as HP OpenView - or is this managed as an entirely separate layer?
We believe service virtualisation is the key enabler to achieve separation of governance from core service logic. It doesn't make sense for SOA developers to embed governance logic in code and, personally, I don't think most programmers are particularly thrilled by the prospect of doing so either. So, in short we propose that by adopting a service virtualisation solution governance can be managed by operational staff.
Is this something you can develop in-house? What is the role of external consultants? What are the issues associated with not doing this in house (in whole or in part)?
Developing core SOA governance technology would probably not make sense for most organisations at this point in time, given how complex the SOA technology stack has grown. External consultants can help out here by guiding the organisation in which part of governance can be addressed by technology and what the right technology mix is between off-the-shelf governance software and in-house, custom technology. As in most cases of in-house development though, the customer needs to figure out which business they are really in and if governance software development should be a part of the core business.
What stages should an organisation go through when developing an SOA governance infrastructure?
The first stage is the realization that they need governance at all. This may sound obvious, but many SOA initiatives progress to the point where pain, rather than forward planning, is the guide. So first, ensure that all parties involved accept the need for SOA governance.
In the second stage the organisation needs to address the two questions raised above - what must be done and how can governance be leveraged to improve business execution.
The third phase is concerned with figuring out the right mix between technology and changes in organisational behaviour to fulfil the desired need for SOA governance.
It's only when you reach the fourth phase that technology selection and implementation becomes the focus. Fortunately, the individual components of SOA governance (such as authentication, encryption, auditing, validation and logging) are fairly well defined and it's more a matter of decomposing the overall governance requirements into appropriate pieces rather than having to invent custom governance solutions.
Sponsored: Navigating the threat landscape