Interesting article, although I don't agree with the final assertion that time-boxing doesn't work for SOA projects. I have seen a couple of supreme success stories that use agile methodologies with strict time-boxing. They do not sacrifice quality or agility in favor of time. The primary factor that gives is scope.
Anne On Thu, Sep 25, 2008 at 4:00 PM, Gervas Douglas <[EMAIL PROTECTED]> wrote: > > > Best Effort SOA and the SOA Quality Star > > Document ID: ZAPFLASH-2008924 | Document Type: ZapFlash > By: Jason Bloomberg > Posted: Sep. 24, 2008 > > 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. > > To support this agility requirement, therefore, traditional pre-deployment > acceptance testing is impractical, as the acceptance testing process itself > impedes the very agility the business requires. Instead, quality becomes an > ongoing process, involving continual vigilance and attention. Quality > itself, however, need not suffer, as long as the business understands the > implications of implementing an agile architecture like SOA. > > An intriguing analogue to this shift in perspective that SOA Quality > requires appears in the telco world's move to the mobile phone network. In > the old circuit-switched, plain old telephone service (POTS) days, the > carriers sought to deliver eponymous carrier grade quality of service, > delivering the proverbial five nines (99.999%) availability. However, the > new cell phone network was entirely unable to deliver carrier-grade > availability -- and even to this day, as we move to third generation mobile > networks and beyond, we still live with dropped calls, dead zones, and more. > Does that mean that today's mobile phone networks are essentially of lower > quality than POTS service? The answer is no, as long as you define quality > in the context of the new environment, what the telcos call "best effort." > After all, the components of this network -- cell towers, mobile phones, > etc. -- have all been tested thoroughly, and the network overall delivers > the quality the telcos promise and that we're willing to pay for. As long as > the infrastructure delivers its best effort to complete and maintain our > phone calls, we're happy. > > Just so with SOA Quality. If we exclude the agility requirement from the > quality equation, we'll never be happy with the result. But if we build > agility into our quality approach, then the resulting implementation is > within reach of both. Nevertheless, there is still a tradeoff between > agility and quality, but that tradeoff depends upon more than two variables. > As a result, there's more to this story. > > Beyond the Software Development Triangle > To understand the agility/quality tradeoff question, we have to reach back > into the ancient history of software development (say, more than ten years > ago) and brush off the venerable Software Development (SD) Triangle, which > states that any SD project has three key variables: cost, time, and scope. > It's possible to fix any two of these, but the third vertex of the triangle > will vary as a result. For example, if you fix the cost and schedule for a > project, you may or may not be able to deliver on all the requirements for > the project, and so forth. > > Restricting the relevant variables to these three, however, assumes a fixed > level of quality. In other words, if an SD stakeholder attempts to fix all > three corners of cost, time, and scope, then all that's left to give way is > the quality of the resulting deployment, which is rarely if ever acceptable. > We might say that the SD Triangle is really a square, with quality being the > forth vertex. > > SOA projects, though, vary this relationship in a fundamental way: they add > agility to the equation, turning this square into a star (or a pentagon, if > you will), as shown in the figure below, where the lower three vertices form > the traditional SD Triangle: > > The SOA Quality Star > > Now, it's tempting to posit that this SOA Quality Star exhibits a > fundamental five-way symmetry, where we might fix any four vertices at the > expense of the fifth, but if we take a closer look, the situation isn't > quite so simple. In fact, there is a second triangle embedded in the star > above that illustrates some important fundamental principles of SOA Quality. > This triangle that connects agility, quality, and time we'll call the Best > Effort SOA Triangle, because it illustrates the problem the DoD faced in the > story above: the more agile a SOA implementation becomes, the more time is > required to ensure quality, and as a result, it isn't long until quality > activities become so time-consuming that the agility of the implementation > is at risk. > > Combining the SD Triangle and the Best Effort SOA Triangle into the SOA > Quality Star, then, doesn't lead us to the conclusion that we can fix any > four vertices by varying the fifth, because the maximum agility we can > achieve is limited by the time it takes to obtain the required quality. As a > result, the only two vertices we might leave unfixed are the two that are > not on the Best Effort Triangle, namely scope and cost. In other words, if > we're able to specify the required agility, quality, and time for a > particular SOA project, within the context of the dependencies the Best > Effort Triangle expresses, then either we can set the cost of that project > by adjusting the scope, or set the scope of the project by allowing for > additional cost. > > The conclusion of this analysis is clear: the only way to obtain the balance > between agility and quality the business requires is to take an iterative > approach to a SOA initiative, where each iteration is bounded either by > scope or cost. As a result, SOA projects differ from traditional SD projects > in that with a SOA project, time boxed iterations (that is, those with the > time vertex fixed) are impractical, because time boxing doesn't take into > account the effect of the agility requirement on quality. Instead, the time > vertex depends upon the agility/quality balance that characterizes Best > Effort SOA. > > The ZapThink Take > Perhaps the most important lesson here is the contrapositive of the above > conclusion: "big bang" SOA projects that attempt to roll out broad, > enterprisewide SOA initiatives in a non-iterative fashion inevitably > sacrifice the agility/quality balance, essentially because the time it would > take to adequately test such an implementation would severely curtail the > agility of the result. Only when agility is not a requirement at all would > such a big bang project be even theoretically feasible -- but it could be > argued that every SOA effort does have at least some agility requirement, or > else why would you bother with SOA in the first place? > > You could even say that an ostensible SOA project with no agility > requirement is in truth an integration project, as there would be no need > for loosely coupled Services. Unfortunately, we see evidence of such > projects all the time: organizations that think they want to implement SOA > for one reason or another, but instead purchase an ESB or other integration > middleware first and deliver what becomes a large-scale, big bang > integration project instead. The end result of this snafu is business > stakeholders scratching their heads over the resulting lack of agility and > wondering why they didn't get the business value from the initiative they > expected and thought they were paying for. Taking an iterative approach to > SOA is the most important step in avoiding this unfortunate conclusion. > > > >
