What Do Architects Do?

David Dikel and his colleagues, authors of Software Architecture: Organizational Principles and Patterns , have captured the essence of the activities of the architect in a model they call VRAPS, which stands for Vision, Rhythm, Anticipation, Partnering, and Simplification.

Vision

"Vision is the mapping of future values to architectural constraints, as measured by how well the architecture's structures and goals are clear, compelling, congruent, and flexible." [2] Developing an architectural vision permits a better definition of the scope of the architectural endeavor and sets the right level of expectations among the stakeholders (internal and external). It also allows early detection of when the expectations fail to align, and it makes tacit knowledge about architecture visible to its users.

[2] See Dikel 2001.

The architectural vision is clearly articulated in the Software Architecture Document, which must tie to the overall project Vision Document. Many of the activities related to architecture in the RUP Elaboration phase contribute to this architectural vision.

Rhythm

"Rhythm is the recurring, predictable exchange of workproducts within an architecture group and across their customers and suppliers." [3] It is about the lifecycle, the cycles and iterations, their visibility and predictability, how the organization will evolve an architecture over time, and how the various components will unfold and integrate. It is both about timing and about the content of a release and the quality of that content. It deals with synchronization between stakeholders, about re-evaluation. The RUP has a three- tier "tempo": cycle, iteration, and build. The initial development cycle brings a clear focus on architecture through its Elaboration phase. Subsequent evolution cycles will also have an Elaboration phase to evolve , refine, and simplify the architecture. Each cycle and phase is decomposed in iterations, which provide organizationwide synchronization points, focusing on a release of products, initially leading to an architectural baseline, and then evolving to a gradually more complete product of increasing quality. Then, in each iteration, the regular builds force a focus on value and force closure on concrete issues.

[3] Ibid.

Anticipation

"Anticipation is the extent to which those who build and implement the architecture predict, validate, and adapt the architecture to changing technology, competition, and customer needs." [4] The hardest objective of an architect is balancing long- term vision with immediate needs in the context of high technology churn. How do you avoid getting on the nasty tracks of too much bleeding edge and tunnel vision? Here you see how the various principles start playing each other: A healthy rhythm will force regular reviews and re-evaluation of the architectural vision.

[4] Ibid.

Partnering

"Partnering is the extent to which architecture stakeholders maintain clear, cooperative roles and maximize the value they deliver and receive." [5] Do not do it all. Build cooperative organizations, internally and externally. Maximize the ultimate value for critical stakeholders, not the amount of local invention and development. Make sure that there is a clear and compelling agreement between the various stakeholders, in the sense of the "win-win" approach preached by Barry Boehm and others. The architect is a negotiator , a mediator, a go-between, an ombudsman. The architect is keen on reuse.

[5] Ibid.

Simplification

"Simplification is the intelligent clarification and minimization of both the architecture and the organizational environment in which it functions." [6] The architecture continues to be used, but at the same time the cost of using it, and therefore its complexity, must be reduced: no fluff, no overgeneralization of the problems leading to overgeneral solutions. The architect understands the essential minimal requirements and builds them into the core elements of the architecture. The overall business case for evolving the architecture remains clear. Some architectural refactoring does take place.

[6] Ibid.



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net