Many accept the advantages of these methods, however, often criticize these methods for their overhead. I think, these methodologies can certainly be adapted for agile use. We do not have to stick to the the elaborate process that SEI has recommended, but instead, we should adapt it for our use by sticking only to its principles. In fact, in my experience, these methodologies are more beneficial if we use them in conjunction with agile development methodologies.
In Agile world, the application functionality is to be built in agile way, with constant visibility to business, and frequent changes to the features. However, the same is not the case for its architecture. If the architecture is allowed to evolve with changing requirements, it causes frequent rework, constant re-factoring and in fact, it counters the ‘Agile’ response. It makes sense to spend upfront time on architecture evaluation and ensure that it is flexible to accommodate the future changes.
- Evaluate on Sampling basis –Short-list only the unique and critical scenarios that are likely to change.
- Create the artifacts such as Utility Tree as part of Architecture development process and not just for evaluation. The act of creating the utility tree will improve the thought process while defining the architecture.
- Evaluate everyday as soon as you discuss the scenarios in the war room. All the stakeholders are present in the war room. This avoids extensive planning, presentations, and elaborate evaluation exercises.
- During the evaluation, apply the utility tree to each scenario and evaluate the Sensitivity Points, Risks /Non-risks points, and Trade-off points. In case of alternative solutions, estimate Cost and perform Cost-Benefit analysis.
- Evaluate not only for the defined scenarios, but also for the possible changes. Get the ‘change’ scenarios from the business to evaluate the impact of changes. The architecture should be flexible to accommodate such changes.