Software Architecture

Definitions

Software Architecture: an architecture that captures the most important, pervasive, top-level, strategic inventions, decisions, and their associated rationales about the overall structure (i.e., essential elements and their relationships) and associated behavior of one or more (potentially reusable) software components

Responsibilities

The typical responsibilities of a Software Architecture are to:

Fulfill Requirements.
Provide an overall structure and set of mechanisms that help fulfill all architecturally significant requirements (especially the quality requirements) and constraints.
Drive Design, Implementation, Integration, and Testing.
Help influence and constrain all subsequent activities including the software design, implementation, integration, and testing.
Improve Communication.
Communicate the architectural decisions concerning the application’s software components to their stakeholders (e.g., members of the customer, development, and subcontractor organizations) in a form that is:
- Descriptive.
- Prescriptive.
- Proscriptive.
Build Consensus.
Produce a formally documented consensus amoung the endeavor’s stakeholdlers concerning the:
- Architectural patterns and styles to be reused,
- Top-level strategic structures (i.e., major functions, classes, processes, components, their responsibilities, and their relationships),
- Most important, pervasive architectural mechanisms, and
- Associated rationales.
Drive Organizational Structure.
Help drive the organizational structure of the development team(s) by assigning different components to be developed by different teams and organizations (e.g., subcontractors).
Support Endeavor Management.
Help drive the production of the endeavor’s:
- Budget by providing input (e.g., number, size, and complexity of system components and mechanisms) for estimating the cost of the endeavor.
- Work Breakdown Structure (WBS).
- Master Schedule by providing a basis (e.g., components, mechanisms) for estimating the schedule of the endeavor’s development or life-cycle cycle’s phases, builds, and milestones.
Achieve Strategic Reuse.
Help an organization achieve strategic reuse by reusing:
- Reference architectures.
- Parts of existing software architectures.
- Architectural patterns.
- Architectural mechanisms.
Influence Training.
Influence the endeavor’s training plan including training in the architecture and its associated architectural patterns, mechanisms, and technologies.

The typical contents of a software architecture are:

Logical Views:
- Logical elements (e.g., layers, types, major functions), their responsibilities, and their logical interfaces.
- Logical relationships (e.g., generalization, depends-on, aggregation, collection, membership, dataflow, and control flow).
- Deployment of logical elements to hardware components.
- For example, this might include the following diagrams:
Source Code Views:
- Source code elements (e.g., classes, procedures), their responsibilities, and their physical interfaces.
- Code-level relationships (e.g., procedure calls, method invocation, and inheritance) and their responsibilities.
- Allocation of source code elements to file structures.
- Deployment of source code elements to hardware components.
- For example, this might include the following diagrams:
  - Class Diagram.
  - Deployment Diagram.
Runtime Views:
- Runtime elements (e.g., processes, threads, and objects).
- Runtime relationships (e.g., communication links and protocols, data flows, and shared storage).
- Deployment of runtime elements to hardware components.
- For example, this might include the following diagrams:
Mechanisms (dealing with major architectural drivers and their validation):
- General Mechanisms:
  - Startup and Shutdown.
  - Component Integration.
  - Persistence.
  - Concurrency.
  - Distribution.
  - Searching, Indexing, and Categorization.
  - System management and monitoring.
- Mechanisms for Quality Requirements.
  - Developer-Oriented Quality Mechanisms (extensibility, portability, reusability, etc.)
  - User-Oriented Quality Mechanisms (robustness, scalability, operational availability, interoperability, performance, personalization, security, etc.) with associated diagrams:

Stakeholders

The typical stakeholders of a Software Architecture are:

Producers:
- Architecture Team
Evaluators:
- Architecture Evaluation Team
- Customer Organization, which evaluates the architecture for feasibility and appropriateness
Approvers:
Maintainers:
- Architecture Team
Users:
- Software Development Team

Phases

A software architecture typically is produced during the following phases:

Business Strategy: Not Applicable
Business Optimization: Not Applicable
Initiation: Started
Construction: Completed
Delivery: Maintained
Usage: Maintained
Retirement: Archived

Preconditions

A software architecture typically can be started if the following preconditions hold:

The initiation phase is started.
The architecture team has been staffed and trained in architecting.
At least some of the following inputs are available.

Inputs

The typical inputs to a software architecture include:

Work Products:
Stakeholders:
- Domain Experts
- Software Package Vendor Representatives

Guidelines

Document the software architects to the extent that they are unambiguous and can be analyzed and evaluated.
All of the requirements need not exist, but at least some of the architecturally significant requirements and constraints need to need to exist prior to the development of the software architecture.

Conventions

A software architecture is typically constrained by the following conventions:

Work Flow
Content and Format Standard
Inspection Checklist

Examples

Example Software Architecture