Original URL: https://www.theregister.com/2007/05/25/tibco_soa_governance/
A primer on SOA governance
The ground rules
Posted in Software, 25th May 2007 10:15 GMT
Interview TIBCO's Stefan Farestam talks with Reg Developer about the ground rules of SOA governance.
What do you understand by SOA governance? Surely, it's just a question of corporate governance generally – automated business processes should be subject to the same controls as are applied to any business process?
On a high level that is certainly true but what's challenging with SOA, from a governance perspective, is its distributed and potentially heterogeneous nature. This makes it particularly difficult to establish SOA governance in a controlled and homogeneous fashion and without these two prerequisites being fulfilled, any good intentioned governance initiative rapidly breaks down. So SOA governance in my book encompasses all components of the SOA infrastructure in that it is instituted in a controlled and homogeneous fashion.
OK, how big is this issue then; and where does it bite?
A simple guideline is that it bites as soon as your SOA infrastructure contains components critical to your business. This is why we typically see governance appearing as SOA initiatives progress from the departmental to the enterprise scale, but it could become an issue immediately after your first service goes live.
Is it big? Absolutely. Since one of the core value propositions of SOA is to create a more dynamic environment for services to interact and to encourage reuse of services, controlling how these services interact with each other has a huge impact on both the long-term ROI and manageability of any SOA initiative.
What governance questions do organisations need to ask? How do they establish where they start on the governance ladder?
SOA governance can never be an after-thought as it can be very expensive to institute governance on an infrastructure that is not designed for it. Governance, therefore, has to be a core feature of any SOA initiative from the start if it is targeted at containing business critical services.
So the core questions should be focused on establishing a timeline for when to start using the various components of the governance infrastructure. This, in turn, should be guided by which level of control and agility is desired and required during the different phases of growth.
Although technology is an important part of governance, and an enabling component, personnel training and operational procedures are ultimately the key factors for success. It is therefore important to start using the various components of governance early so that skills and procedures are in place well ahead of the time they are strictly required.
Can you talk about service management and what it means in this context?
Service management has a design-time and a run-time perspective. During the design-time, a registry of available services and a repository of service assets assists greatly in establishing reuse and should be some of the very first governance components put in place.
Run-time services management, however, is traditionally not a part of SOA governance as it is handled, typically, by the technology platform that the service is deployed within. While not being an issue in the initial phases of an SOA deployment where services typically are only contained within a single technology platform, this rapidly becomes a huge challenge when services are contained in heterogeneous platforms.
To address this challenge TIBCO has pioneered a new technology called service-virtualisation that enables run-time management of services across heterogeneous platforms.
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.
How would a small company, perhaps a net consumer rather than a provider of services, relate to SOA Governance?
If the company is a net consumer of SOA services from other business partners then governance is of tremendous value as it can be used to enforce service level agreements and to validate both service requests and service responses. Reversely, SLA monitoring could be used to establish premium prices for higher service availability or response times.
What are the (internal) roles and responsibilities involved in SOA Governance?
Since SOA governance needs to be planned and implemented along with the SOA infrastructure it makes a lot of sense to bring the two together, typically by establishing a SOA Centre of Excellence that is responsible for enterprise-wide planning and assists in execution. However, it is also advisable to separate the roles of the SOA architect and the governance architect since conflicting interests may sometimes arise.
In terms of responsibilities, anyone touching the SOA infrastructure needs to be properly trained to ensure that governance guidelines are followed.
Do you see SOA Governance as primarily a technical issue, or a cultural/business issue?
It has to be both since you want to focus your governance efforts on things that matter from a business execution point of view and not just pure technical compliance at the SOA infrastructure level.
When I was at QCon recently, I asked Burton Group Analyst Anne Thomas-Manes about the issue of the 'dark path' in SOA – what happens when one of a group of services contributing to a business operation fails and you have to sort out the mess? Is this dark path ever properly designed and tested? She said this was simply a governance issue. What are your views on this?
If by failure we mean that the service produces non-compliant data (as a part of a request or a response), then properly implemented governance can certainly help you by imposing schema validation, checking of digital signatures etc. However, pure operational failure would normally be handled in other ways. Logging, tracking and auditing can help you sort out failure in a post-mortem fashion, but halting erroneous operations as they occur is where most value is to be gained since corrective business processes can be invoked immediately.
You have a service virtualisation technology called Active Matrix. Surely, this is just a neat technical solution to building SOA effectively. How do you see virtualisation generally (and, perhaps, ActiveMatrix specifically) as contributing to SOA Governance - if you do?
Before addressing that question I think it's worthwhile pointing out that by service virtualisation we mean a technology that separates all aspects of the operational environment that a service executes in from the core logic of the service. This means that no aspects of governance and policy management logic, such as encryption, authentication, schema validation, routing etc is contained within the service itself but rather configured externally. What this means is that control of how governance is applied and operated can be transferred from programmers to operational staff, which is where governance really should be handled. However, it also means that no aspects of governance are contained in code, where it rapidly becomes invisible and unmanageable but rather transferred to configurable governance policies that can be managed as proper assets.
So, service virtualisation holds great promise in alleviating many of the core pains that are currently associated with implementing governance in a consistent and manageable fashion while easing the pain for those who implement the core service logic. By doing this, it also enhances the prospect of services being reused since the core services have no internally embedded policies.
With ActiveMatrix, we have taken this concept several steps further and also made it technology and deployment neutral. In clear, this means that we can mix .Net services with Java services in the same OS-process or in a distributed fashion while imposing governance policies on every single interaction between services. We do this by complying with the JBI standard and the emerging SCA standard, but extending it beyond Java to .Net, C++ and scripting languages and embedding governance at the core of the platform.
What are the critical success factors for SOA governance?
The most critical success factors are (a) to start thinking about it early and before it becomes an operational imperative, (b) to view governance as a moving target where policies have to be managed as entities with their own lifecycles, and (c) to choose a technology platform that can help you address your immediate governance needs as well as those that will appear as your SOA infrastructure scales.
And, how do you know you've achieved it?
Although it is conceivable to set up objective goals for achieving SOA governance, I think it is more meaningful to measure how well the internal goals for governance have been met. This is typically done through an internal audit. As the SOA industry matures further I am convinced that automatic tools will be created that can help in automating at least part of this audit.
How do you communicate your 'state of good governance' to third parties such as business partners and regulators?
That's a tricky question. External parties care mostly about the rules, regulations, and agreements that your business has to comply with, but not the governance that you institute to run your business better. However, while the former leaves little leeway, since you typically just state your compliance status, the latter means you can proactively embed governance in your business and show your customers by action rather than statement that you take governance seriously.
Finally, what is the single biggest barrier to SOA governance, in your opinion? And the single biggest enabler?
Despite representing a technology vendor, I would definitely say that not realising the need for governance is currently the biggest barrier. However, governance technologies in general and service virtualisation in particular are key enablers to make governance happen.
Dr Stefan Farestam is regional director customer marketing EMEA at TIBCO. Prior to joining TIBCO, Dr Farestam was the co-founder and CEO of IGIS, one of the first internet start-ups in Sweden where he pioneered the use of web technology for intranets in major corporations.
Dr Farestam holds a PhD in Computational Fluid Dynamics from CERFACS/Institut National Polytechnique de Toulouse (France) and an M.S. in Engineering Physics from Chalmers University of Technology (Sweden).