Architecture Design Templates

Mark Skilton
Dec 6, 2004
6 min read

Ontology of Architecture Design

The definition of Architecture design documentation can cover a wide spectrum of scope from business level architecture to specific solutions and detailed technical architecture design.

The current practice across projects and clients can vary significantly depending on the terminology and modelling standards and approach used.

Company methodology standards contains guidelines that embody the key architecture elements of design, these commonly include:

The key business drivers and problem statement to be solved
A representation of the proposed technical design platform at a conceptual level
References to the specific Business requirements and Technical policies that need to be solved
A definition of the IDE and Modelling ontology standards to be used e.g. UML, XML..
A definition of the Components and Data of the design – also often called the Static design
A definition of the functional capabilities, data flows of what needs to be processed and delivered– also often referred to as dynamic design.
A definition of the qualities of services (QoS) - non-functional requirements of the solution

Extensions beyond this above set are then specific architectural considerations relating to three aspects:

Scope of organisation
This is the level at which the architecture is be used to address. This is typically defined in process terms such as:
Business Architecture (Strategy level)
Solution (Application level)
Platform (Technical Level)
Deployment (Run-time Level)

Specific capabilities in context
This is the definition of the specific competencies that architecture is trying to achieve. This can be seen from a run-time platform perspective for example:
Service Oriented Architecture (SOA)
Process Oriented Architecture (POA)
Gateway Inbound/Outbound
Hub deployment Architecture
Portal Composite Architecture
And others…

Specific levels of abstraction
Conceptual – not business or technology specific – a common generic view
Logical – business specific but not technology platform capability constrained
Physical – both business specific and technology platform specific and constrained

2 Summary of Content types

Table 1 Summaries of Content types

3 Example Architecture Specifications

3.1 Application Context Model Case study 1 example

Background
Purpose
Scope
Key Decisions
Static Models
Application Context
Message integration
System / performance Management
Data Integration
Dynamic Models
Message integration
System / Performance Management
Data Integration
Appendix
Tables
Application Component Definitions
Component Flow Definitions
Message Interaction Component Definitions
Message Interaction Flow Definitions
System / Performance Management Component Definitions
System / Performance Management Flow Definitions
Data Integration Component Definitions
Data Integration Flow Definitions
Figures
Application Context Diagram
Static Message Interaction Diagram
Static System / Performance Management Diagram
Static Data Integration Diagram
Dynamic Message Integration Diagram
Dynamic Systems / Performance Management Integration Diagram
Dynamic Data Integration Diagram

3.2 Solution Design Case study 2 example

Introduction
Objectives
Scope of document
Intended readership
Risks
Issues
Assumptions
End to end solution context
Scope context
End-2-end scope
……app scope
Sub-system architecture
Platform 1.. Domain
Platform 2.. Domain
Platform n. domain…
Functional Architecture
Fundamentals of …app functionality
Messages required to support …app
Message between app1…app2
Message between appx..appy….
New or changed components with the.. app
App1
App n…
Platform Domain merge
Platform Domain Separation (in other words this is partitioning)
Deployment architecture
Deployment overview
Platform 1.. Domain
Platform 2.. Domain
Platform n. domain…
Data Architecture
Workflow configuration data
Data Transformation
App.. Data cache
….. Database
Requirements Compliance
Functional Requirements
Non-functional requirements
Volume model (changes to current loads)
Appendix
Figures
Appp. Context
… interface architecture
example interface file for message xx..
Message routing service
Current Transformer design
Revised Transformer design
… app logical deployment design
Tables
Changed messages
App1..app2 messages
Appx .. appy messages …
Component impact table
Line Qualification messages
Volumetrics

3.3 Dynamic Design Case study 3 example

