The specification of architecture frameworks is one area of standardization in ISO/IEC/IEEE 42010:2011 (the international revision of IEEE 1471:2000).
WG42 is collecting examples of architecture frameworks, listed below. Items in grey are entries in progress and should not be considered definitive at this time.
Corrections and additions may be sent to the webmaster. Please include: Name, Purpose, Scope, Brief Description and URL (or literature references).
Thanks to the following for their inputs: Takahiro Yamada (RASDS), Sly Gryphon (IFW), Alexander Ernst (EAM-PC), Nic Plum (TRAK), Graham Berrisford (Avancier Methods), Kevin Smith (PEAF), Mark Paauwe (Dragon1), Danny Greefhorst (various), Christian Schweda (BPEAM), Nick Rozanski (RW), Andrew Guitarte (BCA), Neil C. Greenfield (SABSA), Daniele Gianni (ESA), Jose L. Fernandez (PPOOA), Patrizio Pelliccione (MEGAF), Roger Evernden (IFW), Vanessa Douglas-Savage (QGEA), Adrian Grigoriu (FFLV+GODS), Dan Haner (DODAF), David Sprott (CBDI-SAE), Anders W. Tell, Harris Veziris (eTOM), Ger Schoeber (CAFCR), Bruce McNaughton (AF4Orgs), Damian Andrew Tamburri (SQUID), Joris van den Aker (CAFCR+), Ian Glossop (ARIES).
|AF-EAF||Air Force Enterprise Architecture Framework||
“The AF Enterprise Architecture Framework (AF-EAF) provides a logical structure for classifying, organizing and relating the breadth and depth of information that describes and documents the Air Force Enterprise Architecture (AF-EA).”
|Air Force IT systems||Communication, Guidance, Enterprise Architecture Descriptions||
“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]
|AFIoT||IEEE P2413 – Architecture Framework for the Internet of Things||“This standard defines an architectural framework for the Internet of Things (IoT), including descriptions of various IoT domains, definitions of IoT domain abstractions, and identification of commonalities between different IoT domains.”||“The architectural framework for IoT provides a reference model that defines relationships among various IoT verticals (e.g., transportation, healthcare, etc.) and common architecture elements. It also provides a blueprint for data abstraction and the quality ‘quadruple’ trust that includes protection, security, privacy, and safety. Furthermore, this standard provides a reference architecture that builds upon the reference model. The reference architecture covers the definition of basic architectural building blocks and their ability to be integrated into multi-tiered systems. The reference architecture also addresses how to document and, if strived for, mitigate architecture divergence. This standard leverages existing applicable standards and identifies planned or ongoing projects with a similar or overlapping scope.” [website]|
|AF4Orgs||Architecture Framework for Organisations||To provide the instructions to create an Architecture Description for a whole organisation or a part of an organisation.||A whole organisation or part of an organisation situated in its environment.||Enterprise, Organisation, Teams within a Team.||
AF4Orgs is a prototype of an architecture framework for organisations. 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 organisation as a people-intensive sociotechnical system (people, process and technology). AF4Orgs also uses the Framework for Architecture Frameworks to identify concepts and viewpoints.
Some testing has been done on the models. Feedback on the prototype, the use of ISO/IEC/IEEE 42010, and its applicability to organisations would be appreciated. [website]
|AGA||Australian Government Architecture Reference Models||The intent of this Australian Government Architecture (AGA) framework is to assist in the delivery of more consistent and cohesive services to citizens and support cost-effective delivery of Information and Communications Technology (ICT) services.||AGA provides a common language, to enhance collaboration, assist in describing and analysing IT investments, and assist in transforming Government.||Enterprise Architecture||
This document is targeted at architects from all disciplines practicing within Australian Government agencies including those that do not have an enterprise architecture practice or are just initiating an EA within their agency. Those involved in program management (e.g. program/project managers, business and investment analysts, systems engineers, application architects, systems developers, etc.) should also refer to this document. AGA is based on USA-FEAF. [PDF]
|AGATE||Atelier de Gestion de l’ArchiTecturE des Systemes d’Information et de Communication (AGATE)||“used to manage the architecture of communication and information systems (CIS)”||French weapons systems||Viewpoints: Stakes and Objectives in Context; Business; Services; Logical; and Technical (Implementation). AGATE metamodel is documented in UML. [website]|
|AM||Avancier Methods||Architecture framework and body of knowledge, distinct processes for enterprise and solution architecture, architecture description artefacts, guidance on organisation, roles and governance, and reference model||solution architecture, enterprise architecture||
“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]
|ARCHI||ArchiMate||“To provide a uniform representation for diagrams that describe enterprise architectures, the ArchiMate enterprise architecture modeling language has been developed. It offers an integrated architectural approach that describes and visualizes the different architecture domains and their underlying relations and dependencies.”||enterprise architecture||architecture description language||
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||Architecting Innovative Enterprise Strategies||“... the ARIES framework is designed to guide the exploratory phase of transformation.”||Enterprise transformation||concept architecture||
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.
|AUSDAF||Australian Defence Architecture Framework||
“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  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”]
|AAF||Automotive Architecture Framework||Architecture framework for the automotive industry||“an umbrella for the description of the entire vehicle system across all functional andd engineering domains”||
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||Business Capability Architecture||A Business Capability Architecture or BCA serves as a business foundation of the enterprise to enhance accountabilities and improve decision-making.||Enterprise architecture, Business architecture||
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]
|BDAF||Big Data Architecture Framework||[slides, paper]|
|BEAM||Business Enterprise Architecure Modeling||Business; Data/Info; Application; Security; and Technology. Developed at Ken Orr Institute, circa 2004. Not much information available. [website]|
|BPEAM||iteratec best-practice enterprise architecture management (EAM) method||BPEAM provides a toolkit for rolling out EAM in an enterprise and for gradually expanding EAM over time.||enterprise architecture management and IT strategy||
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.
|CAFCR||Customer Objectives, Application, Functional, Conceptual, and Realisation model||Method for multidisciplinary embedded systems architecting based on multiple views that are integrated by qualities and architectural reasoning.||Embedded systems||System architecting||
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]
|CAFEA||Common Approach to Federal Enterprise Architecture||To provide "guidance for a common approach to the practice of Enterprise Architecture"||"Executive Branch of the U.S. Federal Government"||enterprise architecture||
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||CBDI Service Architecture & Engineering (CBDI-SAE™) for SOA||
“CBDI-SAE provides a defined, structured approach to architecture and engineering tasks and deliverables that provides visible traceability from business requirements to implemented services. The structured approach provides the necessary level of formality over policy implementation to ensure governance over business requirements and architectural policies.”
|service oriented architectures||
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]
|CEA||CEA Framework: A Service Oriented Enterprise Architecture Framework (SOEAF)||Address challenges with current frameworks: “(1) defining process is heavy, prolonged and tedious (2) Keeping EA artifacts up-to-date is an awkward work. These challenges make the artifacts of EA useless and unreliable.”||enterprise||“CEA Framework involves a [Service Oriented] Roadmap that is completely compatible with ITIL and a Classification Schema that cover all aspects of organization, these aspects categorize according to Purpose, Pattern or Practice, Policy, Stakeholder and Resource.” [pdf]|
|CEAF||Commision Enterprise IT Architcture Framework (CEAF)||To provide “a common reference framework ... to empower the different stakeholders involved in information systems to plan and communicate on a mutual basis”.||“CEAF is an IT framework"—"not ... a generic enterprise framework”.||
“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]
|CIAF||Capgemini Integrated Architecture Framework||Enterprise architecture||Aspect areas: Business; Information; Information Systems; Technology Infrastructure; Security; and Governance. [pdf]|
|DoDAF||US Department of Defense Architecture Framework||To enable “the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries.”||US DoD||
Viewpoints: All; Capability; Data and Information; Operational; Project; Services; Standards; and Systems. [website]
|DNDAF||Department of National Defence/Canadian Armed Forces Architecture Framework||all DND/CF architecture activities||enterprise architecture||[website], [DNDAF viewpoints]|
|DRA1||Dragon1||Open method for visual enterprise architecture||enterprise architecture||
“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.”
|DYA||Dynamic Architecture||“to achieve ... ‘dynamic architecture’—architecture specifically aimed at agility and facilitating change. This applies to both aspects of architecture: content and process.”||IT architecture||“The Architectural Framework is divided into three high-level architectures (Business Architecture, Information Architecture, and Technical Architecture)—which are subdivided into domain architectures such as processes, data, and platforms—and three conceptual levels: general principles, policy directives, and models. The domain architectures make up the columns of the matrix, while the conceptual levels constitute the rows of the matrix.” [website]|
|EAB||Enterprise Architecture Blueprinting||EAB “provides a formal notational system for drawing and maintaining IT architectures, [called] the Enterprise Information Technology Architecture Blueprinting”. “EAB defines a communications system that allows a community of IT professionals to visualize architectures in a standard manner.”||IT architecture: infrastructure and application architectures||
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||Extended Enterprise Architecture Framework||Communication, Description||
“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]
|EAM-PC||EAM Pattern Catalog||A pattern-based approach to Enterprise Architecture Management||Enterprise architecture management||
“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]
|EEAF||US OMB Enterprise Architecture Assessment Framework||[website]|
|EPCAF||The EPCglobal Architecture Framework||“The EPCglobal Architecture Framework is a collection of hardware, software, and data standards, together with shared network services that can be operated by EPCglobal, its delegates or third party providers in the marketplace” to promote “the global adoption of the Electronic Product Code (EPC) and related industry-driven standards to enable accurate, immediate and cost-effective visibility of information throughout the supply chain”.||Probably better termed a “reference architecture” rather than a framework.||
|ESAAF||European Space Agency Architecture Framework||ESAAF is a "modelling methodology for supporting the decision making in SoS design and integration".||Space-based systems of systems (SoS).||
“ESAAF is based on established methodologies, such as MODAF and TOGAF, aiming to enhance on the following aspects:
|ESSAF||Essential Architecture Framework||An architecture framework, metamodel and tool set.||License: GNU General Public License||
Layers: Business, Application, Information and Technology.
Viewpoints (within each layer): Conceptual, Logical and Physical. [website]
|eTOM||Business Process Framework (eTOM)||Communications Service Providers, Entertainment Industry|
|EXAF||Extreme Architecture Framework||“a minimalist EA framework for an agile environment”||Enterprise IT architecture||Defines an enterprise as as “a collection of human activity and software systems”. Organizes thinking into a hierarchy of system types: sector, enterprise, business process, software application, software component; and several complementary viewpoints: activity, information, software, data, technology to describe the enterprise. [web]|
|FEAF||US Federal Enterprise Architecture Framework||“The Federal Enterprise Architecture Framework promotes shared development for common Federal processes, interoperability, and sharing of information among Federal Agencies and other Governmental entities.”||“The Federal Enterprise Architecture Framework v2 describes a suite of tools to help government planners implement the Common Approach.”||
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]
|FESS||Framework of Enterprise Systems and Structures||Provide an instrument for persons, managers to address the fundamental elements of an organisation/system and integrate their work.||General Architecting, Architectures||The FESS provides a general architecting approach and framework that offers an opportunity for systematic thinking, addressing the manifold of concerns emerging from organized activities on a larger scale. FESS is instrumental, work-oriented with focus upon architecting of fundamental elements and boundary objects of a system. [web]|
|FFLV+GODS||Functions-Flows-Layers-Views + Governance-Operations-Development-Support||
A frame structure that enables an EA to be readily designed by plugging components and models into their allotted framework spaces, including a development process, architecture principles, maturity models, and IT templates as parts of the overall method.
All industries and the whole enterprise illustrating the business process and information, people organisation and technology integrated operations.
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]
|FMLS-ADF||FMLS Architecture Description Framework 3.0 (SE)||To “enable description of architectures for systems with the qualities required by SwAF: Cost effectiveness through reuse of services and systems; Flexibility to support changing conditions and new unique missions, enabling a situation adapted system assembly and configuration – SitSyst; Support for service oriented behavior as well as integration of legacy systems; Enabling incorporation and use of commercially available systems; Enabling interoperability with coalition partners and civil governmental agencies; Supporting a system of system structure providing flexibility through loosely coupled systems elements”||“All FMLS 2010 systems in a system of system context”||
“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]
|FSAM||Federal Segment Architecture Methodology (FSAM)||[website]|
|GA||Garland and Anthony||software architecture method||J. Garland and R. Anthony. Large Scale Software Architecture: A Practical Guide Using UML. John Wiley and Sons, 2002|
|GEAF||Gartner’s Enterprise Architecture Framework||
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]
|GERA||ISO 15704 Generic Enterprise Reference Architecture||“requirements for enterprise-reference architectures and methodologies”||“all types of enterprise creation projects as well as any incremental change projects”||
Viewpoints: Function, Information, Resource, Organization; Customer Service and Product, Management and Control; Human Implemented Tasks, Auotmated Tasks; Software, Hardware.
|HEAF||Health Enterprise Architecture Framework||[website]|
|IADS||IBM Architecture Description Standard||“a set of conventions for notation, terminology and semantics to describe the architecture of an IT system”||IT architecture||
Aspects: functional aspect, operational aspect. [Youngs R, et al. A standard for architecture description. IBM Systems Journal 1999, 38(1)]
|IAF||Index Architecture Framework||methodology|
|ICODE||iCode Security Architecture Framework||an approach to develop security architectures||information security||Viewpoints: Business, Information and Technical [slides]|
|IFW||IBM Information FrameWork (IFW)||“The Information FrameWork is a family of data, process and object models to help financial institutions transform cross-enterprise architectures.”||“Industry-specific to financial services system architectures, in particular banking.”||enterprise architecture||
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]
|IIRA||Industrial Internet Reference Architecture||To provide “guidance for the development of system, solution and application architectures. It provides common and consistent definitions in the system of interest, its decompositions and design patterns, and a common vocabulary with which to discuss the specification of implementations so that options may be compared.”||“Industrial Internet systems [which] cover energy, healthcare, manufacturing, public sector, transportation and related industrial systems.”||safety, security, resilience||Viewpoints: Business, Usage, Functional and Implementation following ISO/IEC/IEEE 42010. [web]|
|4+1||Kruchten’s 4+1 view model||software architecture method||Viewpoints: Logical, Physical, Process, Developer, Scenarios. [doi]|
|LEAD||Leading Enterprise Architecture Development (LEAD)ing Practice||“Empowering organizations to structure a common way of thinking, working and modelling that enables them to innovate, transform and deliver value.”||enterprise modelling and architecture||enterprise architecture||LEAD version 3.0 currently consists of 10 frameworks, 6 methods and 4 approaches that are all integrated with each other and with supporting maps, matrices and models. [website]|
|MACCIS||MACCIS 2.0 – An Architecture Description Framework for Technical Infostructures and their Enterprise Environment (NO)||[pdf]|
|MEGAF||MEGAF||MEGAF is an infrastructure for realizing architecture frameworks.||software, system and enterprise architecture||
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]
|MODAF||(UK) Ministry of Defence Architecture Framework||
Viewpoints: Operational, Systems, Technical, Strategic, Acquisition [website]
|NAF||NATO C3 Systems Architecture Framework||“to provide guidance for developing and describing NATO architectures”||C3 systems interoperability||
Viewpoints: All; Capability; Operational; Service-Oriented; Systems; Technical; and Programme. [website]
|NIST-EAM||NIST Enterprise Architecture Model|
|OIO||OIO Enterprise Architecture Method||enterprise||[website]|
|OSSAF||Open Safety & Security Architecture Framework||"The Open Safety & Security Architecture Framework (OSSAF) aims to provide a simple, open and prescriptive approach to coordinate the perspectives of different types of stakeholders within a PS&S organisation (Strategic, Operational, Functional and Technical)."||Public Safety and Security (PS&S)||views, content and format, method, governance||[Downloads]|
|PEAF||Pragmatic Enterprise Architecture Framework||To provide a minimal EA framework.||“The whole enterprise consisting of the Organisation, the market it operates in and the wider Enterprise.” PEAF is intended to be a “business agnostic, vendor and consultancy independent, technology neutral framework”.||enterprise architecture method||Viewpoints/Model Kinds: Enterprise strategy, Enterprise structural, Portfolio, and Principles. [website]|
|PPOOA||Processes Pipelines in Object Oriented Architectures||Provides a collection of building elements and an architecting process to build component-based architectures, taking into account concurrency issues earlier in the development.||software-intensive, real-time systems||PPOOA is an architecting framework oriented to real-time systems architectures. PPOOA uses two viewpoints: structural, using UML class diagrams extended with PPOOA stereotypes, and behavioral, supported by UML activity diagrams. PPOOA architectures may be evaluated by analytical methods such as RMA (Rate Monotonic Analysis) and simulation tools such as Cheddar tool. An architecting methodology (ise&ppooa) and process is provided also. [website, ISE & PPOOA]|
|PRISM||Partnership for Research in Information Systems Management||Characterize the architectural environment in sponsor organizations, and provide an approach for architectural activity. To describe an overall framework that can be used as a starting point for architecture development.||Information systems architecture||
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]
|QGEA||Queensland Government Enterprise Architecture||“The QGEA is a tailored EA which delivers a comprehensive set of processes, frameworks, policies, guidelines and tools to describe how the Queensland Government organises its resources to support service delivery.”||Queensland Government, Australia||
information management and ICT policy
License: Creative Commons
|“The QGEA Framework provides a means for the Government to define policy, requirements and targets which drive agencies in supporting the Government’s priorities and providing services to help build a strong, green, healthy, smart and fair Queensland.” [website, QGEA documents]|
|RASDS||Reference Architecture for Space Data Systems||Provide a standard description method||data systems to support space missions||
RASDS is intended to provide a standardized approach for description of data system architectures and high-level designs. [pdf]
|RM-ODP||ISO Reference Model for Open Distributed Processing||Open distributed processing systems||
ISO/IEC 10746-1 Information technology — Open Distributed Processing — Reference Model: Overview.
Viewpoints: Enterprise, Information, Computational, Engineering, and Technology. [website]
|RWSSA||Rozanski and Woods||software architecture practitioner handbook||information systems||viewpoint set||
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.
|S4V||Siemens 4 Views||software architecture method||
C. Hofmeister, R. L. Nord, and D. Soni. Applied Software Architecture. Addison-Wesley, 2000
|SABSA||Sherwood Applied Business Security Architecture||“The SABSA framework has evolved as a ‘best practice’ method for delivering cohesive information security solutions to enterprises. SABSA is a six-layer model covering all four parts of the IT lifecycle: Strategy, Design, Implementation and Management & Operations.”||enterprise security architecture||model, method, process and lifecycle||
“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.”[website]
|SASSY||Self-Architecting Software SYstems||Research "to build a framework for Self-Architecting Software Systems".||service oriented software systems||“SASSY includes: 1) Self-architecting: given the service and Quality of Service (QoS) requirements, an optimal architecture is automatically generated with the aid of design patterns. The merit of architectural alternatives is evaluated with the aid of multivariate utility functions. 2) Activity-based specification: behavioral requirements are expressed as activity schemas annotated with QoS requirements and domain ontology. 3) Unification of evolution and adaptation: both the evolution of requirements and changes on monitored run-time conditions and QoS trigger the revaluation of architectural alternatives, and, to the extent possible, the automatic reconfiguration of systems.” [website]|
|SGCAF||Smart Grid Conceptual Architecture Framework||[pdf]|
|SQUID||Specification Quality In DevOps||"Model-based documentation of software architectures and their quality properties in DevOps scenarios with the goal of providing DevOps-ready software architecture descriptions."||DevOps||software architecture||[DOI] [pdf]|
|TEAF||(US) Treasury Enterprise Architecture Framework||Development/Investment Guide||Published in 2000. Now seems to be withdrawn from use.|
|TOGAF||The Open Group Architecture Framework||IT methodology||[website]|
|TRAK||TRAK||TRAK provides a means of describing the architecture of systems, based on the requirements of ISO/IEC/IEEE 42010.||Domain-neutral. General purpose for the description of systems, aimed at systems engineers.||License: available under GNU Free Docmentation License and GNU General Public License.||
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]
|UADF||Universal Architecture Description Framework||
“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]
|xAF||Extensible Architecture Framework||“to develop a generic architecture framework that is theoretically solid and practically useful”||“enterprise engineering (business definition, business system development, organisation development, ICT-applications development, etc.”||
“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]
|ZF||Zachman Framework||“The ‘Zachman Framework’ is a schema, a classification of the total set of descriptive representations that are relevant for describing an Enterprise such that it is ‘normalized’.“||Classification Scheme||[website, interview]|