After design time and runtime comes change time, the most important stage of the lifecycle in a service-oriented architecture. Services have to operate in the real world, where nothing can be taken for granted and nothing is set in stone. That's why they have to be loosely coupled. Change is inevitable, and sooner or later usually sooner, of course services need modification to adapt to new requirements (what I called "the uh-oh moment" in a previous blog posting on this topic). The lifecycle of a service is a continuous loop of build-test-deploy-redesign.
Unfortunately for anyone building an SOA, conventional software tools do a poor job of catering for the change-time phase of the development lifecycle. This is a problem, considering that change-time represents the entirely of the lifecycle except for that thin sliver of design time before a service is initially deployed. Only now, however, are we beginning to see products coming out that begin to address the need to manage change-time modifications.
This week, for example, AmberPoint introduced its SOA Validation System to plug the gap that currently exists for adequate testing of change-time deployments. Conventional testing tools from vendors such as Mercury Interactive and Parasoft work fine for testing new software builds at design time, but they have no facility for testing the impact of introducing that new service into an existing SOA infrastructure. Are enterprises supposed to close down their entire SOA infrastructure for testing every time a new service is introduced? That would be absurd, obviously. But if there's no mechanism for testing the runtime impact, the only other alternative is to bring up the service and keep your fingers crossed. That's not much of an alternative.
AmberPoint's product captures actual request-response traffic on a live SOA and then mimics that traffic for testing purposes. The new service can be tested against the peaks and troughs of activity seen in the live system, and it can be tested against captured traffic from external or shared systems that would otherwise not be available for testing purposes.
It's not just new or redesigned services that need testing. Simply changing the configuration of a service may have unforeseen consequences. "The reality is, policy changes are as important and potentially as crippling as code changes are," AmberPoint's VP of marketing Ed Horst told me when we discussed the new product last week.
This reality isn't holding back other vendors from pressing ahead with products that aim to empower business users to change policy on the fly. Infravio last week launched the latest version of its X-Registry SOA governance product, pitching it squarely at the change-time opportunity. It simultaneously unveiled a new website and a marketing makeover that runs with the tagline "Real World SOA". That's the same real world that I mentioned in my opening paragraph, the business-driven world in which change is inevitable and which demands adaptability and agility from its IT infrastructure.
Infravio has a diagram on the products page of its new website that puts business users in charge of change time, while developers remain responsible for design time and good old IT operations are left holding everything together at runtime. "What SOA is really all about," Infravio's VP of marketing Miko Matsumura told me in a phone call ahead of the launch, "is creating a model of business computing that creates a very rigorous separation of concerns." Infravio's product provides a complete infrastructure to support cataloguing, compliance and governance across each of those separate areas of concern. It reflects the state-of-the-art in SOA today, and underlines why IT has to start getting its head around all the manifold implications of managing the change-time stage of the services lifecycle, with all its potential for unforeseen and unintended consequences. The rise of SOA governance is creating an environment in which whatever can go wrong will be logged, documented and attributed to the person nominally responsible when it does go wrong.