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."

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

"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, TUM-I0915, IBM and Technische Universitaet Muenchen, 2009.

"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: [E2AF]

"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."

[EAM-PC]

"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

[FEAF], version 1.1, 1999.

"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."

TR G00133132, The Gartner Group, November 2005.

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

ISO 15704 Industrial automation systems — Requirements for enterprise-reference architectures and methodologies, 2000

"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: Operational, Systems, Technical, Strategic, Acquisition [MODAF]

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

RM-ODP calls itself an architecture framework. ISO/IEC 10746-1 Information technology – Open Distributed Processing – Reference Model: Overview.

Viewpoints: Enterprise, Information, Computational, Engineering, and Technology.

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:

Perspectives:

TRAK is based on MODAF. In adapting the MODAF metamodel domain-specific constructs have been removed and some subtle but important changes made, for example in representing a 'system' as a Capability Configuration, rather than as a type of Physical Asset as it is within MODAF. allowing for a better and more generic model of a system and its physical, software and human parts. The views are domain-free but there is a lot of historical interest in views overlaid on geographical layouts i.e. instances and location is important so there might be rail-oriented views in the future. This will depend on the analysis of the diagrams produced by the various functional disciplines and whether/how they fit into an architecture.

Viewpoints: A list of the viewpoints and the concerns addressed by each is at TRAK viewpoints.

TRAK also has the following perspectives:- Capability: concerned with the overall enterprise and capabilities needed; Operational: concerned with the logical ‘what’ or problem; Procurement: concerned with projects and delivery of solutions (to provide the capabilities needed); Solution: concerned with the behavioural and physical aspects of the solution; Management: concerned with the management of the model, architectural views, the architecture task.

[TRAK]