Survey of Architecture Frameworks

"The AF-EAF does not define the AF-EA content, rather it consists of various approaches, models, and definitions for communicating and facilitating the presentation of key architecture components (i.e. architecture vision, governance, principles, guidance, products, etc.) required for the development and integration of AF architectures. The AF-EAF establishes a common foundation for understanding, comparing and integrating architectures and as such provides the overarching guidance for generating AF architectures."

[All quotes from AF-EAF v2.01, 6 June 2003]

"Divided into modules that cover processes for enterprise architecture and solution architecture, a documentation framework (with scores of architectural entities, catalogues, matrices and diagrams, and a modelling language based on ArchiMate), related guidance and techniques, and advice on architecture roles and governance." [website]

Layers: Business, Application, Technology.

Viewpoints: Introductory, Organization, Actor Cooperation, Business Function, Business Process, Business Process Cooperation, Product, Application Behavior, Application Cooperation, Application Structure, Application Usage, Infrastructure, Infrastructure Usage, Implementation and Deployment, Information Structure, Service Realization, Layered, Landscape Map, Stakeholder, Goal Realization, Goal Contribution, Principles, Requirements Realization, Motivation, Project, Migration, Implementation and Migration. web

Based upon TOGAF, "ArchiMate standard does not provide its own set of defined terms, but rather follows those provided by the TOGAF standard."

"An architecture framework specifies a method of organising an enterprise or systems architecture into a collection of views that are consistent and complementary. The views can be textual, tabular,diagrammatic, or pictorial."

"The Australian Defence Architecture Framework (AUSDAF) is also based on DoDAF. It includes a set of Common Views (CVs) instead of All Views (AVs) and it is likely that the next revision [2] will contain additional views such as Strategic Views, Acquisition Views and Human Views."

It is difficult to find much information on AUSDAF. [Quotes from: Harris, Graham, King Bieri, "From DAF To Sim: Simulation Support To Capability Engineering"]

Viewpoints: functional, logical, technical, information, driver/vehicle operations, value/net.

M. Broy et al., Automotive Architecture Framework, IBM and Technische Universitaet Muenchen, 2009. [pdf]

BPEAM includes: a set viewpoints for describing EAs based on an integrated metamodel covering key concerns of different EA stakeholders with a suite of analysis techniques and patterns; a standard approach for EAM rollout as well as a set of governance practices for an organization-specific EAM; and an adaptable method for managing the EA both from a strategic as well as an operative point of view.

Viewpoints: the following three being most prominent: 1) Masterplan (Information systems and technical components over their life cycle information: in development from/to, in production from/to, etc.); 2) Landscape (Information systems mapped to the supported business processes at business units, or products at business units); 3) Information flow (Information systems and their connecting information flows; the latter detailed with transferred business objects as well as the degree of automation). BPEAM also uses a Portfolio matrix (applicable to different architecture elements and dimensions) which is not a viewpoint in the narrow sense.

BPEAM is supported with an open-source EAM tool, iteraplan, that supports the viewpoints and the integrated metamodel. [website] [book]

"The CEAF is a framework which, in addition to the architectural standards, defines the processes and the organisation necessary to enable it to function."

Stakeholder perspectives: Business; Functional; Application; and Technical. [pdf]

Viewpoints: All; Capability; Data and Information; Operational; Project; Services; Standards; and Systems. [website] DoDAF 2.0 volumes [1], [2], [3].

"Dragon1 is build around a process model, a service model and a product model, enabling controlled, structured and repeatable creation and usage of enterprise architecture designs, reference architectures and architecture descriptions in projects and in organizations."

This seems to be a new effort. Very little detail (on stakeholders, concerns, viewpoints, etc.) is yet available. [website] [wiki]

Viewpoints: Infrastructure, Data, Applications, and Organization.

Model kinds ("diagram types"): system block diagrams, platform diagrams, interoperability diagrams, function block diagrams, and cut-out diagrams.

[Boar, B.H., Constructing Blueprints for Enterprise IT Architectures, Wiley, 1998.]

"E2AF by itself is a Communication Framework describing the topics and relations that can be addressed during an architecture program. The purpose of E2AF is to communicate with all the stakeholders involved in the program."

Extended enterprise viewpoint sets: Economic, Legal, Ethical and Discretionary.

Quotes from: [web]

"The objective of the EAM Pattern Catalog is to complement existing Enterprise Architecture (EA) management frameworks, which provide a holistic and generic view on the problem of EA management, and to provide additional detail and guidance needed to systematically establish EA management in a step-wise fashion within an enterprise."

"The EAM Pattern Catalog is a pattern language for EAM, which is made up of 164 EAM patterns and EAM anti patterns. Three types of EAM patterns are differentiated. M-Patterns document processes and roles required to address the concerns of companies in EAM. These M-Patterns use V-Patterns, which document viewpoints for EAM. In order to be able to create views according to the viewpoints documented in V-Patterns, certain information is required. This is documented as information models (metamodels) in I-Patterns. Those three EAM pattern types constitute proven practices found at project partners, in academia, or in literature. Complementing these EAM patterns, EAM anti patterns document solutions, which have proven not to be successful to prevent blind alleys." [website]

