5.2 Overview of Architecture-Driven Approach

5.2 Overview of Architecture-Driven Approach

5.2.1 Development Process

The development processes for creating me-centric applications can be manifold , as we learned from the last chapter. Although we do not want to impose any development methodology on you, we think it is important to notice that user -centric development processes provide a higher quality result in me-centric computing.

The application systems should be developed in two basic steps: First, for each application, customer-specific requirements must be elucidated and any changes in the reference requirements (deviations from standardized requirements presupposed in the architecture) must be understood ; second, specific implementation components must be selected to meet the specific requirements of each customer. This twostep process greatly simplifies many smaller steps and a wide range of alternative sequences that may be possible.

Additionally, various policies may be imposed to require particular intermediate products and decisions. Nevertheless, the architecture process is one of adapting a generic solution to fit a particular problem by understanding the unique requirements of the customer at hand and selecting or customizing solution components to fit.

5.2.2 Key Resources

Our approach depends on a reference architecture, reusable components, and tools for adapting a reference architecture to meet requirements of particular customers. A variety of techniques can enhance the quality of these key resources and the processes by which they are developed, applied, and maintained . These resources constitute the principal intellectual capital for a product line and are the appropriate concern of a product line manager. The cost of technology components and interconnection resources needs to be kept low, because only with cheap ingredients is it possible to expand the deployment of the basic architecture into every aspect of life.

5.2.3 Principal Sources of Leverage

Our approach can provide enormous leverage on hardware and software affordability , program predictability, and mission performance. These benefits result from accumulating and exploiting software components that can be configured to meet the specialized requirements of each customer-specific application derived from the architecture's generic solution.

This approach, moreover, can make software development predictable, by eliminating or simplifying design, development, and testing. By reusing a solution repeatedly, confidence increases in its suitability while incremental errors are reduced in frequency. Finally, better software quality translates directly into higher performance of critical missions, because the software functions correctly and does what the user intends it to do. Furthermore, because this approach makes software easier and cheaper to obtain, it means that more of the critical functions customers need will be provided. This, in turn , means that more ambitious and challenging missions will be accomplished with a greater range of capabilities provided. This success will translate directly into reduced losses and improved outcomes , at lower cost.

5.2.4 Key Constraints

For our approach to work, several constraints must be satisfied. First, reference architectures must be reused over several applications, networks, and appliances. The benefits of reuse require both experience from reuse and opportunities for reuse. A product line manager must be able to adopt and enforce adherence to a reference architecture, and other stakeholders must comply . The affected stakeholders can include users, component developers, system integrators, maintainers, system operators, and even standards-setting bodies. ^[4]

^[4] Standards can be determined either by consensus committee processes or unilaterally by market-dominating vendors . While the former might be more " open " than the latter, the importance of standards to the architecture-driven approach is the same: standards assure that components interface, interconnect, and interoperate as expected. Thus, architectures incorporate standards by reference to them, and a reference architecture is a pattern that goes beyond formal standards by citing generic or specific solution components.

Each architecture defines a potential common approach to achieving interoperability and interchangeability that buyers and suppliers can exploit within a certain domain. A critical proportion of these participants must agree to the approach for it to prove practical.

5.2.5 Sources of Variation and Flexibility

One reason why software reuse and systems integration are difficult is that independently developed software components often embed different assumptions about the context in which the components will be applied.

Our approach attempts to avoid this problem by providing enough specificity in open interfaces so that independent developers can produce plug-and-play components. The reference architecture must make explicit the context assumptions so that all developers can treat these consistently. Descriptions of components must make explicit which types of variations are permitted and must rule out others. Certain variabilities can be anticipated in a reference architecture and supported explicitly, giving the reference architecture "built-in" flexibility.

For example, different transaction rates might be supported in various ways, including replicating processes and dynamically balancing workload across multiple processors. Typically, this kind of flexibility is supported by setting parameters for architecture components or by specifying a range of possible values for capabilities required of component implementations .

Exceptions to a reference architecture should be possible as well, but each of these will generally reduce predictability and reusability of the affected components. In addition, by using a non-compliant component within an application, the manager increases the likelihood that subsequent efforts to plug in new or modified components will fail. Such interoperability failures are traceable generally to incompatibilities introduced by the non-compliant component.

5.2.6 Relationship to Other Methods and Standards

A reference architecture might be considered as a kind of "standard" for a particular application-specific community. The reference architecture specifies standard component interfaces, and the domain model provides a reference model showing how an application fits into its application context and environment. Furthermore, generic components of the reference architecture typically make assumptions about what capabilities they get from their implementation environment and which capabilities they must provide to other components.

These are the same concerns addressed by various standards. In short, each architecture should harmonize with other important standards that affect the same stakeholders. For example, standards for distributed computing and desktop presentation managers apply to many architectures. Although standards are always in flux, each architecture will either be consistent with particular standards or incompatible with them. Compatibility is preferred.