Application Architecture

Definitions

Application Architecture

the overall architecture of a single application

Responsibilities

The typical responsibilities of an Application Architecture are to:

• Fulfill Requirements.
  Provide an overall application structure and set of mechanisms that fulfill all architecturally significant requirements of the application.
• Drive Designs & Implementations.
  Influence and constrain the designs and associated implementations of the application’s components.
• Improve Communication.
  Improve communication among the application’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 application’s stakeholdlers (e.g., members of the customer, development, and subcontractor organizations) concerning the:
  • Architectural patterns and styles to be reused on the application,
  • Top-level strategic logical and physical structures (i.e., major functions, classes, processes, components, their responsibilities, and their relationships) of the application,
  • Most important, pervasive architectural mechanisms of the application, 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 application.
• Enable Scheduling.
  Provide a basis (e.g., components, mechanisms) for estimating the schedule of the application’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 Application Architecture are the application’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 Application Architecture are:

• Producers:
  • Architecture Team (Overall Application 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 application 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

An application 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.
• When relevant, the content management team and security team have been staffed and trained in architecting.
• The following inputs are available.

Inputs

The typical inputs to an application architecture include:

• Work Products:
  • A relatively complete version of the application 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.
• An application 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).
• A nontrivial application typically requires the production of one or more associated architectures.

Conventions

An application architecture is typically constrained by the following conventions:

• Work Flow
• Content and Format Standard
• Inspection Checklist

Examples

• A software-only application architecture.
• A system application architecture.
• A client/server application architecture.
• An n-tier distributed Internet application architecture.