Enterprise Architecture 

 Frameworks

Framework

                                                                mainpage

                 Business Architecture Information Architecture Systems Architecture Infrastructure Architecture

               Architecture Domains: The 4 levels of Enterprise Architecture

Architecture Framework

An Architecture Framework provides context and structure for the application of enterprise architecting. It provides a reference for design undertakings. Frameworks provide guidance and are not intended to be rigidly adhered to. An architecture framework needs to be customer-focused, and adaptable to a wide range of customer contexts. Organisations may:

  • have their own framework;
  • adopt an industry framework (e.g. government agencies complying with a government model such as the Australian Government Architecture Reference Models or the Queensland Government Enterprise Architecture);
  • adopt an accepted best-practice framework such as TOGAF, apply one that is used by an IT provider; or
  • they may have no formal framework at all.

The application of a framework, such as the illustrated example, provides a bridge between a customer's own architecture framework, its business operations and strategies and the architect and his/her organisation's design capabilities and reference architecture.

Adopting an Architecture Framework will allow Enterprise Architects to:

  • devise designs and articulate their value in customers' business terms; and
  • provide for a consistent, and therefore inherently more efficient approach to all design efforts.

Industry-recognised frameworks such as TOGAF or Zachman are intended to provide guidance for the widest possible reference, and hence need, and acknowledge, that they should be adapted for specific use. It is important to recognise that, while the focus is on the customers and an Enterprise Architect's execution of architecting practice for those customers, 3rd parties frequently play a role in the application of EA - including:

  • Other ICT providers to the customer
  • Customers' customers and suppliers
  • Sub-contractors

Effective enterprise Architecting requires the application of an ICT Governance model that is participative and collaborative between a customer and all of their primary providers of ICT Services.

Business and Operational Context

Enterprise Architecture is all about linking information and communications technology with the business, and exploiting the technologies to achieve business goals and objectives. ICT should not be totally reactive and work in isolation from planning and operational activities. Information Technology is now so pervasive that all roles within any organisation have some appreciation of its value, even if they don't understand how it works, or don't understand the difference between ICT management and architecting. ICT professionals, including architects, should be able to become engaged with the business at all levels.

  • Governance is the assignment of roles, responsibilities, accountabilities and decision rights. Corporate governance is "the system by which companies are directed and controlled". Enterprise Architecture, or at least IT management, should be recognised within those arrangements and should be a participant in the relevant forums. Enterprise Architecture principles should link to enterprise governance and its principles, given that principles are designed to guide decisions, and governance is about decision rights.
  • Standards - including minimum and desired technical standards to be applied, processes and procedures, accreditations and skillsets
  • Policies - an organisation's policies applicable to its deployment and use of ICT
  • Regulation - government, ICT industry and organisation-specific laws and regulations.

A RACI matrix (Responsible / Accountable / Communicated / Informed) is an ideal tool to capture and communicate the respective involvement of all groups and / or individuals. Good practice assigns only one role / person as the Accountability for any one topic.

Architecture Domains

The 4 levels of architecture, as the primary domains of the Taxonomy.

Business Architecture

The Business Architecture defines the Information Architecture by setting out the business strategies, demographics, functions and processes and the information needed to carry out the functions and processes to achive the goals and objectives.

Information Architecture

The Information Architecture influences the Systems Architecture by describing where information is stored, how it is accessed and used, the levels of protection required and the format in which it is required - which shapes Systems types, configurations and features.

Systems Architecture

Systems Architectures determines Infrastructure Architecture by setting out the necessary interconnectivity between systems to allow for the necessary exchange of, and access to information.

Infrastructure Architecture

Infrastructure Architecture is comprised of the detailed physical components (hardware, software, networks, Systems tools, artifacts and human factors) of the environment.


The architectures are described at increasing levels of detail as Arcitecture Descriptions - the Views and Viewpoints.

Architecture Descriptions

Descriptions, products, artifacts, models, views and veiwpoints.

Anyone with a desire to confuse themselves should explore the various uses of these terms in the many EA frameworks. A reasonable interpretation can be found in "Enterprise Engineering Planning, Foundation of Enterprise Architecture: Overview of DAF Products". For the sake of simplicity, the following interpretations are applied here:

  • Architecture Description. As the name implies, the architecture described, individually or collectively, as Views and/or Viewpoints. Architecure Descriptions should include proper version controls and metadata.
  • View A representation of an architecture. Architecture Views may be graphical, tabular, textual or any combination of these.
  • Viewpoint. The perspective taken - for example, an End User will have a different Viewpoint than a CIO or business manager. In other words, an architecture is represented in a View that is appropriate to the audience's Viewpoint.
  • Model. A logical representation of how Views fit together - typically in graphical formats, to illustrate flows and interdependencies. Models should use a consistent modelling language (a whole new world of pain to explore) or style.
  • Product. An output from architecture work - including Descriptions, Views and Viewpoints but can include other related material such as schemas, glossaries, ontologies, taxonomies etc.
  • Artifact. All Products are artifacts. Not all artifacts are products. An artifact can be external to the architecture work but is referenced by the architecture.
  • Catalogue. A collection of like items (Views and Viewpoints should form a catalogue). A catalogue should be a logical, indexed structure that is searchable and where relationships between catalogued items is identifiable.

