Integrated Architecture Framework Version 4.5

Reference Manual

Version 1.0 April 2009


The Capgemini Integrated Architecture Framework (IAF) has been the cornerstone of architecture led engagements across most of Capgemini for many years. To date, IAF is used at many customers, used and developed by the architecture community. As a result, IAF has evolved and adapted over the years through the experience and thought leadership of the Capgemini architecture community. Learning and education has been through formal (A-Week events) and informal (on the job coaching). IAF has undergone major revisions at intervals, with course and reference material updated as resources allowed. This process has ensured that at any one time, there are several ‘flavours’ of IAF in use, each involving slightly different interpretations but still underpinned by a consistent and robust set of concepts.

Recently, Capgemini has identified a need to communicate and share IAF with clients and a wider, public domain community. It is therefore necessary to establish a consistent baseline of definitions that can be used for this dissemination process. It is necessary to present a definitive version and interpretation of IAF Artifacts^1^{#fnref1 .footnoteRef} in order to support this initiative.

Purpose and Scope

This document is the definitive reference for the core architecture Artifacts that comprise the Integrated Architecture Framework. It addresses the architecture content of the IAF only. Other documentation will be provided that describes the processes for using IAF in engagements (Roadmaps, use with TOGAF etc , dealing with different engagement scenarios etc)


The specific definitions and reference information contained in this document relate to IAF V4.5.

Limitations of this version of the manual

This version of the manual does not include a comprehensive example set, this will be addressed later

Integrated Architecture Framework and Concepts

This section deals with the concepts of architecture from the Capgemini perspective, in terms of what architecture is, the role it plays and the basic concepts of the Integrated Architecture Framework.

Defining Architecture

Architecture has become a very popular term and is applied extensively in many different areas of life. The popularisation of the term architecture has diluted and extended it’s original meanings.

WIKIpedia has the following to say on the term architecture:

Architecture (from Latin, architectura and ultimately from Greek, αρχιτεκτων, "a master builder", from αρχι- "chief, leader" and τεκτων, "builder, carpenter")is the art and science of designing buildings and structures.

A wider definition would include within its scope also the design of the total built environment, from the macro level of town planning, urban design, and landscape architecture to the micro level of creating furniture. Architectural design usually must address both feasibility and cost for the builder, as well as function and aesthetics for the user.

Planned architecture often manipulates space, volume, texture, light, shadow, or abstract elements in order to achieve pleasing aesthetics. This distinguishes it from applied science or engineering, which usually concentrate more on the functional and feasibility aspects of the design of constructions or structures.

In the field of building architecture, the skills demanded of an architect range from the more complex, such as for a hospital or a stadium, to the apparently simpler, such as planning residential houses. Many architectural works may be seen also as cultural and political symbols, and/or works of art. The role of the architect, though changing, has been central to the successful (and sometimes less than successful) design and implementation of pleasingly built environments in which people live.

In modern usage, architecture is the art and discipline of creating an actual, or inferring an implied or apparent plan of any complex object or system. The term can be used to connote the implied architecture of abstract things such as music or mathematics, the apparent architecture of natural things, such as geological formations or the structure of biological cells, or explicitly planned architectures of human-made things such as software, computers, enterprises, and databases, in addition to buildings. In every usage, an architecture may be seen as a subjective mapping from a human perspective (that of the user in the case of abstract or physical artifacts) to the elements or components of some kind of structure or system, which preserves the relationships among the elements or components.

An engineering perspective from the IEEE definition of architecture (within a Business and IT context) is:

“The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”

This definition is somewhat static, but applicable although more focused on Solution Architecture than Enterprise Architecture.

Another definition is:

“Architecture shows the relations and interdependencies between the organization with its processes, the information, the IT systems and the infrastructure. Architecture is an effective and consistent set of principles, models and guidelines that give direction and set boundary conditions for programs, projects or systems.”

This definition is more oriented to Enterprise Architecture, but also applicable for Solution Architecture.

All of the definitions have in common a focus on structure and relationships with reference to a set of governing principles that provide guidance and support for direction and decisions.

Architecture the Capgemini Way

Capgemini started developing its architectural approach in 1993, and has steadily evolved its architecture framework, the Integrated Architecture Framework (IAF), to address much more than Technical Architecture or Software/Systems Architecture.

Capgemini views architecture as providing a comprehensive and coherent view across Business, Information, Systems and Technology, not just to design IT systems but to deliver Business Change which may also be supported and enabled by IT.

This holistic view of the business through the use of architecture is becoming even more critical as Service Oriented Architecture and the Service Oriented Enterprise become the way that many organisations think about and organise their business.

A Holistic View

Clients and the industry as a whole are moving towards a standard (but not yet universally defined and agreed) set of terms that describe different types of architecture. These typically encompass terms such as Enterprise Architecture, Solutions Architecture, and even Security or Governance Architectures as well as the more usual Technical, Applications or Business Architectures.

The following diagram illustrates how Capgemini relates these types of architecture to one another, demonstrating the inclusion of Business Architecture within a full Enterprise Architecture, as well as the need for Solution Architecture to span from Business to Technology.

Figure 1 Types of Architecture

It is important to note that each type of architecture will address different levels and types of insight that may span business, information, systems, etc. Within this model Capgemini recognises:

Enterprise Architecture details the structure and relationships of the Enterprise, its business models, the way an organisation will work, and how and in what way Information and IT will support the organisation’s business objectives and goals. Enterprise Architecture provides an all-encompassing, holistic end-to-end view of the business in terms of people, process, governance and technology within (and external to) the business support those objectives and goals.

Enterprise Business Architecture (or Business Architecture) defines the integrated structure of the overall business itself (in terms of organisation, people and process and resources). Business architecture supports business change with a more holistic perspective. This approach is becoming more important with the move towards Service Oriented Architecture at the business level, often termed the Service Oriented Enterprise.

Enterprise IT Architecture defines and describes the structure and relationships of IT systems at the Enterprise level, in terms of the way that IT supports the organisation in achieving its business goals. This typically includes standards and guidelines that are applied within Solution Architectures.

Solution Architecture defines an architecture for a specific solution, whether this be Business or IT or both. The Solution Architecture provides structure, standards and guidance for the detailed design of a solution and is typically guided by the Enterprise Architecture. Note that “Solution Architecture” is often used as shorthand for “Solution IT Architecture” and is sometimes referred to as Project Architecture.

Governance Architecture defines

the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It includes the following:

Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization

Implementing a system to ensure compliance with internal and external standards and regulatory obligations

Establishing processes that support effective management of the above processes within agreed parameters

Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization

Security Architecture defines not only traditional IT security but also addresses business and information security as well as the resulting organisational and business-related services to deliver the required security, often linked to the Governance aspects to cover what is often termed security management.

This holistic view of architecture is directly reflected in Capgemini’s approach, the Integrated Architecture Framework (IAF), with specific “Aspect Areas” that focus on Business, Information, Information Systems, Technology Infrastructure, Security and Governance.

Note that the “Software, Network and Storage Architecture…” shown on the diagram are outside the scope of IAF. Capgemini positions these aspects in the engineering/design focussed methods such as the Rational Unified Process (RUP) for Software Architect and, in Capgemini, the Infrastructure Design Framework (IDF) for Network, Storage, etc. which all form a coherent part of Capgemini’s Quality System “DELIVER”.

The Architecture Lifecycle

Capgemini believes architecture must deliver real value in terms of improved project success and increased Business/IT Alignment. This is often delivered solely through strong governance over the delivery of solutions.

Figure 2 shows how architecture bridges the gap between Business/IT Strategy and solution development. Aligning solution architectures to an overall Enterprise Architecture provides the “missing link” in the governance chain from strategy to implementation.

Figure 2 Architecture Influence and Governance

It is equally important to understand that architecture is seen as an ongoing process and not just a “one-shot” event. This is necessary to ensure that the architecture continues to deliver value by:

staying aligned with business needs and priorities, including changes resulting from external factors e.g. regulatory change; leveraging technology change where relevant, managing costs and facilitating business change; and incorporating lessons learned through the implementation and realisation of projects.

Integrated Architecture Framework

The Integrated Architecture Framework is used to structure the architecture information content. The framework comprises a number of inter-related areas. These areas are either vertical aspects which focus the content into common areas of interest e.g. business or security. Or they are abstraction levels that allow the complexity of architecture to be analysed and represented.

Figure 4 Integrated Architecture Framework

The Integrated Architecture Framework:

Provides a repository model for the content of the architecture elements,

Describes the format and content of the constituent elements of the architecture, and

Specifies the way in which these elements relate to each other.

Aspect Areas

The Aspect Areas in the IAF describe a formal boundary between elements of the architecture solution that are usually considered within their own context. Each aspect area focuses on one particular dimension of the architecture, and adds information to the overall architecture.

Figure 5 Integrated Architecture Framework Aspect Areas

The IAF comprises six Aspect Areas, four of these areas focus exclusively on core aspects of architecture i.e. Business, Information, Information Systems and Technology Infrastructure. Each Aspect Area comprises a set of artifacts that describe the architecture in that aspect area.

The IAF also explicitly recognises two additional Aspect areas, covering the two disciplines of Governance and Security. Security and Governance Aspects are common across all the other Aspect Areas and represent a set of requirements that are driven across all core aspect areas, and may significantly change the architecture structure across one or more core aspect areas.

Use artifacts from the relevant core Aspect Areas to describe the governance and security architecture elements.

The Business Aspect Area describes the business architecture in terms of business sub aspects representing business goals, business activities, roles and resources. The outcome of the Business Aspect Area is typically a series of business architecture components that describe process, organization, people and resources.

The Information Aspect Area describes the information the business uses, the information structure and relationships. The outcome from the Information Aspect Area is typically information (not data model!) architecture and a series of business information components that describe what and how information is used and flows around the business.

The Information System Aspect Area describes the information systems (packaged or bespoke) that will automate and support the processing of the information used by the business. The outcome from the Information System Aspect Area is typically a series of Information System architecture components that describe how the information systems will be used to support the automated aspects of the information architecture and business information architecture components.

The Technology Infrastructure Aspect Area describes the technology infrastructure need to support the automated business information architecture components and information systems architecture components.

The Governance Aspect Area adds knowledge to the core aspect areas in terms of quality and manageability of the core architecture components. The outcome of the Governance Aspect Area is typically a set of refinements to the core architecture components and the addition of further architecture artifacts to specifically support the governance objectives.

The Security Aspect Area adds knowledge to the core aspect areas in terms of risk and integrity of the core architecture components. The outcome of the Security Aspect Area is typically a set of refinements to the core architecture components and the addition of further architecture artifacts to specifically support security objectives.

Abstraction Levels

IAF defines three levels of abstraction (of the architecture) and an initial level which provides for the single overall input context and rationale for the architecture. The abstraction levels provide a framework for thinking and analysing the Business Objectives. Considering the Business Objectives at these different levels of abstraction provides a way of ensuring that the whole Scope is addressed at a consistent level before attempting to add further definition and detail. This is the way that IAF deals with complexity and completeness. Applying this across all the Aspect Areas (within the Scope) at the same time ensures a consistent level of granularity across the architecture.

The abstraction levels allow all relevant issues to be identified and resolved before elaboration of the architecture is developed. This does not mean that the Abstraction Levels should be interpreted as series of process steps to be followed one after the other but as a mechanism to support the categorisation of the artifacts and how they should be interpreted. In practice the boundaries between the Abstraction Levels is not always rigid and refinement between abstractions levels is normal and appropriate.

Figure 6 IAF Abstraction Levels

Contextual Level

The Contextual level is about understanding the question “WHY there is a need for a new architecture and the context of the architecture. In the IAF the Contextual Level is about understanding WHY the architecture is required, why the boundaries are set for the new architecture, the current business and technology contexts (including the eco-system that the organisation relates to), understanding who the key stakeholders are, the business objectives, success criteria, in short a set of information that will provide the context for the architecture development. These are referred to in IAF as Support Products.

This is achieved through characterising and obtaining an understanding of all those parameters that will define the boundaries and constraints for the new architecture.

The key architecture content related outcomes of the Contextual Level are the Scope and Business Objectives, Assumptions and Constraints, and the Principles.

Conceptual Level

The Conceptual Abstraction Level is characterised by the “WHAT?” statement. It is about answering the question “WHAT is needed to realise the business objectives”? At the Conceptual Level, the requirements and objectives are decomposed, ensuring that all aspects of the scope are explored, that issues are identified and that these issues are resolved without concern over how the architecture will be realised.

The Conceptual Level outcomes are representations of the requirements in architectural terms of descriptions of “elements of behaviour” and their inter-relationships. This approach is common across all the Aspect Areas.

Logical Level

The Logical Level is characterised by the “HOW” statement. It answers the question “HOW can the architecture be structured and organised in an optimal fashion to achieve the stated objectives”. The Logical Level is about setting the desired architecture state and structure in an implementation independent manner. The desired state for the architecture may be a short term view or it may be a long term view.

Several “Solution Alternatives” are typically developed that reflect different or conflicting constraints, priorities, principles or business objectives for the architecture. For example a low cost alternative may be considered against a high performance one. These different alternatives may only affect portions of the architecture or they may have ramifications across all the architecture.

The outcome of the Logical Abstraction Level is an agreed “desired state to be achieved” representation of the architecture that is implementation dependent. This typically is a compromise between different “Solution Alternatives”. The Logical Abstraction Level therefore is the level where major decisions are made. This is where IAF can be used as decision support for optimal solutions, looking for the impact of change or even identifying opportunities simply by looking at different alternatives. This is where for example IAF could have a strong role to play as a tool for an organisation’s enterprise architecture function.

Physical Level

The Physical Level is characterised by the “WITH WHAT” statement. It is about determining the real world structure and is concerned with transforming the Logical Level outcomes into an implementation-specific structure. The physical representation of the architecture will for example allocate where the desired state will be implemented (this may be either in new implementations, existing implementations or a combination of both). For a business outcome it may indicate where existing organisational structure is retained and where changes are made, where new or changes to existing process is needed or even where existing processes are re-used. Another example is where information is stored this is often a combination of existing and new information stores.

The outcome of the Physical Abstraction Level is the implementation dependent architecture described by standards, specifications and guidelines that will be used to support the detailed design, configuration and implementation of a real solution.

When considering specifications and standards it is important to remember that the architecture does not describe the detailed functional behaviour of a solution, so decisions based on architectural fit alone should be resisted or accompanied by associated selection and evaluation activities for functional/user criteria.

Framework Intra-relationships - Traceability, Alignment and Dependencies

A key feature of the IAF is the way that the different abstraction layers and aspect areas are inter-related through the content artifacts.


Traceability in IAF is specifically concerned with ensuring that the architectural decisions are founded in the objectives and needs of the business. Traceability is supported by three key mechanisms in the architecture, the most important of these are the principles which reflect the business needs and objectives, the second are the scope and Business Objectives which set out what the architecture outcome should be , and finally the IAF cross references that relate the requirements between the different conceptual aspect areas.


Alignment in the IAF is concerned with ensuring that the structures in the Logical Aspect Areas are consistent. In simple terms there is only one architecture, each Aspect Area reflects a particular focus or view on that one architecture. If these structures are not aligned then the architecture is not aligned to the overall business needs. This alignment is manifested in the iterative nature of IAF and the creation of consistent views across logical Aspect Areas.


Dependencies are the result of constraints on the architecture, if there were no constraints then the physical abstraction would be fully aligned with the logical model! Dependencies result in physical solution alternatives and inevitable iteration across physical Aspect Areas.

A good example of this is to consider the following:

A bank wants to achieve a business objective of having a single view of it’s customer to minimise administration and maximise cross selling.

It decides that it will restructure its business activities and organisation to support this.

From an information focus it makes sense to consider a Logical Information Component that supports the single view of customer.

From an IS focus this means that there should be one or more IS components using this Logical Information Component.

The architecture decisions are traceable to the principles and key business objectives. Unfortunately the realisation of this may have physical constraints, e.g. the bank cannot afford or does not have the capability to re-structure immediately, customer information is held in lots of different places so a choice has to be made about master and slave, this means that the physical IS/TI architecture will need to be different.

In all of these the dependencies may result in a series of migration steps for which there may be a need to iterate the physical alternatives (the ultimate desired or logical state does not change but the steps to get to it need to be developed and therefore one may need to develop an additional series of logical migration alternatives to support the physical alternatives!

Framework Granularity

As indicated the IAF is designed to support different scenarios. One of the key features of IAF is the ability to use the same framework artifacts to describe different levels of detail. For example a “service” can be described at a very granular level for example an IS service might be described at the level of an exposed web service application or a whole system. Similarly a Business Service might actually encompass “provide IT services” or might describe a specific process step in a single business domain.

This allows the IAF to represent architecture at different levels of granularity using the same artifacts and thus can represent architecture at Enterprise, Programme or solution levels of granularity. In any particular scenario the architecture artifacts would all be at the same level of granularity for those aspects deemed to be in the Scope. Different levels of granularity however might be used when dealing with relationships between internal and external services for example so that the relationships are clearly represented. This could apply to eco-system relationships for example.

Framework Iteration

The IAF has been designed to support iteration and refinement of the artifacts. This has been done by minimising dependencies between different Aspect Areas and between different Abstraction Levels. The artifacts are relatively simple in structure. They do not need to be fully defined in order to be used as input for other Aspect Areas. Similarly flexibility in granularity means that high level passes can be undertaken quite quickly and allow Aspect Areas to be started and developed in parallel. The simple structure of the artifacts means that additional information can be added later without necessarily causing major ripples.

The IAF supports iteration and refinement both between Aspect Areas and Abstraction Levels, in fact without it there is little probability of achieving an optimal and aligned architecture. The IAF structure should not be considered as some sort of planning or process structure. The partitions in the framework are there to help the architect understand the context of the analysis and derivation of the architecture artifacts not to indicate a sequence of activities or outcomes.

Glossary and Synonyms Dictionary

The major pitfall in architecture engagements is misunderstanding due to wording. Therefore, the use of a glossary is mandatory. A glossary contains a list of the words used with for each word a definition (a sentence with a subject, a verb and a complement).

A difficulty in using a framework is the wording to name the building blocks. Terminology that already is used in the organisation is often not the same as the framework terminology. The use of a synonyms dictionary clears this up.


Term Synonym Definition

Business Goal Capability Business Activity Function


IAF 4.5 exists of 6 parts, namely:

The Integrated Architecture Content Framework (IACF)

The Catalogue of Views

The Catalogue of Cross-references

The Catalogue of Roadmaps

The Catalogue of Documentation

The Catalogue of Alignment

The IACF is described in detail in the following chapters.

The catalogue of views contains all views with their definition, objectives, common content and is described in this reference manual.

The catalogue of cross-references contains all X-ref that must be used in IAF for traceability and X-check purposes.

The catalogue of roadmaps contains some generic roadmaps (business or IT related) that are commonly used on engagements.

The catalogue of documentation contains all the documentation associated with IAF. Each catalogue entry is a stand alone document in its own part (catalogues are part of the documentation itself). Examples of documentation :

Principle catalogue

Reference Manual

Repository of experiences and best practices

Catalogue of IAF framework extensions

Guide to build a Roadmap

Guide to build a view

Architecture Maturity Model approach

The catalogue of alignment contains documents that describe IAF alignment with other frameworks . Examples are COBIT, MDA, TOGAF, SEMBA, IDF, Technovision, RUP touch points, Zachmann.

Integrated Architecture Content Framework

IAF describes the architecture using two basic constructs:

Artifacts that fundamentally describe the architectural elements.

Artifacts belong to (and are derived within) specific Aspect Areas or Abstraction Levels within the IAF.

Typically artifacts are similar across all Aspect areas within a specific Abstraction level, for example “service” artifacts occur in all Aspect Areas at the Conceptual Abstraction Level, “Component” artifacts occur in all Aspect Areas but also in both Logical and Physical Abstraction Layers.

Views are used for:

Analysing and presenting the architecture from different perspectives;

Representing relationships between artifacts;

Documenting the relationships between artifacts.

Views therefore show the structure of the architecture and provide both traceability for, and the justification of decisions that have been made in the development of the architecture.

Architecture Artifacts within IAF

Artifacts are the core elements of the IAF and fundamentally describe the architecture.

There are a number of core types of artifact within IAF that are essentially the same across any of the aspect areas in which they reside. This section describes these core artifacts and where they are derived within the IAF.


Set out the general characteristics of the desired architecture and WHY it should be as it is. Principles are initially represented at the start of an architecture engagement; however they are often expanded and enumerated throughout the architecture process as the architecture detail is expanded, or as a result of better understanding of the business objectives.


The fundamental building blocks of the architecture. A service describes an “element of behaviour” or function needed in the architecture. The description of a service describes WHAT it does, rather than how it is done. Services are derived at the Conceptual level in the IAF.


Describe HOW services should be organised in accordance with the Principles and business objectives, and are derived at the logical abstraction level and refined at the physical abstraction level of the IAF.


Describe the interaction behaviour between services (and the inference components). Derived at all abstraction levels of the IAF.


Describe standards that will apply to the realisation of the architecture during detailed design, building, configuration and implementation phases of a solution lifecycle (for all aspect areas).


Provide guidance and direction (requirements) for the realisation of the architecture during design, building, configuration and implementation phases of a solution lifecycle (for all aspect areas).


Describes how specific architecture components should be built, configured and implemented (for all aspect areas).

Standards, Guidelines and Specifications are part of the physical level of the architecture and support the physical components and interactions. They provide key supporting input for realising the architecture during detailed system design, build, and configuration and implementation phases of a solution lifecycle.

Other Artifacts

Some Aspect Areas have additional Artifacts that describe specific elements for that Aspect Area.

These Artifacts are used to describe specific constructs that ensure the architecture is appropriately described and connected.

Business Goal (Business Conceptual Abstraction Level)

Business Goals describe the outcomes needed by the business to achieve its business mission and business objectives.

Business Activity (Business Conceptual Abstraction Level)

Describes WHAT business activities are needed to realise the Business Goals.

Role (Business Conceptual Abstraction Level)

Describes the role needed to carry out the business activity.

Business Object (Business Conceptual Abstraction Level)

Describes a resource used by the business

Actor (Business Logical Abstraction Level)

A component that represents one or more roles

Information Object (Information Conceptual Abstraction Level))

Describes the information (typically in terms of information areas) used by the business services.

Object Contract (Business and Information Conceptual Abstraction level)

Describes how a service uses an object

Artifact Definition


All IAF Artifacts are described in this manual using a common structure.

Definition A formal definition of the artifact type.

Description A description of the artifact type, its purpose and derivation. Artifact Attributes This is the artifact template. Artifact Attributes are the template for describing real artifacts. Artifacts are DEFINED USING a set of attributes that are common to all artifacts and a set of specific attributes for that artifact. The common attributes are mentioned in the next paragraph, the specific attributes per artifact. Relationships and Context Describes where the artifact type is positioned in the IAF and its key relationships to other artifacts. Hints and Tips Some practical guidance and issues with deriving the artifact content. This is principally to support the context of the artifact rather than provide a prescription for creation. Example One or more examples of the artifact type.

Common Artifact Attributes

All artifacts include a subset of common attributes irrespective of where they are positioned in the IAF. These comprise the attributes that would suffice to identify every artifact in the architecture.

Artifact_ID A unique identifier within the architecture information for cross reference, clarity and differentiation from other, similar artifacts.

Title A suitable (and preferably unique) short form name for the artifact. Subject The subject represents the concepts of the artifact. This clarifies the functionality of the artifact, answering the WHAT-question. Rationale Describes the reason and foundation of the existence of this artifact. Source The source of this artifact or later artifacts (which may be a person or a reference document) along with a date to support traceability of the architecture. Owner The owner of the artifact is the name (person or group) who validates the details of this artifact. In order to ensure ownership of the architecture, this owner should be a client architecture team member. Author Name of the author of the current version. IAF Location The IAF cell in which the artifact can be placed

Specific Artifact Attributes

The common attributes would perhaps be sufficient to describe a very high level architecture; however most scopes and objectives will require additional attributes specific to the artifact type. For example Service artifacts (e.g. TI Service) have additional Specific Artifact Attributes for example that might include inputs, outputs and metrics.

The specific attributes for artifacts are fundamentally optional and extensible. In other words IAF Specific Artifact Attributes can be extended as required to record any aspect of the artifact to be described. This flexibility makes it very easy to tailor the IAF for different Business Objectives. In general the more granular the architecture scope the more attributes will be detailed and required.

Attributes are not bounded in terms of style, format or content. This free-form structure maximises the information captured and again supports the different scenarios that IAF can be applied to. Attributes should be used and defined where this adds additional value and information to the architecture definition.

Having said that it is perfectly acceptable to extend the number of Specific Artifact Attributes either with additional attribute fields or develop them into a more prescriptive structure. This flexibility allows IAF to take advantage of the existing market of diverse toolsets and data repositories to create metamodels, generate graphics, implement change control or automate linkage and tracking information.

The attributes described in this manual reflect the most commonly used attributes that describe an artifact.

Contextual Artifacts

In IAF, the abstraction level referred to as Contextual contains a number of information sets referred to as the Support Products. These Support Product information sets serve two functions.

First, they identify information that supports the IAF engagement process. Architecture definition can be a complex process, and the Contextual Level provides visibility of this complexity by identifying sets of information to support and facilitate the architecture process. These information sets support, rather than being explicitly part of, the desired architecture state. They may or may not exist or be required for any particular engagement and are not always available prior to or at the start of an IAF type engagement. The requirement for this information set has to be evaluated for each architecture engagement, with one important consideration being the viability and cost/time of creating or sourcing it.

Examples of Support Products are:

Stakeholder Overview

External Information

Internal Information


Competitor Analysis

SWOT Analysis

Business Case

Organisation Model

Culture Analysis


Business Context – (current state information about the business)

Technology Context – (current state information about the IT in use)



Appendix A describes these in more detail.

The second function of the Contextual Level is to present information that drives the architecture definition, and allows key architectural decisions to be made in direct response to business requirements. Consequently they are classed as part of the architecture and described as Artifacts .

The following information is categorised as Artifacts:


Business Mission


Business Objectives



Contextual Artifacts are input artifacts, which describe the key parameters used to structure, define and decide what the architecture will look like. While in principle lack of the input Artifacts will preclude the development of the architecture, in reality they are often elusive in nature and usually require discussions and workshops with the stakeholders of the architecture to agree and formalise their content.

These inputs should not be confused with the Support Products described earlier that provide background and context for the architecture.

Business Mission


The business mission describes the rationale for existence of a business.


The business mission is usually set as a challenge for a business, which provides a goal and is meant to generate inspiration and aspiration within the organisation.

A mission statement is usually short and pithy, and is primarily a statement of direction and goal for the overall business, although they often exist as motivational statements within individual business domains.

The mission is designed to set a strategic goal and communicate the ethos of the business to both internal staff and external partners. Mission statements tend to be static, often being re-issued to support programmes of major change. For the architecture they provide a strategic goal and a means to validate many of the Business Objectives.

Specific Artifact Attributes

Business Mission statement The business mission describes the rationale for existence of a business and outlines the challenge facing the organisation in achieving its goals in terms of: culture, market position, capabilities and growth. The mission reflects the desired goals of the entire organisation, its behaviour and what is important. It is intended to generate inspiration and aspiration within the organization.

Hints & Tips

Business missions should be a fairly short and concise statement, but if poorly defined can run to the length of a novelette. In the latter circumstances, the mission usually includes a lot of the business objectives as well and it could be indicative of organisational difficulties and a lack of business focus (i.e. “trying to be all things to all men“).

Finding the prime business mission statement can sometimes be difficult especially in old, well established businesses. In this case, if the architecture work is being undertaken as part of a new change programme there may well be a mission statement attached to that.

Missions can often be found on company websites as well as their annual accounts and marketing literature, but ensure that you validate these, as they may be results of marketing hyperbole rather than executive direction. Missions should be well publicised within the organisation, and a properly focused business mission should pay attention to the company resources (like staff) and business continuation (for its shareholders). A bad mission statement is one that is exploitative or would put customers off - mission statements are supposed to be aspirational and insprirational.

Be prepared to spend some time linking business objectives back to the mission statement (i.e. understanding the rationale for the business objective) as it relates to mission. If you find that the business mission is largely unconnected to the potential scope of the architecture consider persuading the relevant business domains to create/ adopt a more relavant one.


“Our company will be the market leader in quality fishing products for the hobby market. Our success is based on people enjoying fishing.”

From this it is possible for example to extrapolate business objectives and principles for quality, competiveness, and brand recognition.



A statement that defines an objective (or constraint) that is used to determine the organisation and structure of an architecture.


A Principle is a statement of belief, approach or intent which directs the formulation of the architecture. It does not have to explicitly reference architecture artifacts or structure. In this way many “Business Principles” will often be expressed within the architecture. Principles may refer to the current state or to a desired future state.

Principles will usually address more than one IAF aspect areas.

Principles will have an implicit hierarchical structure where an Principle may generate a number of consequential Principles, some of which may be within other aspect areas.

Principles are owned and validated by the architecture or business owner or owners.

Principles are the starting point for any architecture development. Without Principles it will be difficult to organise and structure the architecture and manage the inevitable conflicting requirements.

Principles are guidelines for the development of the architecture, as they underpin analysis and investigation of architecture options, and provide a structured set of justifications for the decisions that were made about the components in the architecture.

Principles ensure that the architecture is defined consistently and in line with the business objectives.

The Principles are typically derived from Business mission / Strategy / objectives and any corresponding assumptions, scope, constraints and objectives.

Additional inputs can be found in current state, business programme information, business and technical strategies, and business consulting studies, interviews, workshops, discussions, etc.

Specific Artifact Attributes

Classification Describe the classification of the principle according to need and scope of architecture. <Business/ Transformation/ Architectural/ Information Design Decision>

Definition This section is concerned with a more specific statement. This is the actual core of the principle, which enables formal assessment and enforcement. It involves a precise definition of terms and relationships used in the principle's definition, a precise formulation of the intended rule, as well as the identification of the way in which the principle will be assessed. Motivation Rationale for existence of this principle Area Of Impact Principles can be classified based in terms of the area of impact which the underlying rules and assessments may have. Describe here the area of impact of this principle. Implications Consequences of adopting the principle (this provides a source of additional requirements, principles and design guidelines). Note that the implications may be wide ranging and not just limited to the Scope. Describe the implication of carrying out this principle, both for the business and IT aspects. Describe in terms of resources, costs, and activities/tasks. Priority Describe the relative priority of this principle. Numerical format where 1 is highest priority <1/ 2/ 3> Assurance How conformance to this principle will be measured Validity Indication of durability of the principle e.g. strategic, tactical, aspirational

Hints & Tips

A good quality Principle clearly communicates a durable idea.

Good Principles are characterised by 1 or 2 clear sentences, statements worded as an action (object WILL action),

They should:

be relevant to the scope of the architecture

be durable

be clearly linked to business objectives (use the Business Goals as part of the motivation statements), and

have clear, documented implications.

Consideration of assurance measures will often identify additional requirements for the architecture .

They should not:

be too low level for the scope

be poorly disguised design guidelines

contain general statements

use statements that no one would ever dispute, particulary around things like finance (“the architecture will reduce costs” - the concern is how that will be measured and against what baseline, which is not for an Principle to describe)

Whilst Principles are “owned” by the client, they often find it hard to derive their own set of Principles. In this case, it can be useful to put up ‘straw model’ Principles for validation that highlight known dilemmas within their type of organisation or sector, especially those that cut across the different business domains and functions. Another useful technique is to let one party make a draft set before entering a workshop with all parties involved.

While investigating the items which impact the architecture, do not spend too much time in philosophical discussions on whether an item is a constraint, objective, principle or assumption. Use the Principle template for listing them and undertake discussions with the relevant stakeholders to clarify their status. Principles that emerge in this way are often thought (mistakenly) to be common knowledge (‘I thought everyone knew that….’) and so need to be publicised as soon as possible.

At the highest level Principles can reflect the Business Goals and this probably requires no more than 12 Principle Statements. Working the implications will readily allow lower level Principles for different aspects to emerge in a simple hierarchical way.

Note that classification is an attribute of Principle i.e. Principle is not an attribute of classification. Do not set out to create different classes of Principles, i.e. “lets develop the data Principles” as this may miss important cross aspect Principles.


Business Objectives


A goal that an organization sets for itself, for example, profitability, sales growth, or return on investment.


Business objectives typically identify the planned outcomes to an enterprise’s business drivers, based on taking advantage of opportunities and mitigating threats.

Business Obectives describe what the organisation wants to achieve typically within specified timeframes. Business Objectives are not necessarily totally financial but may include organisational aspects, changes to their image or market etc.

Business objectives communicate what the organisation wants to achieve and set parameters and goals for all initiatives within the organisation. They should be aligned with the overall Business Mission to ensure the basis for continued business and measurement of planned change.

Business objectives will usually be found in various sources if not explicitly available for example in strategy papers, business cases, Charters for Change and the like.

Business Objectives are closely associated with Business Mission, Business Goals and are often a basis for deriving Business Activities and Business Services.\ Business Objectives can sometimes be very qualitative in nature and may need to elaboration to emphasise any quantitative aspects. with relevant stakeholders or alternatively they can be expressed as Principles.

Business Objectives usually have a clearly defined owner (especially if linked to a specific business initiative) so the stakeholder analysis input will often identify where these reside.

Ideally Business Objectives should have clear goals, be measurable and be achievable. The scope of the engagement will be closely aligned to the Business Objectives and demonstrate how the architecture supports the goals and measures.

Different types of business issues require different types of architecture and architecture engagements. Architecture may be used to support major strategic change and planning, or as a validation and specification exercise as a precursor to a “build” programme. The former are generally categorised as “Enterprise” while the latter is categorised as “Project”. The primary difference between the two is in the level of detail and aspect area focus. “Enterprise” architectures tend to focus on the Business and Information aspects with a top slice across the other aspect areas whereas “Project architectures focus on the IS and TI aspect areas (with an implicit assumption that the Business and Information aspects are defined). Similarly an enterprise architecture that is created as part of a business case for major change provides just enough detail and structure to estimate costs. One that is created to define which systems will be used after a merger focuses on the current and desired structure together with life cycle management aspects of those systems and will require more detail and analysis.

The Business Objectives relevant for the engagement set out the outcomes of the architecture. The Business Objectives communicate the issues that the architecture will address and the way that the architecture will address them.

The Business Objectives shape the roadmap for the architecture engagement. The Business Objectives allow the appropriate deliverables for an individual architecture engagement to be determined, and the level of analysis required to achieve a satisfactory level of confidence in the outcomes.

Specific Artifact Attributes

Business Objective description Describes the architecture outcomes based on the business issue(s) the architecture needs to address.

Parent Business Objective The reference-id of the parent Business Objective; an Business Objective at higher level that is supported by this Business Objective.

Hints and Tips

Architecture is used for many different purposes and the term architecture has many interpretations so for example a business interpretation of architecture is often different to a technology interpretation Consequently it is important to understand exactly what the architecture purpose and scope are and to ensure that this is agreed and understood and common expectations for the Business Objectives set.

For example

From the business point of view the issues may be portrayed as:

Major business change programmes

Systems that will no longer support the business

Business developments that ask for systems innovation

‘Time to market’ problems

From a technology point of view the issues may be portrayed as

Business does not define requirements clearly

Lack of insight in current systems

The sponsor needs a new system

Maintenance problems

Problems with system operations or systems management

Technological developments that ask for systems innovation

Diminishing costs, complexity and risks of system development projects

Wanting systems that work and co-operate well.

There will often be both these perspectives sometimes in conflict and it should be remembered that many objectives will not be achieved by an IT solution alone, but require a series of related changes to the business architecture possibly including organisational, cultural, and communications, system governance, rationalisation, restructuring and standardisation.

The Business Objectives must separate these different issues and show how the architecture will or will not address them.

It is important therefore to ensure that the Business Objectives are validated by all the relevant stakeholders.

A good Business Objective would be:

“Improve Decision Making by providing better management information through a company-wide portal encompassing branch requirements.”

This architecture will define the architectural requirements for a company-wide portal encompassing the branch requirements. It will provide the management with information to improve decision making.

This makes it clear what the architecture will address and what the outcomes will be and what issues are being addressed.

On the other hand :

“This architecture will provide a solution to the interfacing problem”

This is vague, the issue is unclear (where is the interfacing problem, business or technology?) and does not show who in the business will benefit. (in reality this is a design/support project objective not an Business Objective)


Hierarchy of Objectives


A hierarchy of objectives is built by decomposing each objective/constraint in a set of goals.


The hierarchy of Objectives describes the decomposition of Business Objectives in sets of goals. The starting point of the hierarchy is the Business Mission of the company (or the addressed Business Domain). Adding values to each goal gives the added value of a business objective. Input for the hierarchy could be a Business Case.

Specific Artifact Attributes

Description The description of the specific business objective

Parent objective The reference-id of the parent objective: an objective at higher level that is supported by this business objective




Describes the boundaries of the architecture to be developed


Scope should be defined to ensure complete coverage of the relevant business issues. The Scope determines the level of granularity and detail for each of the aspect areas to be covered and ensures that the appropriate expectations are set for stakeholder agreement.

Controls the architecture engagement and ensures that all architecture activity is focussed on the correct business issues.

Specific Artifact Attributes

Description of topics in Scope Definition of what is in scope, e.g. organisational, architectural, time.

Description of topics Out of Scope Definition of what is explicitly out of scope.

Hints and Tips

Scope and Business Objectives are probably the most important documents for an architecture enagagement.

Stakeholders in the architecture will have different agenda’s and objectives for the architecture. There should be common agreement across all significant stakeholders for the scope.

It is important to allow appropriate time to develop the scope, either right up front or more commonly now during a “discovery” phase. Alignment with the Architetcture Objectives is very important and these should be developed in tandem. See Hints and Tips on Architetcure Objectives.

During an engagement be alert to potential scope changes, and where necessary track, adapt and communicate the scope as other information becomes available. Where the architecture is being developed to support a number of subsequent projects, it is important that control of the scope is maintained and suitable architecture governance processes are in place to do this.




An Constraint is an assertion of a fact which applies to the architecture and is recognised as having a fundamental impact on the architecture.


Constraints are inevitable when dealing with complex issues and the impact they have can have serious consequences when developing architecture.

Constraints may arise from internal or external sources and may be related to business, existing suppliers, technology or even finance. Technology selection is a common constraint e.g. a stipulation that deployment must use a particular manufacturer’s technology.

It is unusual to uncover additional constraints (as opposed to risks and assumptions for example) during an architecture engagement so constraints are usually identified at the outset.

Constraints usually have a lifespan which may be greater or lesser than the architecture lifespan. This is important information as it potentially affects the options available to the architect.

The purpose of identifying constraints is to be aware of potential issues in the development (and realisation) of an architecture. Constraints will have impact on the way the architecture is organised and validated. Constraints may limit architectural options, make an “ideal” logical architecture unrealisable or simply introduce challenges which cannot be overcome.

Specific Artifact Attributes

Constraint A constraint is a basic rule or statement that MUST be followed to ensure that the organizational and IT strategy/aspirations and the architectural objectives can be met. Describe the constraint here.

Priority Describe the relative priority of this constraint. Impacts Describe the impacts of this constraint.

Hints and Tips

Constraints are closely related to requirements and principles but the key here is that they are the immovable issues. Real constraints will have the following characteristics:

Impose real boundaries on what is possible (for better or worse).

May not be explicit and may arise (or be recognised) dynamically and transiently, rather than as an organic part of analysis.

May be buried in requirements (usually expressed as solutions rather than requirements)

May have little rationale for their existence (religious adherence)

During initial analysis/discovery do not however spend too much time in philosophical discussions on whether something is a constraint, objective, principle or assumption. Use the same template for listing them and resolve in discussion with the relevant stakeholders later

Constraints are not in themselves always a negative factor, constraints may have positive outcomes because they may simplify the architecture process by removing the need to evaluate all possible options.

Constraints will impact the architecture development in different ways for example a complete refresh of an organisation’s technology with a single monolithic solution is unlikely to need a major derivation activity within the IS and TI aspect areas especially at the physical layer but comparision between the B&I objectives and the constrained solution may be worthwhile to ensure alignment. (not to be confused with a functional analysis).

A constraint that introduces a part refresh/replacement will need to focus on how legacy services and information are integrated thereby requiring more effort in determining the integration views across new and legacy services.

Challenging constraints through the rationale for their existence may provide opportunities to remove them altogether.




An Assumption is an unvalidated assertion that something is true, but if later validated as false would introduce an impact on the architecture.


Assumptions must be reasonable, i.e. they will normally have a high probability of being true.

Assumptions must have general agreement with the relevant stakeholders

Assumptions must have an owner who will be responsible for validating the assumption. Assumptions have a lifecycle which must be defined in terms of risk, resolution and timeframe

Assumptions are a means to allow activities to continue even though validated information is not available.

The number of outstanding assumptions are a measure of the risk to the successful completion of an architecture.

Specific Artifact Attributes

Assumption* An assumption is an unvalidated assertion that something is true, but if later validated as false would introduce an impact on the architecture. Describe here the constraint.

Priority* Describe here the relative priority of this assumption. Consequences* Describe here the consequences of this assumption.

Hints and Tips

Assumptions are rarely explicit and form part of the “everyone knows that” culture. They are therefore often implicit and only arise when decisions are about to be made.

Assumptions should only be made when absolutely necessary and an owner must always be identified. Validation of assumptions should be a priority.

Assumptions should be phrased as likely to be true. A probability of greater than 60% is a reasonable measure for an assumption to be true

If the consequences of it being false are significant (e.g. expensive or damaging to the business objectives) This consequence should be also registered in a risk register (projects prefer to track risks rather than assumptions)




A potential event of whatever nature that could impact the architecture.


At this stage it can be regarded as an additional constraint on the architecture e.g. Using unproven technology.

Specific Artifact Attributes

Description The description of the risk

Impact The impact if the risk becomes real, High, medium, low Measures Measures that can mitigate the risk

Hints and Tips

Conceptual Artifacts

Domain Artifacts Overview

A Domain is a way to describe an area by grouping services in order to fit with a specific goal.

For example by:

Using the business taxonomy of a company to explain how the services contribute to this domain

Grouping the services dedicated to governance or security

Grouping the services using a specific technology

A domain is not a structure in terms of architecture. This means that components defined in Logical and Physical phases could deliver a different grouping. It is interesting to make a x-ref of components and domains.

Business Domain


Value Chains (or parts of them) and other subject areas of a Business are called Business Domains. Usually they consist of a collection of Business Services contributing to a certain Business Goal.


Specific Artifact Attributes

Description The description of the specific domain

Parent Id Reference to the Parent Artifact Id

Context and Relationships

Aspect Area Abstraction level Business Information IS TI Governance Security

Contextual Conceptual X X X Logical Physical

Hints & Tips