Architecture Reuse

Definition

Architecture Reuse

the architecting task during which reusable reference architectures or architectural elements are identified and reused

Classification

As illustrated in the preceding figure, architecture reuse is part of the following inheritance hierarchy:

• Type: Concrete
• Superclass: Task
• Subclasses:
  • Component Reuse
  • Reference Architecture Reuse

Responsibilities

The typical responsibilities of the architecture reuse task are to:

• Decide on component source:
  • Acquire
    Hire a contractor/subcontractor to develop the component specifically for the application.
  • Build
    Develop the component inhouse.
  • Buy
    Buy the component from a commercial vendor or share-ware author.
  • Legacy Reuse
    Reuse the component from an inhouse repository.
  • Open Source
    Obtain the component from an open source repository.
  • Receive
    Obtain the component from the customer organization.
• Maximize quality by reusing reference architectures and architecture components of known high quality.
• Minimize the development effort (and associated costs and schedule) by minimizing the architecting effort.
• Maximize the amount of architecture that is reused from the reuse repository.

Preconditions

Architecture reuse typically can begin when the following preconditions hold:

• The architecture team is adequately:
  • Staffed
  • Trained in architecture reuse.
• Reusable reference architectures and architectural components exist and are available.

Completion Criteria

Architecture reuse typically is complete when the following postconditions hold:

• The architecture has been based on one or more reusable reference architectures.
• Reusable architectural component(s) have been incorporated into the architectures.
• The parts of the architecture documents involving reuse have passed evaluation, are baselined, and have been accepted by the customer representative.

Steps

Architecture reuse typically involves the architecture team performs the following subtasks and steps in an incremental, iterative, parallel, and time-boxed manner:

• Reference Architecture Reuse:
  • Based on the requirements and logical architecture, examine the reuse repository to identify potential reference architectures.
  • Based on the requirements and logical architecture, evaluate the identified reference architectures for appropriateness.
  • Select and obtain reference architecture(s) and associated documentation from the reuse repository.
  • Modify the reference architecture to create initial architectures that fulfill the specific architecturally significant business goals or requirements.
• Potential Component Identification:
  • Based on the requirements and logical architecture, identify any potential opportunities for component reuse.
  • Identify potential sources of reusable components (e.g., vendors and reuse repositories).
  • Identify potentially reusable components including:
    • Commercial-off-the-shelf (COTS) components
    • Customer-Furnished-Item (CFI) components
    • Government-off-the-shelf (GOTS) components including Government Furnished Equipment (GFE), Government Furnished Property (GFP), and Government Furnished Information (GFI)
    • Legacy components from the organizational reuse repository.
    • Open Source software (OSS) components
• Potential Component Evaluation:
  • Based on the requirements and logical architecture, develop objective criteria and an associated process for evaluating reusable components.
  • Obtain evaluation resources (e.g., funds, facilities, staffing, test equipment).
  • Form the evaluation team.
  • Obtain reusable components for evaluation.
  • Develop evaluation prototypes.
  • Evaluate (e.g., via test) the potentially reusable component(s) for:
    • Required functionality (i.e., functional requirements)
    • Required quality factors (i.e., quality requirements, especially performance, reliability, safety, scalability, security )
    • Required data and interfaces (i.e., data and interface requirements)
    • Compatibility with the rest of the architecture and architectural components
    • Cost (acquisition and maintenance) via a cost/benefit analysis
    • Support (i.e., consulting, training, and maintenance)
    • Documentation (i.e., complete and compatible requirements, architecture, design, code, and test)
    • License acceptability
  • Make recommendations regarding the evaluated reusable component(s).
• Potential Component Selection:
  • Select the recommended component(s) to reuse.
  • Obtain authorization to obtain (e.g., purchase) and reuse the component(s).
  • Obtain the reusable component(s) and associated documentation (e.g., purchase or obtain from inhouse reuse repository).
  • Modify the reusable component(s) as necessary.
• Architecture Documentation
  Update the architecture document(s) to include the reference architecture(s), reusable component(s), and associated rationale(s).

Techniques

Architecture reuse typically can be performed using the following techniques:

• Checklists
• Cost/Benefit Analysis
• Evaluation Criteria
• Gap Analysis
• Reference Architectures
• Reuse
• Reuse Repositories
• Risk Analysis

Work Products

Architecture reuse typically results in the production of all or part of the following work products:

• Potential Component List,
  which lists the potentially reusable components.
• Component Evaluation Report,
  which documents the results of evaluating one or more architectural components.
• Component Acquisition List,
  which documents the reusable architectural components to acquire.
• Software Architecture Prototype,
  developed for use during the evaluation of the architectural components
• Updated:
  • Architecture,
    which includes information about the reference architecture and/or reused architectural components
  • Software Architecture Document,
    which includes information about the reference architecture and/or reused architectural components (actually a result of architecture documentation)
  • System Architecture Document,
    which includes information about the reference architecture and/or reused architectural components (actually a result of architecture documentation)

Guidelines

• This task is only useful if relevant reusable architectural components are available.
• Although many talk of “Make vs. Buy”, the situation is actually much more complex. It actually involves deciding between acquire, build, buy, legacy reuse, open source, and receive.
• This task is useful for both business [re]engineering and application development endeavors.