Step 9—Present Results
Step 9 is a one- to two-hour presentation summarizing the results and findings of the exercise. It begins
with a boilerplate set of slides that contains a method recap and blank template slides that can be filled in
with the business drivers summary, the architecture summary, the list of approaches, the utility tree, the
scenario analysis, and the list of analysis outputs.
The evaluation team meets during the evenings of phase 2 to compile all the results gathered so far. The
phase 2 agenda also contains a block of time before step 9 when the team can caucus and complete the
In addition to the risks, nonrisks, sensitivity points, and tradeoff points, the team presents risk themes that
seem to systematically underlie the problematic areas of the architecture, if any. This is the only part of
the results that the participants will not have already seen (and, for that matter, helped to identify). For
each one, we also state why it matters in terms that will be meaningful to the client: We identify the stated
business drivers that each risk theme jeopardizes.
Scenario 15: Nightingale is installed in a hospital and
the hospital's existing database must be converted.
Not surprisingly, the architect had given this scenario a lot of thought, since carrying it out
successfully was essential to the success of Nightingale. There was a documented procedure
in place, which the architect drew for us on the whiteboard.
It often happens that a scenario leads to a deeper understanding of the architecture than was
present before. Here, the architect had the information, but (reasonably) did not include it in
the step 3 presentation, considering it ancillary.
Walking through the migration process convinced the evaluation team that a well-thought-out
procedure was in place, with known strengths and reasonable limitations. It did not surprise us
that the architect did not mention the process during his presentation of step 3. What did
surprise us was that we saw nothing about it in the documentation package we received and
reviewed prior to phase 1. When pressed about this, the architect admitted that the procedure
was not yet documented, which we recorded as a risk. Offsetting this risk, however, was a
nonrisk that we recorded: "The architecture supports a straightforward and effective data
conversion and migration facility to support Nightingale installation."
For Nightingale, we identified three risk themes:
Over-reliance on specific COTS products.
Here we cited the difficulties in swapping out the
database, in removing the rules engine, and in relying on an old and possibly no-longer-supported
version of the database portability layer. This risk theme threatened the business driver of a system
that is maintainable.
Error recovery processes were not fully defined. The customer's knowledge of available tools
Several scenarios dealt with discovering errors in the database and backing them
out. While the architecture supported those procedures well enough, it was clear that the architects
and designers were thinking about some of them for the first time. The representatives of the kickoff
customer reported that they had no procedures in place (either of their own or inherited from the
developing organization) for making such error corrections. This risk theme threatened the business
driver of usability and support for the customer's enterprise.
The state of documentation on the Nightingale project was inadequate. The
team began to realize this as far back as the pre-phase 1 meeting, and several scenarios analyzed
during phase 2 reinforced this opinion. While a large volume of detailed documentation (such as that
produced via UML and the Rose model) existed, there was almost no introductory or overview
documentation of the architecture, which is critical for training, adding people to the project,
maintenance, and guiding development and testing. The extensive rule base that governed the
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
286 / 463