In our book Service Orient or Be Doomed! ZapThink explains the metarequirement of agility that underlies every Service-Oriented Architecture (SOA) initiative: the requirement that the implementation of the architecture must be able to satisfy future requirements even as they continually evolve. A core challenge of SOA, after all, is building for change. If you had good reason to believe today's requirements were permanent, you probably wouldn't bother with the expense and complexity of SOA.
What, then, is your metarequirement of agility? As we also detail in our book, it doesn't make sense to expect that the IT organization would be capable of building systems that could deal with entirely arbitrary change, since such a requirement would be prohibitively expensive to satisfy. Instead, each organization will have to decide for itself precisely how much they can invest in order to achieve the level of flexibility they require their SOA implementation to have. While deciding on your agility metarequirement is an essential part of your SOA planning, even more important for the long-term success of your SOA initiative is in ensuring that your SOA implementation conforms to that metarequirement over time. In other words, guaranteeing that your SOA meets the needs of the business over time is a core measure of quality, and as such, SOA quality assurance must address the metarequirement of agility.
Change time qualityTraditional 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.
While many existing SOA management tools on the market handle such runtime SOA management, it is not the intention of these tools to handle quality management in the face of ongoing requirements changes -- at change time. Properly implemented, SOA enables organizations to effect requirements changes via declarative reconfiguration of Service metadata. As a result, managing quality through such changes means managing the quality of metadata. Therefore, such change time quality management focuses on metadata, and how well those metadata satisfy the requirements that apply during change time. Such requirements fall into two categories: ongoing, day-to-day requirements that reconfiguration can address, and the broader metarequirement of agility.
As a previous ZapFlash explored, there are at least three basic types of day-to-day change time requirements: Service contract changes, policy changes, and Service composition changes. To maintain quality whenever any of these metadata change requires both assurance that the Service infrastructure can adequately support the changes, as well as assurance that the newly configured metadata meet the requirements that led to the reconfiguration. SOA management tools should address the former challenge, but the latter challenge is potentially intractable.
The intractability of change-time metadata quality assurance results from the open-ended nature of reconfiguration in SOA. If architects fail to fully plan for this problem ahead of time, the sorts of changes users might introduce over time could be entirely unpredictable and unmanageable. Fundamentally, SOA encourages user empowerment, which in the absence of adequate governance can lead to anarchy. The important point to keep in mind is that change-time metadata quality assurance should be handled as a matter of policy. Apply Service-oriented principles to change-time quality assurance in order to create, communicate, and enforce policies for metadata-based changes. Then you can treat those policies like other policies that your SOA governance infrastructure deals with.
Defining the metarequirement of agility
Considering change-time quality assurance to be a matter of policy enforcement completes the SOA quality tooling picture: testing tools for design time quality, management tools for runtime quality, and governance tools for change time quality. But relegating change-time quality to the governance arena begs the question as to how you should create such policies in the first place. That question takes us back to the metarequirement of agility.
As the enterprise architecture team sits down to plan your SOA initiative, they should be asking questions about the specific levels of agility the organization requires from the SOA implementation. In particular, they should discover the answers to the following questions:
- What are the business requirements for Service reuse? Is the business looking to achieve a certain cost savings or other metric for reuse?
- What are the requirements for loose coupling? Break this question down into multiple levels: semantic, data, message protocol, wire protocol, etc.
- What is the user context for the implementation? For example, how many users will the Services need to support? Are they all internal users, or are you allowing users from outside your organization? What users will be allowed to make configuration changes, and under what circumstances?
- What are the metapolicies? In other words, what policies are in place that govern how the organization should be able to create and enforce policies?
It's important to note first of all that the end product of each of these questions should be a set of policies. Secondly, it's also significant that questions like these don't focus on requirements for specific functionality or behavior of the software you're building as in a traditional project. On the contrary, these questions all dwell on issues of agility -- just how agile your organization wants to be, but possibly even more importantly, in what areas is it OK to be less than fully agile. Identifying the particular constraints on the SOA initiative that your organization accepts can save substantial money and time, and can also lead to framing the discussion of change-time quality policies.
The ZapThink take
Even though considering change-time quality to be a governance issue reduces the risks inherent in user empowerment benefit of SOA, it's important to keep in mind that governance is not fully automatable. In fact, most governance activities are human: training, organizational management, and other human communications activities. SOA governance streamlines the part of the governance framework that lends itself to automation, and provides better tools for people to handle the rest. But no matter how sophisticated today's SOA governance solutions become, the human element will always remain.
As an example of this principle, say an organization has a policy that all Service compositions must be reviewed by a manager before going into effect. That policy is clearly a change-time quality policy, especially if there are associated policies that guide what managers should be looking for when they conduct such reviews. A tool can ease the implementation of this policy, but cannot take the manager out of the equation.
A second, more significant example concerns the potential infinite regression that some of you may have noticed: if metadata quality is a matter of policy, including the quality of the policy metadata themselves, then how can you insure the quality of those policies that apply to your quality policies? The answer is surprisingly simple: quality at the metapolicy level is up to people to provide. Say you have a policy that all Service contracts must conform to a particular Service specification that your organization has hammered out. Automating the enforcement of that policy is straightforward, but ensuring the quality of that policy is unquestionably a human activity: read through the metarequirements list and see if that policy is there, and make sure that people understand it properly. Such activities are simple for people, but prohibitively difficult to automate.