Friday, September 01, 2006

SOA software quality and governance article

Here is an interesting article on SOA quality and governance. Particularly interesting insight into the changed requirements for quality management.

Traditional software quality management essentially consists of design time and deployment time activities. Basically, given the requirements, make sure that the software is as defect-free as possible given budget and schedule constraints, and then continually monitor the working software to make sure that it meets the requirements set out for it when you deploy it. That basic approach to quality is fine for organizations that know in advance what their requirements are, when those requirements are stable, and when the goal is simply to build software that meets those requirements.
Such assumptions, however, are frequently false -- in many cases, requirements aren't fully developed and they change over time. Typically, one true goal of software is to respond to changes in requirements without extensive additional rework. SOA is a particularly effective approach in such situations, and the broad recognition that the build-to-today's-requirements approach to software is no longer effective is one of the primary motivations for SOA.
Quality management at runtime is part of the answer, to be sure. Maintaining the quality of service of running software, whether or not it's abstracted as Services, is a key part of the systems management value proposition. What SOA management adds to the picture is runtime management of the Service abstraction, which is different from management of the underlying Service implementations. Managing the Service abstraction requires quality assurance for certain kinds of ongoing requirements changes, in particular, nonfunctional requirements like performance. Effective SOA management also requires runtime exception management handling in order to reduce the cascading impact of defects and to maintain loose coupling.

Software quality assurance testing services