The users love the ease with which they can access all this information and conduct their daily tasks. Now that they know what is possible, they want more and you are ready to give them what they want. After all, you have just proven that SOA is more than a mere buzzword.
However, no one has yet told you there is a problem.
This initial, highly-successful project has introduced a new level of complexity into your IT organization. Monolithic and heterogeneous applications running in isolation for many years have suddenly become crucial components in a more complex organism held together by the principles of SOA (service orientated architecture).
The IT architects have very detailed architectural diagrams to describe it all, the developers wrote thousands of lines of code to make it all work and the integration team has configured a complex web of message infrastructure to ensure that every message is guaranteed to be delivered to the right application … What could potentially be amiss in this picture?
To illustrate let me pose a few questions:
By using the principles of SOA you have been able to solve a complex problem and by doing so introduced additional complexity into your IT infrastructure. The challenge that you now have to face is how to manage that complexity.
Approach
SOA Governance is a discipline which in an ideal world should be established early on in the SOA life cycle. Yet, it is never too late to implement good policies, procedures and technology to assist with the management of the freshly implemented SOA project.
Consider governance a best practice whereby one transforms lessons learned into sound policies, guidelines and procedures with the aim of establishing a mature SOA ecosystem.
Here are five guidelines I consider essential to good governance:
Establish an SOA competency center. This is a cross-functional team of key people that represent different disciplines within IT. By establishing such a group you facilitate communication between the various groups, ensuring that everyone is represented and that every aspect of the SOA Architecture gets proper consideration.
Furthermore this group can be instrumental in establishing organizational standards, setting guidelines and creating blueprints. This core group can also disseminate knowledge to new groups that need to adopt the SOA approach.
Experience is a good teacher. Blueprints and best practices can be very good teaching mechanisms. They are a tangible way in which everyone involved in the SOA implementation can benefit from the work that has been done before.
Too many times development teams have to “reinvent the wheel” in order to solve a particular problem. Identify and document those solutions that work well and turn them into patterns that can be used repeatedly.
By making a particular approach repeatable you are able to reduce risk, shorten development time and also decrease the cost associated with the overall project. Likewise, it may be just as important to document those approaches that don’t work well or which may have failed. By documenting these so-called anti-patterns one is able to prevent mistakes from being repeated.
Use an SOA repository. Services are by definition reusable and self-describing, but don’t be deceived by this oversimplified view.
If services are not properly documented and made accessible in a consistent manner, they could become just as unusable as some of those legacy applications.
Accomplishing such simple tasks as establishing the exact nature of a service, obtaining the latest service description or determining the owner of a particular service may become quite a daunting task if services management infrastructure is not put into place. This is where an SOA repository can play an important role. It can become the focal point where all services can be documented, searched and accessed.
Monitor quality of service (QoS). Bring predictability to your SOA by implementing service management facilities. What you need is the capability to maintain end-to-end visibility into your services infrastructure via the ability to define SLAs (service level agreements), measure services operation & response levels, analyze service usage & resource utilization patterns and proactively be alerted of potential and imminent service failures. 1.1
Stability is the hallmark of a mature system and through the effective management of your deployed services (and related infrastructure) you can bring a great measure of stability to your SOA.
Manage the SOA life cycle. Create a disciplined and well managed SOA life cycle. In all other areas of IT this kind of discipline is well established and maintained. SOA should be no different.
Implement tools and procedures that will help manage the services development, testing, quality control, deployment and maintenance processes. 1.2
As part of the life cycle create a services approval process, ensuring that services are tested for standards compliance and services are put through a comprehensive vulnerability, interoperability and regression testing process. Implementing these measures will assist in elevating the overall maturity and robustness of your SOA implementation.
Implementing an SOA entails more than just implementing a few services or using an ESB (enterprise service bus). SOA may start out simple, but it inherently introduces complexity into the IT organization. This is mainly due to the nature of the problems that we are attempting to solve.
Acknowledging the complex nature of SOA and taking the appropriate steps to manage this complexity is a crucial step toward the successful development, implementation and maintenance of an SOA. My advice is to plan for SOA success. Plan to be hugely successful and in preparation, consider how you will govern the next generation of business applications.
Theo Beack is Software AG’s chief SOA architect and director of the company’s SOA Competency Center.