petereeles 120000BW4X Visits (1032)
There are, of course, occasions where a project makes relatively-simple changes to an existing system and where the amount of architecting is minimal (and can be done “up front” if it is required at all). And then there is the other 95% of projects. In summary – most projects require an amount of architecting to be performed.
One tool I’ve always found particularly valuable is having a sense of the expected change in architecture emphasis through the life of a project. This helps focus the mind and can be a great help when looking for a “guiding light” through a sea of uncertainty. It ensures that there is an emphasis on those items that must be dealt with now, ensuring that we don’t get bogged down in details that can be dealt with later. And this applies irrespective of the project lifecycle (waterfall, iterative, agile, disciplined agile – as discussed here and here).
The first (and my favorite) articulation of this change of architecture emphasis is shown in the figure below. This was (I’m reliably informed) a sketch that was drawn on a napkin by Bran Selic for Philippe Kruchten. I don’t know what Bran had been eating, but it must have been good stuff.
This figure shows that, early on in the project, the architect is focused very much on discovery. The emphasis is on understanding the scope of the system and identifying the critical features and any associated risks. These elements clearly have an impact on the architecture. The emphasis then changes to one of invention, where the primary concern is to develop a stable architecture that can provide the foundation for full-scale implementation. Finally, the emphasis changes to implementation, when the majority of discovery and invention has taken place. Of course, discovery, invention and implementation are not strictly sequential. For example, some implementation will occur early in the project as architectural prototypes are constructed, and there will be some discovery late in the project as lessons are learned and different strategies for implementing certain elements of the architecture are put in place.
This philosophy was later formalized in the Rational Unified Process, where the phases of Inception, Elaboration, Construction and Transition emerged. As I’ve mentioned before, such as phase-based approach supports convergence of a number of elements as the project progresses. For example, risks reduce over the project lifecycle, and cost and schedule estimates become more accurate. The architecture also stabilizes over time, as shown below, since there is a focus on driving out technical risk (through discovery and invention). The figure below characterizes the Inception and Elaboration phases as “engineering”, whereas the Construction and Transition phases are treated as “production”. This distinction is discussed in detail in Software Project Management – A Unified Framework by Walker Royce (Royce 1998). Moving from Elaboration to Construction (that is, engineering to production) is particularly interesting since this represents a significant milestone as far as the business is concerned. The production stage is generally more predictable than the engineering stage, since there is usually a good understanding of both the problem and the solution. There is therefore a much higher level of fidelity of cost and schedule estimates, and funding decisions can be made with greater confidence.
This is not to say that all of the requirements have been defined by the end of elaboration, or that requirements never change. However, it is expected that the majority of requirements have been defined and that any changes have a minimal impact on the architecture.