My parents expect to spend a certain amount of time and effort managing particular aspects of their lives. For example, when they drive to an unfamiliar vacation spot, they inquire about directions and even write or plot the route before they head out. Whereas for me, it’s a matter of popping out an iPhone or a GPS device, saving time, improving accuracy, and avoiding the mistakes of manually drafting the directions.

The same on-demand principles apply to the SOA life-cycle evolution. When an infrastructure that allows for changes on-demand is established, you need the agility to execute on them quickly and safely while preserving the quality of the overall system. This is a challenge that organizations face – attempting to change their underlying SOA systems without compromising existing business processes. However, this challenge can be solved with ubiquitous on-demand information.

Safe SOA Evolution
The fact is that you almost never start anything from scratch. Instead, you’re always evolving what you already have. So the key to an agile SOA is to look into the various change activities that combine in a service life cycle. These change activities include change inception, change elaboration and impact analysis, construction, and finally, transition into production.

There are three important points here: first, you can’t afford to spend time and resources repeating the same manual activities associated with each of these phases every time a change is needed, such as changes to the environment or testing and impact analysis. Second, the change processes are increasingly iterative; the days of the waterfall model, starting with requirements and design and ending with testing, are gone. Third, the phases I listed – which are mostly based on RUP (Rational Unified Process) – don’t include testing as an isolated phase. In fact, you should never have an explicit, sequential testing or validation phase if you want to have an agile, quality process that produces quality results.

The more time you spend doing tests on changes made in your underlying systems, the more you are likely to compromise the agility of your SOA, and risk quality and continuity.

Quality needs to be baked in. You don’t test it out of an application. I’m by no means suggesting that you shouldn’t test and validate, but the process of testing and validating against established policies needs to be continuously applied throughout the SDLC process, and information pertaining to these policies must also ubiquitously exist, on-demand, in the underlying environment. Just like when you’re driving, you wouldn’t pull out a piece of paper to draw up a new map every time the route or destination altered; you simply know where you are and have full situational-awareness then you set the new goal to get there from where you are. The same principles apply to the SDLC of software in general, and SOA in particular, because SOA’s main goal is to increase agility.