Information systems are complex and keeping them aligned with business needs and objectives has proven to be very challenging having, to deal with issues such as retention, compliance, availability, real-time visibility, complex event processing... in a constantly evolving business and technical environment.
SOA has been touted as a possible solution to these stumbling blocks that often prevent IT to deliver the value that the business requires. However, not all approaches to build a Service Oriented Architecture will give the same results. In his latest article on CIO magazine, Mike Kavis notes:
Implementing SOA without a solid governance model is the equivalent to having an airport without a control tower.
He suggests that when it comes to governance, we need to find the right balance between process and agility:
I have seen many companies fall into two different traps when attempting to implement SOA governance. The first trap is not having a robust enough governance model. The second trap is having so much process that it takes forever to get things done.
He argues that
- Not enough process creates chaos
- Too much process stifles innovation and deters agility
- Evolve governance over time
For instance, without an effective governance model:
SOA ...can [mean]... down systems, high development costs, unmanageable production environments and unhappy customers.
And:
To get the reuse, flexibility, agility, and ease of integration that SOA promises, design time governance must ensure that services are built in a consistent manner that provides business value, meets certain performance and security requirements, is platform neutral, and does not break anything that already is deployed.
He also suggests that Runtime Governance:
is crucial [as a] single business service may be made up of a number of components ... When that service fails, you better have the proper processes and tools in place to quickly identify the issues and to recover before your customers notice first.
So how can we be agile and enforce SOA governance at the same time?
Mike gives us some practical steps to achieve this result:
- One way is to shift from text heavy documentation to visual documentation.
- SOA governance should not be created by project managers; it is the architects that need to define it.
- like SOA, SOA governance is a journey that never ends. Start small and implement only the steps that are necessary at that time.
and things to avoid too...
I have seen where some companies have spent over a year putting all of the proper governance processes in place. That is one year with zero value added to the business. My recommendation is to include SOA governance as a critical piece of your SOA roadmap.
Governance is arguably one of the most delicate and crucial factor when building an SOA especially when you also factor in political or funding in addition to process and agility considerations. How did you go about building your SOA Governance organization and processes? Do you feel you have been successful? Why? How?