Architecture Descriptions are set out in accordance with the Architecture Viewpoints.

Architecture Library

An architecture catalogue should reside in the Architecture Library - and may in many cases form the entire Library. The Library can include additional products and artifacts which, like any library should be properly indexed and cross-referenced. An Architecture Library and an Architecture Repository are effectively the same thing in most circumstances. Both can consist of softcopy and/or hard copy contents, and may be physical or virtual entities. The use of different terms may apply when there is a need for both - for example a Library being virtual instances of a physical repository, or where an Architecture Repository is one part of a wider Library.

Architecture Tools

There are useful EA-specific tools available. The Enterprise Architecture Tool Selection Guide from the Institute for Enterprise Architecture Development provides a comprehensive list and assessment guide.

Tools available include:

  • Telelogic DOORS;
  • Eclipse;
  • Protege;
  • Sparx;
  • ArchiMate; and
  • Netmodeler.

Other Reference:

Tools for Requirements Management: a Comparison of Telelogic DOORS and the HiVe
Information Networks Division, Defence Science and Technology Organisation, DSTO-GD-0466.

External Influences on the Architecture

A catch-all for any influence external to, and outside of the control of the organisation. regulation is an external influence, but because it has a direct influence on the conduct of an enterprise it has been included under "Business and Operational Context and Governance" in the Framework.

External influences can affect each of the 4 primary Architecture domains. At a Business Architecture level, external influences can be identified from Business Strategies and their treatment of a competitve marketplace, or for government agencies, the interworking with other agencies and shared architecture frameworks, models, architectures and sourcing policies.

Customers, clients, partners and other players that comprise the extended enterprise can also influence an organisation's architecture across all domains.

Other likely influences include:

  • Emerging technologies;
  • Evolving standards; and
  • Service providers and equipment vendors.

Effective planning for external influences can be applied through the development and application of well constructed Architecture Principles, active involvement of EA in Governance forums and the proper treatment of innovation.


There are hundreds of EA and related Frameworks that are developed for specific purposes, specific IT architecture communities or for general adoption. Many offer value as reference frameworks, and are generally aligned with a organisation/business-down multi-level structure. Links to some other Enterprise Architecture Frameworks are:

  • Zachman. A schema for organising architectural artifacts that takes into account both whom the artifact targets and what particular issue is being addressed
  • TOGAFan industry standard architecture framework that may be used freely by any organisation wishing to develop an information systems architecture for use within that organisation
  • SABSA. Now integrated with TOGSAF, 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
  • DODAF. US Department of Defense Architecture Framework
  • BEA. Business Enterprise Architecture (US Department of Defense). The US Government Business Transformation Agency (BTA) annually releases the Business Enterprise Architecture (BEA) for the Department of Defense Business Mission Area (BMA) to "help defense business system owners and program managers make informed decisions in support of the Department
  • MODAF. UK Ministry of Defence Architecture Framework.
  • TRAK Metamodel - an enterprise architecture framework based on MODAF. TRAK provides a way of describing systems and their place in the world through architectural models
  • Integrated Architecture Framework. Cap Gemini Ernst & Young's IAF breaks down the overall problem into a number of the related aspect areas covering Business, Information, Information Systems and Technology Infrastructure, with two specialist areas addressing the Governance and Security aspects across all of these
  • OMG - CORBA. The Object Management Group's (OMG) Object Management Architecture (OMA), often loosely referred to as the CORBA architecture, is an object-oriented Applications Architecture.
  • NCOIC - NIF. The Network Centric Operations Industry Consortium's (NCOIC) primary mission is to provide enabling guidance to accelerate the introduction of Network Centric Operations (NCO) and advance system interoperability across multiple domains of operation.
  • ISO RM-ODP. RM-ODP uses an object modeling approach to describe distributed systems.
  • SPIRIT. The Service Providers' Integrated Requirements for Information Technology (SPIRIT) Platform Blueprint is a specification that was developed within the TeleManagement Forum. SPIRIT is a joint effort between telecommunication service providers, computer system vendors, and independent software vendors with the goal of producing a common, agreed set of specifications for a general-purpose computing platform
  • EABOK. The Guide to the Enterprise Architecture Body of Knowledge organises and characterises the knowledge content of the Enterprise Architecture discipline.
  • IDEAS. The IDEAS Model is a formal ontology developed to support the exchange and sharing of enterprise architectures. It has been developed by the IDEAS Group, which is a consortium of Australian, Canadian, Swedish, UK and USA Customer ministries. The IDEAS Foundation has been used as the basis for the DoDAF 2.0 Meta-Model (DM2). The main purpose of IDEAS is to support coalition military operations planning. The ability to exchange architectures between countries enables better understanding of each others capabilities, communications mechanisms and standard procedures.
  • BIAN - the Banking Industry Architecture Network envisions an SOA-enabled banking industry with both internal and industry-wide agility and flexibility. BIAN supports banks to define their internal services based on industry collaboration and best practices. When applying TOGAF in a banking environment, the BIAN content speeds up the work by providing banking-specific architecture content.
  • A comprehensive list of hundreds of frameworks compiled by Pragmatic EA .