Architecture Lifecycle Issues

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

Process

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.