Architecture Lifecycle Issues

From Wiki
Jump to navigationJump to search

Architecture Based Process

  • Establish business case for the system. e.g. Product cost, time to market.
  • Understand the requirements
    • Use cases, prototypes
    • Quality attributes
    • Commonality & variability from previous/future systems - domain analysis.
  • Develop the architecture - use tactics, styles.
  • Document the architecture - using variety of views and ADL.
  • Analyse or evaluate the architecture.
  • Implement product based on the architecture.
  • Ensure that implementation conforms with architecture.

Process Recommendations

  • Architecture should be a product of a single architect or a small group of architects with a single leader.
  • Arch should have both functional reqs and an articulated, prioritized list of quality attributes.
  • Arch should be well documented with atleast one static view and one dynamic view.
  • Arch should be circulated to all stakeholders who should actively review.
  • Arch should be analysed for quantitative measures and formally evaluated for qualitative properties.
  • Should lend itself to incremental implementation via creation of a skeletal system.

Global Analysis

  • The purpose of global analysis is to analyse the factors that influence the architecture and develop strategies for accommodating these factors in the architecture design.
  • Three types of factors:
  1. Organizational factors
  2. Technological factors
  3. Product factors


Analyse factors

  • 1. Identify and describe factors
    • Consider those that have significant global influence.
    • Can factor be localized or is it truly global ?
  • 2. Characterize the flexibility and changeability of the factors
    • Can factor be changed, modified, influenced.
    • How often will it change ? How likely ?
  • 3. Analyse the impact of factors
    • Other factors, component, design decisions.

Develop Strategies

  • 1. Identify issues and influencing factors
    • Identify handful of important issues that are influenced by factors and their changeability.
    • Usually several factors affect an issue and when they conflict - we must negotiate a change in them.
    • Difficult to satisfy factor, expensive factor.
  • 2. Develop solutions and specific strategies
    • Reduce or localize factor's influence.
  • 3. Identify related strategies
    • Dont repeat strategies identified with more than one issue. Reference them.

Organisational Factors

  • Management
  • Staff skills
    • e.g. Analyze factors
    • experience in multithreading.
    • Only one developer has skill.
    • Flexibility: Subject area is too complex for only training.
    • Impact: There is a moderate impact on meeting performance.
    • Strategies
    • Only 1 developer
    • Strategy: avoid use of multiple threads.
  • Process and development environment
  • Development schedule
  • Development budget

Technological Factors

  1. General purpose hardware e.g CPU, mem, disk
  2. Special purpose hardware e.g. probe
  3. Software technology e.g. OS, language,
  4. Architecture technology - e.g product line, DSL's.
  5. Standards - OS interface, data formats, coding conventions.

Product Factors

  1. Functional Features
  2. UI
  3. Performance
  4. Dependability
  5. Failure detection
  6. Service - maintenance
  7. Product cost
  • Example of an issue card:
  • Issue: Easy Addition and removal of features
  • Factors: O4.1 (Org Factor) : TIme to market short
  • P1 (Prod factor) : New varieties added every 3 years.
  • Solution: Use separation of concerns
  • Strategy: Separate components and modules across dimensions of concern
  • Related Strategy: See: encapsulate general purpose hardware.

  • Finally
  • All issues collected and a summary of strategies formed.
  • Output of global analysis process is a set of strategies that form context for the architecture definition

Architecturally significant requirements

  • Requirements may predefine architecture. e.g. safety standards.
  • How to recognise such architecturally significant requirements ?
    • Cannot be satisfied by one component without dependence on rest of system (e.g. availability)
    • Address properties of different categories of components (e.g. naming, referencing, communication)
    • Address process of manipulating components (e.g. configuring or upgrading).

Team organisation

  • Team allocation typically determined by static components of the arch.
    • Each major component represents a "domain" and therefore relies upon a pool of expertise in a certain area.
    • Dynamic behaviour may cut across teams.
  • High bandwidth communication necessary within team and low bandwidth communication across teams.
  • Organisation can also have a reverse impact on the definition of the architecture.
    • Members of a certain group (e.g. DB) may view problems as being group centred.

Role of the architect

  • Architect may be a single person or team.
  • Needs to liaise with relevant system stakeholders.
  • Therefore needs people mgmt skills as well as technical competency.
  • Makes the ultimate decisions - Attempts to reconcile conflict between stakeholders.
  • Must be a keeper of the flame
    • Have a clear vision (architectural description).
    • Ensure that the vision is communicated.
    • Ensuring the vision is maintained.
  • Architect role must be kept different from mgmt role.
  • Architect creates the vision.
  • Is the key technical consultant.
  • Makes decisions.
  • Coordinates.
  • Implements or guides implementation.
  • Advocates.