Johannesburg, 16 Jul 2009
Should governance mechanisms be put in place before services-oriented architecture (SOA) gains momentum, or should the investment in time and resources for governance wait until there is something to be governed? It`s a question that is sparking debate in SOA circles and one that Rick Parry, MD of Progress Software South Africa, is unequivocal about.
It all starts with defining SOA, but if you ask 25 people for an explanation, chances are they will all have something different to say. Primarily though, it`s important to bear in mind that SOA is not a technology, a product or even a series of products.
When you embark on an SOA project, the first thing to do is take a step back from any discussion about product and focus on obtaining a clear understanding of SOA, define what your organisation expects from SOA, and ascertain why you are even talking about it. Only when you have completed that process should you start to look at products.
So, if SOA is not a piece of software, what is it? Quite simply, it`s a strategy; a concept, which recognises that in the world of IT software delivers functionality that can be broken down into a series of interoperable services.
SOA "success", in this context, does not have to mean anything other than a shift in mindset. SOA separates functions into these distinct services, which developers make accessible over a network so that users can combine and re-use them in the production of applications. These services communicate with each other by passing data from one service to another, or by co-ordinating an activity between two or more services. Very many successful SOA implementations can happen without too much influence from the technology side.
As organisations embrace SOA, however, they have to be careful that the services consumed across the enterprise do not mushroom out of proportion and beyond control; this could bring the entire system down at times like month-end, when large numbers of people place a huge demand on the IT environment as a result of all the services they are consuming.
This is where the importance of SOA governance becomes apparent. It`s all about control and visibility. Governance is associated with the number and type of services being consumed. If you neglect to implement SOA governance from the very beginning of your SOA initiative, trouble is inevitable. You do not want to be in a situation in which you try to govern an SOA that has already been put in place. Putting controls in place from the outset is an approach that applies to any project an enterprise embarks on, and it`s no different for SOA. SOA governance is vital if you want to understand what you want from your SOA, what the business benefits are and what the outcomes will be.
The main benefit of SOA governance is that it addresses three critical business questions:
* How can you monitor what`s going on in the heterogeneous, distributed SOA environment, to find and resolve problems quickly?
* How can you know and ensure that your SOA business processes are delivering the right level of customer service?
* How can you guarantee that all services are secure and compliant with appropriate regulatory and business policies?
Life cycle governance, which implies governance from the outset, enables design-time policy authoring and checking to ensure that services comply with industry and corporate standards, and perform well in production.
Runtime governance provides automatic transaction visibility, monitoring, and policy creation and tracking - elements that are critical to process adherence, measurement, and enforcement. Should you neglect to enforce this approach from the outset of your SOA project, you will forever be playing catch-up; and in today`s business environment, that spells chaos.
Share