When organizations establish a Service Oriented Architecture (SOA) strategy, the governance model is usually not the first thing on the to-do list. However, it should be. Many organizations rush into SOA with a flurry of activities. Typically these are technical efforts: everything from putting an Enterprise Service Bus in place to adding Web Services interfaces to a business service.
Because even simple SOA projects can have positive results for the business, it is not surprising that organizations want to “cut to the chase” without thinking of the consequences, and in particular of the management requirements of a SOA implementation. The way to manage the SOA environment is through SOA Governance.
In brief, SOA Governance is the process of determining how to create SOA-based services that conform to business standards. For example, let’s say you create a service that conducts a credit check. The service has been designed to meet the needs of the business. Who is allowed to make a change to that service? Can any developer with a tool change it to fit another requirement? Is it alright to have five different versions of the check credit service? Who within the business confirms and signs off on the service?
Many organizations have not started to think about the process of constructing and managing services. This is quite dangerous because it does not just impact the IT department but the integrity of the business itself.
A Hypothetical Example
We think this is already happening without companies being aware. Let’s walk through an example:
An insurance company has made the decision to implement a SOA strategy in order to better leverage its IT assets and make the business more productive. There is top level approval both from business executives and IT. A project is selected as a starting point. The organization decides that the claims processing operation will be an ideal pilot. A team consisting of IT professionals and claims practitioners collaborates and creates five business services that make it much easier to accommodate new business partners and to create new business initiatives without creating new applications from scratch. After the first three months, it is apparent that the rewards are great. The company is able to implement new business ideas in weeks rather than months. The project is a showcase.
Now, things start to go wrong. Several enterprising claims processing analysts take an existing business service and modify it so it can be used in one very different opportunity. In another situation, a developer adds a different variation into the mix and inadvertently changes a key business rule that determines the amount of commission paid to a partner.
Looking at this scenario makes the problems appear obvious, but when things start to go wrong, it will typically take an organization a long time to discover what has been happening. Are the individuals involved doing something illegal? Are they being deceptive? No, they are merely being pragmatic; taking advantage of resources and assets that have been successfully used already and “improving” upon them. They have not been given training on what a business service actually is and what the procedures are for changing a service or augmenting it.
The Bottom Line
Right now there is very little understanding that SOA governance is an important enabler that makes SOA safe for business. The well meaning practitioners are simply unaware that SOA needs to be managed both as part of IT governance and as a subset of corporate governance. This understanding does not happen without a set policy and set of best practices designed and an appropriate business process to manage it.
SOA governance is an essential element to making SOA safe. Ignore it at your peril.