• "To enumerate, at a high level, each of the hardware, software, and data standards that are part of the EPCglobal Architecture Framework and show how they are related.
• To define the top level architecture of shared network services that are operated by EPCglobal, its delegates, and others.
• To explain the underlying principles that have guided the design of individual standards and service components within the EPCglobal Architecture Framework.
• To provide architectural guidance to end users and technology vendors seeking to implement EPCglobal standards and to use EPC Network Services."

"ESAAF is based on established methodologies, such as MODAF and TOGAF, aiming to enhance on the following aspects:

• Adding space domain specific concepts
• Increasing detail of modelling, where/when needed
• Improving technical and logical consistency
• Enhancing model exploitation, including properties inference
• Reducing visible complexity of the generic methodology."

[briefing] [paper]

An architecture framework, metamodel and tool set licensed under the GNU GPL.

Layers: Business, Application, Information and Technology.

Viewpoints (within each layer): Conceptual, Logical and Physical. [website]

"The Framework provides a sustainable mechanism for identifying, developing, and documenting architecture descriptions of high priority areas built on common business areas and designs that cross organizational boundaries."

Architecture Description: "An architecture representation or blueprint prepared in accordance with a framework."

Viewpoints: Business; Design; Focus: Data (what), Application (how), Technology (where)

Stakeholders: Planner, Owner, Designer, Builder, Subcontractor

[website], FEAF, version 1.1, 1999 [pdf]

Based on Functions, Flows, Layers, Views. [website]

"The Architecture Description Framework governs which architecture types to use and which templates to use when describing a system from an architectural point of view. These templates are today based on NATO/NAF v2, but modified to support additional demands."

"The architecture description framework supports: three horizons and levels of detail: long-term, medium-term and short related; six aspects of architecture: domain (business), information system, information, infrastructure, security and governance; and [the] definition and deployment of systems"

FMLS-ADF, issue 3, 2007 [pdf]

Architecture framework: "the theoretical constructs used to organize an enterprise's thinking around the subject of architecture"

Viewpoints: Enterprise Business, Enterprise Information and Enterprise Technology. Its "aspect-oriented approach allows for the articulation of additional viewpoints, should the organization require them." [pdf]

Viewpoints: Function, Information, Resource, Organization; Customer Service and Product, Management and Control; Human Implemented Tasks, Auotmated Tasks; Software, Hardware.

ISO 15704 Industrial automation systems — Requirements for enterprise-reference architectures and methodologies, 2000. Based on the life cycle model of [CIMOSA] and [GERAM].

Aspects: functional aspect, operational aspect. [Youngs R, et al. A standard for architecture description. IBM Systems Journal 1999, 38(1)]

"Information FrameWork models identify and define over 80% of the data, process and software component requirements of a universal financial institution, operating in an international environment. The Information FrameWork model set is highly detailed, customizable and built on open industry standards including UML and XML. Data can be mapped from one model to another. By providing a set of predefined business templates, a framework enables the scoping, specification and design of information solutions to business challenges." [IFW-1] [IFW-2] (original creator)

Viewpoints: Logical, Physical, Process, Developer, Scenarios. [doi]

[website]

Viewpoints: Operational, Systems, Technical, Strategic, Acquisition [website]

Viewpoints: All; Capability; Operational; Service-Oriented; Systems; Technical; and Programme. [pdf]

RASDS is intended to provide a standardized approach for description of data system architectures and high-level designs. [pdf]

ISO/IEC 10746-1 Information technology — Open Distributed Processing — Reference Model: Overview.

Viewpoints: Enterprise, Information, Computational, Engineering, and Technology. [website]

C. Hofmeister, R. L. Nord, and D. Soni. Applied Software Architecture. Addison-Wesley, 2000

N. Rozanski and E. Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perpectives. Addison Wesley, 2005

Viewpoints: functional, information, concurrency, development, deployment, operational.

Perspectives: security, performance and scalability, availability and resilience, evolution.

TRAK is based on MODAF. It was developed for rail but is domain agnostic and can be used wherever there is a system to be described. TRAK has been designed from the outset to conform to ISO/IEC 42010.

TRAK has 5 perspectives and 22 architecture viewpoints. [Viewpoints] Architecture view content is defined using tuples (object - relationship - object) with additional rules to enforce consistency across an architecture description, based on a metamodel. [Metamodel]

More: [Wikipedia] [website]

"an architecture description is a way to describe a system using models. In this paper a collection of models forms an architecture description framework. If that collection is comprehensive it may be called a universal framework."

"In this paper we will take a brief tour of the several models that could be used today, none of which are comprehensive, followed by a description about how subsets of them can be assembled into a universal set coordinated with the content of a universal specification format and a way to establish traceability across the gaps when using one particularly troublesome pair of models." [text] [slides]

"The basic idea of xAF is that there is a root extensible framework (xAF0), on the basis of which other (extensible) frameworks can be defined as extensions of this root framework. Defining an xAFi as the extension of one or more existing xAFi's is guided by strict extension rules. Two rules have been proposed, which seems to be sufficient: the specialisation rule and the integration rule. By applying these rules, one builds up a lattice of xAFi's. Theoretically, it is possible then to reformulate any existing architecture framework as a particular xAFi in this lattice. This makes the xAF a universal basis for evaluating and comparing frameworks. But it also makes the xAF a method for developing one's own framework in such a way that the developed framework satisfies high quality standards, and that it is easily comparable to existing frameworks." [website]