Efforts and resources have to be spent on establishing the infrastructure that provides on-demand visibility into the quality of the underlying artifacts. When you decide on a change in a system, its impact has to be analyzed immediately in terms of what existing services are going to be affected and what business processes rely on these services. What this means is that while the change is being worked on, developers have to be able to execute the relevant tests and validations immediately on the components that are impacted directly by that change.

This is achieved by instituting process sensors at different points in the life cycle to ensure quality at each of these points. As soon as the change activities commence, modifications to code or any service metadata artifacts (such as WSDLs and BPEL models) are validated, and regression tests are executed at the code, service, and business process layers to detect undesirable side effects or deviations from the existing functionality. Such multi-layer process sensors are similar to a manufacturing assembly line. They ensure that whatever is produced consistently adheres to established quality standards. These sensors also provide the on-demand visibility needed to achieve full situational awareness and quality measures anytime during the process. So let’s talk a bit more about these sensors and how they’re applied.

Design and Development Policies
Quality is best defined with a consistent policy. Just like runtime security requirements, or how service use and availability are described with policies, quality can also be asserted with a set of declarative policies. Such quality policies, which I’ll refer to as design and development policies, define how the various artifacts are changed and produced, and what standards and rules they need to adhere to. For example, a policy may specify that developers with a certain role review code changes before they’re committed to a certain source control system; and according to the policy, the code changes need to follow certain maintainability rules, WSDLs need to pass WS-I BP compliance, messages must use a certain version of SOAP and adopted WS-* specifications, and schemas must adhere to a set of best practices around design and type definition. These policies essentially define the structural requirements of the artifacts; as they’re enforced and measured with proper sensors by the underlying infrastructure, they prevent certain defects or interoperability issues from getting into the system.

Functional Regression Tests
Regression tests are what ensure that what worked yesterday is still working today. To capture system functionality best, they need to be applied at several layers: the code/class layer with JUnit or NUnit tests, the service layer with functional operation tests, then the process layer with tests that exercise the end-to-end transactions as defined by the various business process use cases. Once these various test assets are created, they’re maintained and evolved along with the application artifacts. As they execute continuously and automatically in the background, they ensure that when a change takes place it didn’t break any existing functionality. However, the key here is that these tests are created and maintained to be automatically runnable. To the largest extent possible, regression tests shouldn’t consume time or resources to be executed, only to be created and maintained. This is a critical principle that, once applied successfully, provides a huge improvement in both process agility (in terms of rapid delivery), and test coverage. I’ve seen Fortune 1000 organizations achieve high double-digit gains on these two fronts.

System Performance
Like quality, best practices, and functionality tests, performance validation can be executed in a continuous fashion to provide up-to-date results. This is an alternative to leaving it as an activity at a later integration cycle, which often leads to surprises, delays, and unpredictability. When load tests execute against isolated parts of the system, even in the development environment when changes are being made on the system day to day, the quality-of-service metrics can be monitored for any abnormal deviations. The absolute metrics around the desired performance of the system in a development/test environment is certainly different from the live system, and they’re hard to determine. However, that’s not important. What’s important is to capture a baseline of these performance metrics (such as execution times, memory utilization, etc.) and have the subsequent load test run results compared to that original baseline. Once this is put in place, performance side effects or configuration changes in the application would be detected immediately and addressed. The lack of such immediate detection and on-demand information results in errors being caught much later, when analyzing and resolving becomes harder and more time-consuming, and when uncertainty is introduced.

SDLC Process Automation
The various activities of the development process, such as build and deployment, change management and issue tracking, code reviews, and the collaboration activities among the various stakeholders such as audits, approvals, and release procedures, need to be defined and automated as much as possible. In the end, the activities handled by people are the most time-consuming activities – especially when several stakeholders are involved. Therefore, the extent to which these activities can be defined and driven via an automated set of processes to facilitate the collaboration among people will significantly impact agility and the accuracy with which these activities are carried out.

Quality Visibility
With these practices in place, measurement can provide the on-demand SDLC process visibility. At any time, an architect or a manager should be able to know the current quality status of an artifact, at the code level or the service contract level. This visibility is best achieved in SOA by feeding these metrics directly into the service registry so it’s associated with the related artifacts. For example, not only would the registry show the metadata around a service such as dependencies, access controls, and quality of service metrics, but also quality metadata such as test coverage, adherence to interoperability, and organizationally established standards. This is particularly important since service registries today have evolved to take a role in the life-cycle process of a service. This helps the various stakeholders manage the life cycle so that quality visibility – serving as a health check for the service – is what provides the triggers to promote the service from one state in the process to another, or instills confidence in the stakeholders that it has met the quality criteria needed to go live.

The lack of visibility and an objectively measurable process can lead to the organization and its partners simply not reusing the business components. This lack of trust, which is reasonable when dealing with mission-critical business process, will deteriorate the efficiencies that the SOA model promises.

Conclusion
When information is always available, instantly and ubiquitously whenever needed, tasks can be done quickly, easily, and with a high level of accuracy. On-demand information lets you quickly adjust to changing needs and provides alternative choices with little overhead – as long as you have the necessary information readily available and visible.

For an agile service-oriented architecture, ubiquitous and on-demand information can be readily available via various process sensors that can be applied throughout the SDLC. Design and development policies, functional regression tests, system performance metrics, DSLC process automation, and quality visibility all provide the necessary information to ensure that your SOA remains agile.