Have you ever noticed that there are two types of people when it comes to building a new toy, assembling a piece of furniture or even creating a new IT infrastructure? There are those that jump right into the assembly part while others carefully review the instructions, become familiar with all of the parts and make sure they have the right tools before they tackle the job. We all know what happens to the first group – at some point in the not too distant future (hours, days, weeks) they realize they should have read the instructions and wind up having to scrap their haphazard approach while also losing valuable time and money along the way.
It’s a similar scenario that sometimes happens when it comes to deploying a service-oriented architecture (SOA). To ensure that the SOA is successful in terms of aligning IT with the goals of the business, it’s best to read the instructions at the beginning. For example, those instructions usually include modeling business processes, fostering collaboration among IT and business leaders and establishing both long- and short-term goals before the SOA building can begin.
A Renewed Focus
Another important part of the “instruction manual” is SOA governance. As you can imagine, with myriad web services available for reuse throughout the infrastructure, there is a greater need for SOA governance. While IT has always upheld a semblance of governance to oversee the entire infrastructure’s IT processes, the level of rigor and detail around governance varies from company to company. However, governance is becoming increasingly more important as SOA is rolled out throughout the company. And with a growing emphasis on governance comes a focus on quality management within the SOA.
This renewed focus on quality management is primarily due to the fact that customers are moving beyond the pilot phase of SOA. As SOA matures and becomes more pervasive across the organization, more services are moved into production and shared, requiring the utmost in quality management and governance.
Imagine the impact on the organization and its customers if the web services are faulty or the business processes lack cohesion. One way to avoid this fate is through what is known as SOA quality management.
While it’s important to note that IT has always focused on quality, the focus has primarily been as a testing issue. However, with SOA, the role of quality management shifts because it involves business as well as IT and needs to focus not just on testing, but on the entire SOA lifecycle. To be clear, quality management in SOA is not defined as how many defects per line of code you find, but how well the service meets the business requirements.
Quality management is often categorized under the heading of governance and service lifecycle management and has been variously called function testing, automated testing or quality assurance because it has almost always focused on the testing activities of development. Quality management within SOA significantly extends that definition to be a more business driven end-to-end process.
The Quality Management Cycle Within an SOA
First, let’s understand the quality management cycle within an SOA. It starts with modeling business processes and requirements, then goes through development and testing, and later extends into monitoring the performance of services against those business requirements once the service is in production.
This idea of an end-to-end quality management process can significantly improve IT’s ability to meet the needs of the business. For example, the following illustrates how this would work in the creation of a new service.
Let’s assume that a company wants to perform automated credit checking and asks the IT staff to create a process to support this task.
IT’s first step is to perform what is known as ‘service discovery.’ Service discovery is a way of identifying whether or not an existing business process — such as automated credit checking — has already been created by another department in the company or another member of the IT staff. By conducting service discovery to gain an aerial view of the infrastructure, a company can eliminate redundant development efforts. This, of course, saves time and money in development efforts in what is known as ‘business process reuse.’ If, on the other hand, IT finds that the automated credit check service doesn’t exist, they will then begin development, creation and testing of one.
The key to understanding what business processes exist and how to create a new one lies in the sharing of that instruction manual we were talking about earlier. To truly make the most out of existing IT resources that align with SOA governance capabilities, the IT team must ensure that the instructions are available and easily understood. These instructions are called ‘artifacts’ and tell the developers all they need to know about the service.
This information includes: who owns the service, the performance requirements for the service in production, the current usage of the service, which applications are using the service, and who can see the service. Once you make the artifacts available for reuse, you can see how they will assist in maintaining the high quality of the service throughout the company so that best practices truly are shared.
It’s important to note that quality management of a service continues throughout the life of a service to maintain quality and consistency. This is where IT needs to keep in check with the operational artifacts to make sure that the service is being followed. In a more easily understood scenario, you all know what happens when several team members revise a document and it soon looks nothing like its original form. A similar situation can occur once a service is in production. This is why IT needs to conduct continuous monitoring to make sure the service meets the established business requirements.
While governance and reuse are two of the most compelling reasons to embark on an SOA journey, it’s critical to ensure the quality and consistency of the services that are used throughout the organization to avoid the sharing of worst practices.
About the Author
Scott Hebner is a Vice President of Strategy, IBM Rational, IBM Software Group.