Introduction
Objectives
Scope
Intended Readership
Approach
Service Model
Overview of functional requirements
Approach to Service definition
Overview of approach
Adherence to Functional Design Principles
Reuse of existing services
Designing for re-use
De-coupling
End-2-end processes should provide only top level process control
App.. solution
Delivery of required functionality
App1 to app2
High Level description
Object Sequence Diagram
Object Sequence Diagram Service and message map
Object Sequence Diagram Detail Description
App x to app y …..
High Level description
Object Sequence Diagram
Object Sequence Diagram Service and message map
Object Sequence Diagram Detail Description
Supplementary requirements for service components
Event logging requirements
Error handling requirements
State Model
Persistent Business Objects
App.. cache state model
Data Model
Overview of data requirements
Approach to data definition
Overview
Adherence to design principles
Minimise Persistent data with the app.. (Hub)
Minimise Data Validation within the app.. (Hub)
Re-use existing data definitions
Use Structured XML
Transform to and from a app .. (Hub) format
Use a dedicated transformation service
Bulk data transfer
Data to be handled by the app.. (Hub)
Messages
Message definitions
Business Entities Handled
Database design
Non-functional Model
Non-functional characteristics of the proposed solution
Performance and scalability
Availability and resilience
Security Responsibilities and characteristics
Decomposed non-functional requirements
Decomposed Security requirements
Security Vulnerabilities
Security Recommendations
Testability Considerations
Testing Strategy
Unit testing Strategy
Functional testing Strategy
Component test Strategy
App.. (Hub) System test Strategy
Non-functional testing strategy
Specific testing requirements
Functional Testing
Non-functional testing
Test Harness requirements
Risks, Issues and Assumptions
Risks related to this design
Design issues
Design non-compliance
Other Design Issues
Design Assumptions
Appendix
Figures
App1. to app2 Object sequence Diagram (OSD)
App x to app y OSD….
Hub Cache State Model
Tables
App. (Hub) design documentation
Overview of functional requirements
App.. (Hub) Service components
Test Scenarios
Events to be logged
Error detection behaviour
App. (Hub) Release (Version x..) data
App. (Hub) Release (Version x..) messages
Availability modes of sub-components
Scalability options of sub-components
Anticipated Concurrent data Volumes
App.. (Hub) component resilience issues / derived availability requirements
App.. (Hub) component security issues / derived requirements
Risks related to this design
Other Design issues (?)
Design Assumptions

3.5 Static Design Case study 4 example

Introduction
Objectives
Scope
Intended Readership
Approach to app. (Hub) design
Approach to app. (Hub) static design
Design Conventions
Context for app. (Hub) Development
Role of the hub
Key Design Principles
App. (Hub) Architecture
Hub Connectivity
Connectivity at a conceptual level
Approach to hub external interfaces
Hub component architecture
Overview of component architecture
Hub Layers
External Interface components
Data Transformation, Routing and Logic Components
Other Hub Components
Functional requirements
Non-functional Requirements
Performance and scalability
Throughput
Response times
Concurrent Object Volumes
Availability and resilience
Explicit and Implicit Availability Requirements
Addressing Availability and Resilience
Security
Private Circuits
Broadband
Testability considerations
Testing Strategy
Functional Testing Strategy
Non-functional testing Strategy
Specific Testing Requirements
Functional Testing
Non-Functional Testing
Test Components
Test harness
Test Stubs and other test Components
Operational Support Considerations
Introduction
Hub Operation Tools
Logging of hub events
Error handling
Pre-emptive error management
Pro-active Error Management
Reactive Error Management
Systems and Application Management
Systems management
Systems Monitoring
Configuration Maintenance
System Back-up and Restore
System Start-up and Shut-down
Housekeeping
Data Archiving and Retention
Reconciliation
Disaster Recovery
Other Design Considerations
Future Development Capability
New product Lines
Upgradability
Maintainability and Reusability
End-user considerations
Regulatory Requirements
Audit Requirements
Risks, Issues and assumptions
Risk related to this design
Design Issues
Design Non-compliance
Other Design issues
Design Assumptions
Appendix
Tables
Component naming standards
Hub External Interfaces
Hub External Interface components
App. Platform 1 (e.g. WLI). Data transformation , routing and logic components
App. Platform x. (e.g. eLink) Data transformation , routing and logic components
Anticipated throughputs models
Cache volumetric models
Availability and resilience approach for specific hub components
Security at … interfaces
Test harness (environment)
Test stubs (the test component setup)
Hub operational tools
Pro-active error management
Reactive error handling in the app.. (hub)
App. (Hub) data to be backed up
App. (Hub) data to be excluded from back-up
Risks related to this design
Design non-compliance
Other Design issues
Design Assumptions
Figures
Hub connectivity
Overview of the hub architecture
Hub component architecture