Architecture

Definitions

Architecture

a fundamental architecture work product 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 characteristics and behavior of an:

• Business Enterprise,
• System,
• Application,
• Application Framework, or
• Reusable Component.

Classification

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

• Type: Abstract
• Superclass: Work Product
• Subclasses:
  • Application Architecture
  • Business Architecture
  • Center Architecture
  • Content Management Architecture
  • Database Architecture
  • Distribution Architecture
  • Hardware Architecture
  • Information (Data) Architecture
  • Network Architecture
  • Operational Availability Architecture
  • Organizational Architecture
  • Safety Architecture
  • Scalability Architecture
  • Security Architecture
  • Software Architecture
  • System Architecture
  • User Interface Architecture

Responsibilities

The typical responsibilities of an 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 system’s or application’s 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 architectures.
  • Architectural patterns.
  • Architectural views.
  • Architectural perspectives.
  • Architectural mechanisms.
• Influence Training.
  Influence the endeavor’s training plan including training in the architecture and its associated architectural patterns, views, perspectives, mechanisms, and technologies.

Contents

The typical contents of an Architecture are its:

• Architectural style and patterns
• Architectural elements (e.g., its major blackbox (i.e., data, hardware, software, user interface, and personnel) components, their responsibilities, and the relationships between them.
• Major architectural mechanisms.
• Major technology and associated vendor selections.
• How these architectural elements collaborate to implement and fulfill the architecturally-significant requirements.

These contents can be in the form of:

• Architectural Models:
  • Architectural Views
  • Architectural Perspectives
• Architectural Diagrams
• Text

Stakeholders

The typical stakeholders of an Architecture are:

• Producers:
  • Architecture Team (Application, Center, Component, and Framework Architectures)
  • Business Strategy Team (Business Architecture)
  • Content Management Team (Content Management Architecture)
  • Security Team (Security Architecture)
• Evaluators:
  • Architecture Evaluation Team
  • Strategy Evaluation Team (Business Architecture)
  • Customer Organization, which inspects the architecture for feasibility and appropriateness.
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative
• Maintainers:
  • Architecture Team
  • Business Strategy Team (Business 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 Interface Team, which uses the user interface architecture during the design and implementation of the user interfaces.

Phases

An Architecture typically is produced during the following phases:

• Business Strategy: Completed (Business Architecture)
• Business Optimization: Not Applicable
• Initiation: Started (System, Application, Component, or Framework Architectures)
• Construction: Completed
• Initial Production: Maintained
• Full-Scale Production:Maintained
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

An architecture typically can be started if the following preconditions hold:

• The relevant phase has started.
• The relevant teams have been staffed and trained in architecting.

Inputs

The typical inputs to an Architecture include:

• Work Products:
  • A relatively complete version of the relevant vision statement (e.g., application vision statement) is available.
  • Domain Model Document for the logical architecture and database architecture.
  • System Requirements Specification
  • Glossary
• Stakeholders:
  • Domain Experts
  • Vendor Representatives

Guidelines

• Fulfill Requirements.
  An architecture must fulfill (and is therefore validated against) the architecturally-significant requirements including:
  • Functional requirements,
  • Data requirements,
  • Interface requirements,
  • Quality requirements, and
  • Constraints.
• Drive Design.
  The architecture should drive and constrain the tactical (i.e., detailed) design.
• How? vs. What?
  The architecture and design both answer the question “How?”, whereas the requirements answer the question “What?”.
• Differences.
  The architecture and design differ in:
  • Degree because the architecture provides the big picture viewpoint, whereas the design provides the close up viewpoint.
  • Kind because architectural decisions have global (i.e., strategic) impacts, whereas design decisions only have local (i.e., tactical) impacts.

Conventions

An architecture is typically constrained by archtecture-specific versions of the following conventions:

• Work Flow
• Content and Format Standard
• Inspection Checklist