Page 207 -

192 BARBER AND GRASER
RARE and the DRA can benefit the development process. Aspects are posed as questions and
grouped into process-related and representation-related concerns.

Process-Related Concerns

Does the organization plan strategically over multiple projects? Is reuse important
over the long term, or are development efforts typically “one-time” investments?
The primary value of RARE and a high-level domain reference architecture is to establish a vi-
sion for the topology of multiple deployments over time, regardless of the technology that will
be selected to implement those deployments. The DRA captures domain requirements, and these
requirements are reused as multiple systems are produced, thereby amortizing the cost of the
analysis effort over multiple projects, systems, and deployments. The DRA also provides value
independent of any particular system being built, in that it captures domain knowledge; the DRA
can thereby act as a knowledge transfer medium to educate new developers and other stakehold-
ers. However, if each project is treated as a silo and analysis and design artifacts are typically not
reused, it may be difficult to justify deriving a DRA, given the upfront investment required.
One software development approach that encourages leveraging modeling efforts over multiple
projects is the concept of Model-Driven Architecture (MDA). MDA defines three modeling levels:
platform-independent model, platform-definition model, and platform-specific model (Frankel and
Guttman, 2002). A platform-independent model is a description of a software or business system
that is independent of the specific technological platform used to implement it; the model may be
described in a language such as UML and can be used as a basis for transformation into a family of
platform-specific models. The DRA representation is analogous to the MDA platform-independent
model, where domain data and functionality are allocated into prescribed components.

RARE benefits/limitations to consider. RARE provides opportunities for long-term reuse as
a domain model in a component-connector “blueprint” that can establish a vision for multiple
deployments. However, considerable discipline and upfront investment are necessary to derive a
DRA that captures a complete set of domain requirements and considers factors that are not only
applicable to current sites but also envisioned for future sites.
Would the organization reap the value of early architectural analysis?

The DRA representation is intentionally high-level to make it suitable for early, computational
analysis, the objective being to make decisions as early as possible in the development process.
In general, software methodologies encourage such early modeling and analysis, motivated by the
observation that errors identified earlier in the software development cycle (i.e., during analysis
and design phases) are less costly to fix than after implementation commitments have been made
(Graser et al., 2002). The DRA takes this one step further by allowing engineers to perform analysis
in terms of architecture topology, where domain functionality is allocated to components that can
prescribe eventual computing platforms.

RARE benefits/limitations to consider. The DRA is a high-level architecture defined by a formal
meta-model, making it suitable for early analysis, including static structural analysis (e.g., cou-
pling) and dynamic analysis such as performance simulation. Nonetheless, as with any extensive
domain modeling effort, the DRA requires the acquisition and understanding of functionality and