System Architecture

Definition

System Architecture

the overall architecture of a single system

Responsibilities

The typical responsibilities of a system architecture are to:

• Fulfill Requirements.
  Provide an overall system structure and set of mechanisms that fulfill all architecturally significant requirements of the system.
• Drive Designs & Implementations.
  Influence and constrain the designs and associated implementations of the system’s components.
• Improve Communication.
  Improve communication among the system’s stakeholders concerning the the most important, pervasive, top-level, strategic inventions, decisions, and their associated rationales.
• Build Consensus.
  Produce a formally documented consensus amoung the system’s stakeholdlers (e.g., members of the customer, development, and subcontractor organizations) concerning the:
  • Architectural patterns and styles to be reused on the system,
  • Top-level strategic logical and physical structures (i.e., major functions, classes, processes, components, their responsibilities, and their relationships) of the system,
  • Most important, pervasive architectural mechanisms of the system, and
  • Associated rationales.
• Estimate Costs.
  Provide input (e.g., number, size, and complexity of system components and mechanisms) for estimating the cost of the producing or upgrading the system.
• Enable Scheduling.
  Provide a basis (e.g., components, mechanisms) for estimating the schedule of the system’s development or life-cycle cycle’s phases, builds, and milestones.
• Influence Staffing and Organization.
  Strongly influence the organization structure of the endeavor in terms of its necessary component teams and associated roles. It also influences the endeavor training plan.

Contents

The typical contents of an System Architecture are the system’s:

• Architectural style and patterns.
• Logical architecture in terms of its major classes, processes, and functions.
• Physical architecture in terms of its major blackbox components (i.e., data, hardware, software, user interface, and personnel), their responsibilities, and the relationships between them.
• Major architectural mechanisms.
• Major technology and associated vendor selections.

These contents can be in the form of:

• Architectural Diagrams.
• Architectural Models:
  • Data Model.
  • Object Model.
  • Process Model.
• Software Architecture Prototype.
• Text.

Stakeholders

The typical stakeholders of an System Architecture are:

• Producers:
  • Architecture Team (Overall System Architecture)
  • Content Management Team (Content Management Architecture)
  • Database Team (Database Architecture)
  • Security Team (Security Architecture)
• Evaluators:
  • Architecture Evaluation Team
  • Customer Organization, which evaluates the architecture for feasibility and appropriateness
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative
• Maintainers:
  • Architecture Team
  • Database Team (Database Architecture)
  • Content Management Team (Content Management Architecture)
  • Security Team (Security Architecture)
• Users:
  • Database Team, which uses the database architecture during the design and implementation of the databases and associated data components.
  • Deployment Team, which uses the various architectures during the planning of the deployment tasks.
  • Hardware Development Team, which uses the hardware, network, operational availability, and scalability architectures during the design and implementation of the hardware components.
  • Independent Test Team, which uses the various architectures during the development of integration and functional tests.
  • Integration Team, which uses the various architectures during the planning of the integration tasks.
  • Maintenance Team, which uses the various architectures during the maintenance tasks (to ensure that maintenance tasks to not violate the architectures).
  • Metrics Team, which uses the components in the architectures as an input when estimating the size and scope of the project.
  • Project Management Team, which uses the architectures as an input when managing project scope and schedule project activities.
  • Security Team, which uses the security architecture during the design and implementation of the security components and mechanisms.
  • Software Development Team, which uses the various architectures during the design and implementation of the software components.
  • User Experience Team, which uses the user interface architecture during the design and implementation of the user interfaces.

Phases

An system 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

The system architecture typically can be started if the following preconditions hold:

• The initiation phase is started.
• The architecture team has been staffed and trained in architecture engineering.
• When relevant, the content management team and security team have been staffed and trained in architecture engineering.

Inputs

The typical inputs to an system architecture include:

• Work Products:
  • A relatively complete version of the system vision statement is available.
  • Domain Model Document for the logical architecture and database architecture.
  • System Requirements Specification
  • Glossary
• Stakeholders:
  • Domain Experts
  • Package Vendor Representatives

Guidelines

• See the general guidelines for architectures.
• A system architecture typically includes a set of component subordinate architectures (e.g., hardware architecture, network architecture, operational availability architecture, scalability architecture, security architecture, software architecture, and user interface architecture).

Conventions

An system architecture is typically constrained by the following conventions:

• Work Flow
• Content and Format Standard
• Inspection Checklist

Examples

• TBD