Extreme Architecture Framework

A Canvas for Agile Enterprise Architecture

In conjunction with Floris Gout

We first presented our ideas about the Extreme Architecture (XAF) at a conference in 2002 [8].  A series of articles and papers followed cumulating with a chapter in the Handbook of Enterprise Systems Architecture in Practice published in February 2007 by Idea Group Inc.

See the bibliography below or for a concise summary of our work.

We have not written much since then but have been busy updating the framework [17] to make it relevant to a world that is in many ways quite different to 2002.  This post describes the latest version of the framework which has slimmed down a bit to become even more minimalist.

At first glance, there is a striking similarity between the XAF and the Zachman frameworks.  Both frameworks are presented as a matrix.  This is not a coincidence; as we were heavily influenced by both the strengths and weaknesses of the Zachman Framework.

However, we have chosen to label the rows and columns of our matrix quite differently.

Rows

The rows of XAF represent systems (business, application and component) while rows in the Zachnman Framework represent roles (planner, owner, designer, builder and sub-contractor).

We believe that there are a number of advantages to basing an architecture framework on systems rather than roles:

• Unlike roles, systems can be more precisely defined by a boundary.
• The allocation of responsibilities to individual systems and the interfaces between them encourages a consideration of interoperability.
• Systems encourage an objective systems engineering approach to architecture while roles are by nature more subjective.
• Systems can be decomposed into components that map better to an object-oriented, component-based, or service-oriented style of architecture.

The diagram below defines the rows of the matrix in greater detail.

Columns

The columns of the XAF represent architectural views (activity, information, software, data and technology) while columns in the Zachman Framework represent the English language, single-word interrogatives (what, how, where, who, when, why).

We believe that there are a number of advantages to basing an architecture framework on views rather than interrogatives:

• The English language provides part of the rationale behind the Zachman Framework. The elegance of the framework for speakers of languages other than English may not seem quite so obvious. For example some languages, such as French have a seventh single-word interrogative (combien) meaning “how much”.
• Views are a widely used architectural mechanism. For example, the IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems defines an architectural view as:

a representation of a whole system from the perspective of a related set of concerns.

• Many enterprise architecture frameworks (including XAF but not the Zachman Framework) have adopted the architectural views (business, information, application, data, and technical) originally described in the NISTreport Information Management Directions: The Integration Challenge.  This means that these views are widely accepted and understood.

The diagram below defines the columns of the matrix in greater detail.

Cells

The rows and columns of the XAF classify just seventeen “architectural elements”.  These seventeen elements are intended to provide a minimalist answer to the questions:

Which elements of the enterprise do I need to be aware of and understand; and Which elements am I responsible for and need to manage?

In other words, the XAF defines a minimalist enterprise architecture framework for governance of the enterprise.  In contrast, the Zachman Framework is strongly influenced by the periodic table of chemical elements.  The columns and rows of the framework provide a classification scheme for no less that thirty separate models of an enterprise.

We believe that there are a number of advantages to basing an architecture framework on a minimalist list of elements rather than models:

• Clearly, attempting to populate all of the Zachman Framework cells with the appropriate models is a gargantuan task for even a modest sized enterprise.  The sheer scale of attempting this is sufficient to derail many enterprise architecture efforts.
• The XAF’s architecture elements offer more concrete guidance on precisely what is required in order to describe an enterprise. At the same time, it does not restrict how individual elements can be combined to create models of an enterprise as required.
• The Zachman Framework is intended to classify a number of independent models of an enterprise without defining the relationship between models in adjacent cells.  In contrast, it is intended that the architecture elements of the XAF have some meaningful relationship with elements in adjacent cells.
• Each of the elements can be directly mapped to standard modeling languages such as Archimate and the UML thus providing the opportunity to standardise enterprise models and employ standard modelling tools.

A detailed definition for each of the architectural elements follows.

Business

• Activities: the activities performed by a business [1]. A unit of work performed as part of an initiative or process [3].
• Constraints: statements that concerns dynamic aspects of the business. They specify constraints on the results that activities can produce [1].
• Information: facts that are computed or inferred from other facts via specified derivations [1].
• Derivations:  algorithms used to compute or infer information [1].
• Fact: associations between two or more terms. [1].
• Feature: a distinguishing characteristic of a software item (for example, performance, portability, or functionality) [2].
• Term: words or phrases used by the business [1].

Application

• Scenarios: a series of actions or tasks that respond to events (scenarios provide a black-box view of applications in contrast to the other application elements which provide a glass-box view) [3].
• Interfaces: shared boundaries between a person and an application or two applications through which operations are invoked and/or messages are sent [3].
• Functions: capabilities, or things an application could do for its users [3].
• Storage: data that must be permanently retained and capable of being retrieved [4].

Component

• Operations: interactions between a person and a component; or between two components, that invokes a service[5].
• Messages : communications between a person or a component; or between two components [6].
• Code: computer instructions and data definitions expressed in a programming language [4].
• Schemas: definition of data characteristics and relationships [4].

Technology

• Platforms - types of computer or hardware devices and/or associated operating systems, or virtual environments, on which software can be installed and/or run [7].
• Services - behaviour, triggered by an interaction, that adds value for the service users by creating, modifying, or consuming information [5].

Definitions have been adapted from the following sources:

[1] Defining Business Rules - What Are They Really?, the Business Rules Group.

[2] IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.

[3] A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 2.0, International Institute of Business Analysis (IIBA).

[4] ISO/IEC/IEEE 24765:2010 Systems and software engineering - Vocabulary.

[5] ISO/IEC 10746-3:2009 Information technology - Open Distributed Processing.

[6] IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject).

[7] ISO/IEC 19770-1:2012 Information technology - Software asset management.

Bibliography

[8] The original conference paper and presentation.

[9] Extreme Architecture: Architecture Components, Phil Robinson and Floris Gout, Oracle Scene, Issue 19, Autumn 2004.

[10] Extreme Architecture - Part 2, Architecture Components, Phil Robinson and Floris Gout, Oracle Scene, Issue 20, Winter 2004.

[11] Extreme Architecture: Part 3, Applying the Framework, Phil Robinson and Floris Gout, Oracle Scene, Issue 22, Summer 2005.

[12] Extreme Architecture: Part 4, The eXtreme Architecture Process: Populating the architecture framework (unpublished).

[13] The eXtreme Architecture Process: Amplifying the UML, Phil Robinson and Floris Gout, Oracle Scene, Issue 24, Winter 2005.

[14] XAF: A Minimalist EA Framework for an Agile Environment, Phil Robinson and Floris Gout, Cutter IT Journal, Vol 19, No 3, March 2006.

[15] Extreme Architecture Framework In a Nutshell. 

[16] Amplifying the UML presentation. 

[17] Extreme Architecture Framework Revisited.

[18] Extreme Architecture Framework: A Minimalist Framework for Modern Times, Phil Robinson and Floris Gout, Handbook of Enterprise Systems Architecture in Practice, February 2007, Chapter 2, (pages 18-38), Idea Group Inc.