In one of ZapThink's recent Licensed ZapThink Architect courses for a US Department of Defense (DoD) contractor, we were discussing service-oriented architecture (SOA) quality. I pointed out that as a SOA implementation matures, it becomes increasingly important to manage quality continuously over the full service lifecycle, as the agility requirement for SOA reduces the practicality of focusing quality assurance solely on pre-deployment testing activities. The students then pointed out that the DoD requires that they put any new software implementation through six months of rigorous acceptance testing before deployment. Clearly, these two views of quality are at odds, and beg the question: which has to give? Can the DoD or any other organization implementing SOA have to sacrifice either agility or quality in order to obtain the other?

Best effort SOA quality
The answer is that no, such organizations don't have to sacrifice quality to obtain agility, but rather, they must rethink what they mean by quality in the SOA context. As ZapThink has discussed before when we explained the meta-requirement of agility and the SOA agility model, the agility requirement for SOA vastly complicates the quality challenge, because functional and performance testing aren't sufficient to ensure conformance of the SOA implementation with the business's agility requirement. In essence, the business isn't simply asking the technology team to build something with capabilities A, B, and C, but is also asking them to build something flexible enough to meet future requirements as well -- even though those requirements aren't yet defined.