An Evolving Role

Describing the RUP approach for an architect is a bit of a challenge, as this role evolves throughout the lifecycle ”Inception, Elaboration, Construction, and Transition ”and also during evolution or maintenance cycles.

During Inception, working with the emerging vision, an architect will evaluate possible implementation strategies and feedback feasibility to the requirements work, as well as costs to the management. As the system takes shape, a possible architecture is defined and sometimes even prototyped to assess its effectiveness: a proof-of-concept prototype for the candidate Architecture. Certain delicate parts of the system may also be prototyped to prove a concept feasible , or to help drive a decision to develop the system ”or not develop it, in some cases! For example, if there is a strong doubt, build a crude prototype to show that your distributed system will support the number of transactions you expect.

It is during the Elaboration phase that the Architect has the most crucial role, and often several persons will be involved. An objective of Elaboration is to flesh out the Software Architecture Document and to validate the choices made by developing an executable architectural prototype. The milestone that concludes this phase is called the Lifecycle Architecture (LCA) Milestone, and this is where hopefully the architects can baseline an architecture. Faced now with some more tangible elements other than requirements simply drawn on paper or sketchy design ideas, this architectural effort may result in a revision of the requirements and the vision. For example, your new prototype may show that you have some performance issues to be addressed. But the role of the architect does not abruptly stop at the LCA Milestone.

In Construction, as in building architecture, software architects are responsible for overseeing the implementation of the rest of the system, making sure that the original architectural intent is not compromised. Often architectural adjustments and additions are necessary. The architect will play go-between and arbiter between teams , deciding where an aspect must be developed, making sure that guidelines are followed, or capturing new information in the guidelines. Involved in design reviews, architects are well placed to attract the attention of project management on some staffing issues: imbalance between teams, lack of resources, lack of training, and so on. They can also identify further opportunities for reuse or acquisition of ready-made software.

One may think that the role of architects is almost nil in the Transition phase, that they may now retire in peace or move to greener pastures. Not quite! As things get tough toward the delivery date, the architect is involved in critical decisions about major defects: what to fix and how, especially vigilant so that hasty or uninformed decisions that could fix one subsystem but break another one are not made. Lots of nasty mistakes can be made in that last stretch to the finish line, wiping out the benefits of architectural work.