Architecting

Definition

Architecting

the engineering activity consisting of the cohesive collection of all tasks that primarily involve the production of one or more related architectures

Classification

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

• Type: Abstract
• Superclass: Engineering Activity
• Subclasses: None
• Business Enterprise Architecting
• Component Architecting
• Contact Center Architecting
• Database Architecting
• Data Center Architecting
• Framework Architecting
• Hardware Architecting
• Information Architecting
• Security Architecting
• Software Architecting
• System Architecting

Responsibilities

The typical responsibilities of Architecting are to:

• Produce Architectures.
  Produce, document, maintain, and enforce the architectures of the customer organization’s:
  • Business Enterprise,
  • Application(s),
  • Application Framework(s), or
  • Reusable Component(s).
• Communication.
  Improve communication among the endeavor’s stakeholders concerning the architecture.
• Consensus.
  Produce a formally documented consensus among the endeavor’s stakeholders (e.g., members of the customer, development, and subcontractor organizations) concerning the:
  • Architectural patterns to be reused,
  • Top-level strategic logical and physical structures,
  • Most important, pervasive mechanisms,
  • Design decisions, and
  • Associated rationales.
• Costing.
  Provide input (e.g., number, size, and complexity of system components and mechanisms) for estimating the cost of the endeavor.
• Scheduling.
  Provide a basis (e.g., components, mechanisms) for estimating the schedule of the endeavor’s development or life-cycle cycle’s phases, builds, and milestones.
• 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.
• Quality.
  Maximize the quality of the architecture:
  • Correctness, which is the ability to meet the architecturally significant:
    • Operational requirements,
    • Quality requirements (e.g., extensibility, scalability, performance, operational availability, and security),
    • Design constraints (e.g., use of existing databases), and
    • Business rules.
  • Completeness (i.e., all architectural decisions have been made).
  • Consistency (both internally within and between architectures as well as externally with other work products such as integration test cases)
  • Understandability of the architectures to their many stakeholders.
• Productivity.
  Maximize the productivity of the associated teams (e.g., reuse of reusable architectural frameworks, reuse of architecture conventions, and existence of example documents).
• Principles.
  Maximize the use of architectural principles:
  • Abstraction so that each architectural component and mechanism has a well defined scope and purpose.
  • Maximize Cohesion so that each architectural component and mechanism incorporates a cohesive set of related parts.
  • Minimize Coupling so that each architectural component and mechanism interacts with others through well-defined, minimal set interfaces
  • Information Hiding so that the internal design decisions are hidden behind a well-defined interface.
  • Separation of Concerns so that different tiers, layers, components, and mechanisms address separate concerns (e.g., the presentation tier addresses interfacing with users, security packages address security issues) and can be implemented by different teams with different areas of expertise.

Preconditions

Architecting typically may begin when the following preconditions hold:

• The initiation phase has started.
• The architecture team is initially staffed and adequately trained in architecting.
• Some architecturally significant requirements have been specified.

Completion Criteria

Architecting is typically complete when the following postconditions hold:

• The architecture(s) have been documented.
• The deliverable work products in the architecture work product set have:
  • Passed evaluation.
  • Been accepted by the customer.
  • Been delivered to the customer.

Tasks

Architecting typically involves the following producers performing the following architecting tasks in an incremental, iterative, parallel, and time-boxed manner:

• Business Strategy Team, which performs:
  • Architecture Reuse
  • Business Object Modeling
  • Business Process Modeling
  • Business Case Development
  • Application Selection
  • Architecture Documentation
  • Architecture Integrity Assurance
• Technology Strategy Team, which performs:
  • Architecture Reuse
  • Technology Partner Selection
  • Technology Vendor Selection
  • Technology Strategy Production
  • Architecture Documentation
  • Architecture Integrity Assurance
• Architecture Team, which performs:
  • Architecture Reuse:
    • Reference Architecture Reuse
    • Potential Component Identification
    • Potential Component Evaluation
    • Potential Component Selection
    • Vendor And Component Evaluation And Selection
  • Architecture Prototyping
  • Architecture Production:
  • Architectural Mechanism Production
  • Architectural Patterns Selection
  • Architecture Analysis:
    • Performance Modeling
  • Architecture Documentation
  • Architecture Integrity Assurance
• Software Development Team, which performs:
  • Architecture Prototyping

The following diagram illustrates the temporal relationships between architecture tasks:

Environments

Architecting is typically performed using the following environment(s) and associated tools:

• Reuse Environment:
  • Database management system
  • Repository search tool
  • Configuration management tool
• Engineering Environment:
  • Whiteboards
  • Word processing tool
  • Modeling tools
  • LowerCASE tools
  • Configuration management tool

Work Products

Architecting typically results in the production of some or all of the following architecture work products:

• Business Engineering:
  • Class Responsibility Collaborator (CRC) Card
  • Business Object Model
  • Business Process Model
  • Business Organization Chart
  • Application Business Case
  • Application Strategy
  • Relationship Strategy
  • Technology Strategy
  • Business Architecture Document
  • Business Transition Plan
  • Reuse Strategy
• System Development:
  • Contact Center Architecture Document
  • Data Center Architecture Document
  • System Architecture Document
  • Information Architecture Document
  • Software Architecture Document
  • Software Architecture Prototype

Phases

Architecting tasks are typically performed during individual phases as documented in the following table:

Guidelines

• An architecture must fulfill (and is therefore validated against) the architecturally significant requirements including:
  • Functional requirements,
  • Data requirements,
  • Interface requirements,
  • Quality requirements, and
  • Constraints.
• The architecture drives and constrains the tactical (i.e., detailed) design.
• The architecting activity is typically concentrated in the phases and builds near the start of a development cycle if an iterative and incremental approach is used.
• This activity is documented using the typical configuration for large projects. It is intended to be configured (i.e., instantiated, extended, and tailored) to meet the needs of specific endeavors.
• The preconditions of this activity should be the union of the preconditions of its constituent tasks.
• The completion criteria for this activity should be the union of the postconditions of its constituent tasks.