Enterprise Architecture

Systems and software engineering — Architecture description ISO/IEC/IEEE 4201 iso-architecture.org

- this is the latest edition of the original IEEE Std 1471:2000, Recommended Practice for Architectural Description of Software-intensive Systems.

Defining Architecture iso-architecture.org

- a useful definition of architecture, with comments on alternate definitions. TOGAF does not distinguish between architecture and architecture descriptions. 

A Conceptual Model of Architecture Description iso-architecture.org

The Standard is organized around the terms and concepts of the diagram below. It depicts the contents of an AD and the relations between those content items when applying the Standard to produce an Architecture Description to express an Architecture for some System of Interest.

Architecture Description

An Architecture Description is a work product used to express the Architecture of some System Of Interest. The Standard specifies requirements on ADs. An AD describes one possible Architecture for a System Of Interest. An AD may take the form of a document, a set of models, a model repository, or some other form (AD format is not defined by the Standard).

Stakeholder

Stakeholders are individuals, groups or organizations holding Concerns for the System of Interest. Examples of stakeholders: client, owner, user, consumer, supplier, designer, maintainer, auditor, CEO, certification authority, architect.

Concern

A Concern is any interest in the system. The term derives from the phrase “separation of concerns” as originally coined by Edsgar Dijkstra. Examples of concerns: (system) purpose, functionality, structure, behavior, cost, supportability, safety, interoperability.

Architecture Viewpoint

An Architecture Viewpoint is a set of conventions for constructing, interpreting, using and analyzing one type of Architecture View. A viewpoint includes Model Kinds, viewpoint languages and notations, modeling methods and analytic techniques to frame a specific set of Concerns. Examples of viewpoints: operational, systems, technical, logical, deployment, process, information.

Architecture View

An Architecture View in an AD expresses the Architecture of the System of Interest from the perspective of one or more Stakeholders to address specific Concerns, using the conventions established by its viewpoint. An Architecture View consists of one or more Architecture Models.

Architecture Model

A view is comprised of Architecture Models. Each model is constructed in accordance with the conventions established by its Model Kind, typically defined as part of its governing viewpoint. Models provide a means for sharing details between views and for the use of multiple notations within a view.

Model Kind

A Model Kind defines the conventions for one type of Architecture Model.

Reference Model for ISEB Certificates in Enterprise and Solution Architecture bcs.org

Enterprise and Solution Architecture avancier.co.uk

- valuable extensions to TOGAF 

Business Executive's Guide to IT Architecture  opengroup.org

A data architecture for IT Service Management  erp4it.typepad.com

Δ Reference models are also conceptual data models.

Enterprise Architecture Body of Knowledge | EABOK mitre.org

Federal Enterprise Architecture | FEA

Federal Enterprise Architecture | FEA whitehouse.gov

a criticism of FEA is available here: Why Doesn't the Federal Enterprise Architecture Work?  tmiconsulting.wordpress.com

The Common Approach to Federal Enterprise Architecture whitehouse.gov

- includes the following technology principles

• Data and information exchange should be based on open standards 

• Privacy considerations must be designed into every data solution 

• Use well documented interfaces built on non-proprietary open platforms using standard platform independent data protocols (such as XML) 

• Application platforms should be virtualized whenever possible 

• Open-source software solutions should be included in alternatives analyses 

• Use cloud-based application, platform, and infrastructure hosting designs whenever possible to promote scalability, cost-efficiency, and metering 

• Convergence in voice, data, video, and mobile technologies supports infrastructure consolidation, which should be pursued wherever possible 

• Host solutions must be compliant with federal policy and standards (e.g., Trusted 

• Internet Connection, IPv6 routing, and PIV authentication) 

• Desktop/mobile solutions must be compliant with the latest US Government 

• Configuration Baseline standard 

• Security controls must be designed into every technology solution 

- describes the Collaborative Planning Methodology (CPM)

- defines Reference Architecture: 

A “Reference Architecture” is an authoritative source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and solutions. 

Reference Architectures solve a specific (recurring) problem in a problem space; explain context, goals, purpose, and problem being solved including when and how Reference 

Architecture should be used; and provide concepts, elements and their relationships that are used to direct/guide and constrain the instantiation of repeated concrete solutions and 

architectures. Reference Architecture serves as a reference foundation for architectures and solutions and may also be used for comparison and alignment purposes. There may be 

multiple Reference Architectures within a subject area where each represents a different emphasis or viewpoint of that area. A Reference Architecture for one subject area can be a 

specialization of a more general Reference Architecture in another subject area. The level of abstraction provided in a Reference Architecture is a function of its intended usage. 

- defines artifacts by domain 

- defines reference models: 

• Performance Reference Model - PRM 

• Business Reference Model - BRM 

• Data Reference Model - DRM 

• Application Reference Model - ARM 

• Infrastructure Reference Model - IRM 

• Security Reference Model - SRM