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]

AF4MgtSys is a prototype of an architecture framework for Management Systems used in Organizations. The architecture framework is based upon a synthesis of standard management models and international standards (ISO 42010, ISO 15288, ISO 9000 and ISO 9001) and treats the management system as a people-intensive sociotechnical system (people, process and technology). AF4MgtSys has been created using the Compass Architecture Framework Framework (CAFF) to identify concepts, principles, systems and viewpoints. The concepts, principles and systems were created considering the “Enterprise as a System of Systems”. [website]

Feedback on the prototype architecture framework and the use of ISO/IEC/IEEE 42010, and its applicability to the enterprise would be appreciated. [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.

Based upon TOGAF, “ArchiMate standard does not provide its own set of defined terms, but rather follows those provided by the TOGAF standard.” [ArchiMate Forum]

ARIES “consists of (1) the enterprise element model, specifying ten unique elements for seeing the whole enterprise; (2) the architecting process model, with eight activities; and (3) selected techniques and templates, some developed through our research and others drawn from existing practice”.

[All quotes from D.J. Nightingale and D.H. Rhodes, Architecting the Future Enterprise, MIT Press, 2015.

“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]

BCA is a hexagonal frustum by design with the BCA as the apex of the figure. A network of BCAs form the business foundation across and beyond the enterprise.

“In order to develop an integrated view of an enterprise, many different views of an organization are typically developed. The key views of the enterprise within the business architecture are: 1) the Business Strategy view, 2) the Business Capabilities view, 3) the Value Stream view, 4) the Business Knowledge view, and 5) the Organizational view.” [BAWG]

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]

Original work on CAFCR took place in the 1980s. [website, thesis]

CAFCR+ adds a life cycle viewpoint. The Embedded Systems Innovation group of TNO in The Netherlands provides these introductions (via youtube) [CAFCR+ Introduction, Architect's Way of Working, Business Context]

Levels of Scope: International, National, Federal, Sector, Agency, Segment, System, Application

“Sub-architecture domains” (i.e., viewpoints): Strategic, Business Services, Data and Information, Enabling Applications, Host Infrastructure, Security

CAFEA includes FEAF-II which supercedes FEAF (see entry below). [pdf]

CBDI-SAE for SOA “ is a comprehensive, defined approach for service architecture including taxonomy, classification and policies together with repeatable service engineering processes that guide the delivery of the agile enterprise, implemented in a knowledgebase with integrity between the architecture concepts, processes, tasks, techniques and deliverables.” [website]

“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]

“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.”

[Dragon1 resources]

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.” [pdf]

Layers: Business, Application, Information and Technology.

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

FEAF v2 “consists of a set of interrelated 'reference models' that describe the six sub-architecture domains in the framework: Strategy, Business, Data, Applications, Infrastructure and Security” [website]

FFLV is a meta-EA that links the Business Architecture (modelled on GODS) with the Technology and Human resources tiers and metamodels.

Any Enterprise can be described by its Functions (structure) and Flows (behaviour) in the Business layer and by Technology and People resource layers performing the business Functions and Flows.

An EA can be illustrated in various Views of the above that illustrate various stakeholders’ concerns. Information is a component of business Functions and Flows that is mapped onto data in the Technology Layer. The FFLV metamodel shows the links between the Business Functions, Flows and Information and the components in the Technology and People Layers and Views.

GODS covers a generic one-page business architecture than can be customised for most enterprises. It consists of: Governance (coordinating all other activities), Operations (making and delivering products), Development (developing the products and the enterprise itself) and Support (providing technology, financial, HR, transportation, procurement ... support to all other functions); and the key generic enterprise business processes (flows).

Any Enterprise Business Architecture, described in the EA business layer, can be built on the GODS template. GODS aligns to Porter’s Value Chain model. The FFLV-GODS framework was built by analogy with the human body anatomy and physiology. [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]

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)]

Iran EA Framework (IEAF) is a framework that includes 4 parts: Framework and Methodology; National Reference Models; Sector Reference Models; and a promotion program.

EA Domains (as Viewpoints): Strategy, Business, Data, Application, Technology, Security [website]

IFW consists of a 50 cell framework.

Viewpoints: organization, business and technical views, including models for an organization model, financial services data model, financial services function model, financial services workflow model, financial services object model and critical business process model. [What is IFW?, pdf]

MEGAF provides tools to create, store, and manage viewpoints, views, and concerns; define correspondences among architectural elements; and perform consistency and completeness checks. It is implemented via Eclipse plugins. [website]

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

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

PRISM was is a multi-client research service of Index Systems and Hammer and Company. In 1986, one of the PRISM focused research topics was Dispersion and Interconnection: Approaches to Distributed Systems Architecture. Fifty sponsors participated in the research, including AT&T, IBM, Xerox and DEC. [pdf]

“The PRISM model, being from 1986 (Davenport 1989; Richardson et al 1990) is among the first published enterprise architecture frameworks, and as such actually precedes the Zachman framework (Zachman 1987).” [Greefhorst and Proper, Principles in an Enterprise Architecture Context]

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]

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

“Software Systems Architecture is a practitioner-oriented guide to designing and implementing effective architectures for information systems. It is both a readily accessible introduction to software architecture and an invaluable handbook of well-established best practices. It shows why the role of the architect is central to any successful information systems development project, and, by presenting a set of architectural viewpoints and perspectives, provides specific direction for improving your own and your organization’s approach to software systems architecture.”

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

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

[website]

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

“SABSA is a model and a methodology for developing risk-driven enterprise information security architectures and for delivering security infrastructure solutions that support critical business initiatives. The primary characteristic of the SABSA model is that everything must be derived from an analysis of the business requirements for security, especially those in which security has an enabling function through which new business opportunities can be developed and exploited.”

The SABSA Model comprises six layers: the Business View: Contextual Security Architecture; the Architect’s View: Conceptual Security Architecture; the Designer’s View: Logical Security Architecture; the Builder’s View: Physical Security Architecture; the Tradesman’s View: Component Security Architecture; the Facilities Manager’s View: Operational Security Architecture.

“It follows closely the work done by John A. Zachman in developing a model for enterprise architecture, although it has been adapted somewhat to a security view of the world. Each layer represents the view of a different player in the process of specifying, designing, constructing and using the business system.”

Model-Based Engineering of Embedded Systems: The SPES 2020 Methodology 2012

Advanced Model-Based Engineering of Embedded Systems: Extensions of the SPES 2020 Methodology 2016

Model-Based Engineering of Collaborative Embedded Systems: Extensions of the SPES Methodology 2021

SpesML modeling language plug-in for the tool MagicDraw. Information about SpesML is available on [github].

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. Architecture view content is defined using tuples (object - relationship - object) with additional rules to enforce consistency across an architecture description, based on a metamodel. [Viewpoints, Metamodel, 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]