ServiceOriented Architecture the way we see it

Enterprise, Business and

IT Architecture and the
Integrated Architecture
Framework
Contents
1 Introduction 1
2 Background 2
2.1 The Need for Architecture 2
2.2 Dening Architecture 3
3 Architecture the Capgemini Way 4
3.1 A Holistic View 4
3.2 Architecture and the Business Lifecycle 6
3.3 What is Good Architecture? 7
4 The Value of Architecture 8
5 Capgeminis Integrated Architecture Framework 10
5.1 Principles and Characteristics of IAF 11
5.2 Capgemini IAF Credentials 12
6 An Outline of the Integrated Architecture Framework 13
6.1 Abstraction Levels 14
6.2 Fundamental Artifacts 15
6.3 Aspect Areas 15
6.4 Views 17
6.5 Solution Alternatives 18
7 Applying the Integrated Architecture Framework 19
7.1 Engagement Roadmaps 19
7.2 Tools and Techniques 20
7.3 Using IAF for Enterprise Architecture 21
7.4 Using IAF for IT Solution Architecture 22
7.5 Solution Alternatives 25
8 Building an Architecture Capability 26
9 Supporting and Developing the Capability within Capgemini 28
9.1 Architects Certification 28
9.2 Architects Training 29
9.3 Ongoing Development 30
10 IAF, TOGAF and IEEE 1471-2000 31
11 Summary 32
Enterprise and Solutions Architecture are increasingly seen as paramount for
business and project success. The role of architecture is maturing rapidly, adding
tangible value, and significantly contributing to the success of businesses.
Capgemini recognized the value of architecture in the early nineties, developing
the first components of its architecture framework and approach, the Integrated
Architecture Framework (IAF), as early as 1993. IAF has been steadily enhanced
since to become a mature and comprehensive framework. Now in its fourth major
version, IAF was approved by The Open Group as a Recognized IT Architecture
Method in their IT Architecture Certification (ITAC) program in 2006.
IAF is fully supported by a comprehensive education program, an established
certification scheme and a broad, experienced and active community of practice.
Supported by this, Capgemini has developed one of the largest global Enterprise
and Solutions Architecture practices in its industry.
This document provides an introduction to Capgeminis positioning of
architecture within Business and IT, together with an introduction to the
Integrated Architecture Framework.

Enterprise, Business and IT Architecture and the Integrated Architecture Framework 1
1 Introduction
ServiceOriented Architecture the way we see it

2

2
Over the years, IT has evolved from delivering point solutions to a complex,
interrelated landscape of applications, interfaces and infrastructure that support
the business processes of an organization and the productivity of its people. More
recently, this has started to include an architectural view of business change, so
that Business and IT function seamlessly to deliver the goals of the business.
Architecture has always played a role in the development of systems. However,
until the early to mid 90s, it was almost exclusively used in technical
infrastructure, and commonly referred to as Systems Architecture.
As applications and systems increased in number and complexity, the need for
a clear and consistent view of the complete picture, together with a structured
approach to integration, became apparent. Gradually, the term architecture
was extended to include all areas involved; initially ranging from technical
infrastructure to information systems, and then towards information, processes
and business.
More recently, the differences between architecture at an Enterprise level and at
a Solution (or project) Level have become more clearly recognized and defined:
Architecture at the Enterprise level is oriented to the overall business, information
and systems landscape, whereas at the project or Solutions level, architecture is
more focused on a definition of solution direction and high level design.
2.1 The Need for Architecture
Uncontrolled growth of information systems and technology in the late 1990s
(often as a result of decentralized decision making) resulted in information and
systems landscapes becoming complex, costly and difficult to manage. As a
result, responding quickly and efficiently to new business challenges has become
increasingly difficult. Typical symptoms include (in no specific order):
n
Management remaining dissatisfied with the performance of IT or unclear
about targeted business benefits from IT.
n
Too many projects that are still not delivering their expected benefits or are
aborted prematurely.
n
Lots of talk about the latest IT trends that is not coupled to realizable
business benefits.
n
High and seemingly unmanageable IT operational costs, often as a result of too
many different and standalone systems and not enough standardization.
n
IT landscapes that include legacy systems, standard packages and tailor-made
software with many point-to-point interfaces.
n
Weaknesses in security management, for example complexity in registering
(or removing) users on multiple systems.
n
Inability of IT to keep pace with the desired business change without huge
corresponding increase in costs.
2. Background
2

Enterprise, Business and IT Architecture and the Integrated Architecture Framework 3
ServiceOriented Architecture the way we see it ServiceOriented Architecture the way we see it

In addition to these challenges, there are ever increasing demands on
organizations to be able to:
n
Compete with traditional and new entrants, and be able to adapt more rapidly
to their competitors and market change.
n
Rationalize overlapping and conflicting solutions arising from mergers and
acquisitions.
n
Conform to ever increasing regulations.
n
Drive down costs.
Not all organizations will necessarily have all of these issues or needs, nor can all
of these be solely addressed through the use of architecture. However, architecture
can provide insight, support decision making and help structure potential
solutions in many of these areas. The need for architecture can therefore be
summarized as the need to:
n
Transform IT into an enabler for business by offering better alignment of
business and IT;
n
Deliver more flexibility for business and IT, whilst balancing the often
contradictory needs of business; and
n
Manage complexity better, mitigating risk and aiding overall decision-making.
2.2 Defining Architecture
When looking for a clear and unambiguous definition of architecture (within
a Business and IT context), it becomes clear that there are still many different
perspectives, often as a result of their focus.
The Institute of Electrical and Electronics Engineers, Inc. (IEEE) who publish
IEEE 1471-2000 , Recommended Practice for Architectural Description of
Software-Intensive Systems, define architecture as:
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 highly applicable though it is more focused
on Solution Architecture than Enterprise Architecture.
Another definition is:
Architecture shows the relationships and interdependencies between the
organization, its processes and the information, IT system and infrastructure that
it uses. 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 is also applicable
for Solution Architecture.
All of the definitions have a common focus on defining the structure and
relationships of a system or enterprise with reference to a set of governing
principles that provide guidance and support for direction and decisions.
Furthermore, architecture must provide a coherent and holistic view of the
system or enterprise within an overall context of the wider eco-system (much like
building architecture), with a clear understanding of the big picture as well as
the detail. To achieve this, the use of abstraction and viewpoints is critical.
4
3. Architecture the
Capgemini Way
Capgemini started developing its architectural approach in 1993 and has steadily
evolved a framework around it, called the Integrated Architecture Framework
(IAF). This goes far beyond Technical, Software or Systems Architecture.
Capgemini views architecture as providing a comprehensive and coherent view
across Business, Information, Systems and Technology; not just to guide the
design of IT systems but to deliver business change supported and enabled by IT.
Architecture is therefore a lever to help transform an organization.
This holistic view of the business through the use of architecture is becoming
even more critical in shaping the business as organizations start incorporating the
approaches and architectural styles described as Service-Oriented Architecture
(SOA) and, when using this thinking at a business level, the Service-Oriented
Enterprise (SOE).
3.1 A Holistic View
Clients and the industry as a whole are moving towards a standard (but not yet
universally defined and agreed upon) set of terms that describe different types of
architecture. Typically, these 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.
Enterprise Architecture
Business
Architecture
S
c
o
p
e

o
f

t
h
e

I
n
t
e
g
r
a
t
e
d

A
r
c
h
i
t
e
c
t
u
r
e

F
r
a
m
e
w
o
r
k
Enterprise IT
Architecture
Organization
and People
Services and
Process
Information
Architecture
Enterprise IT
Information Systems
Architecture
Enterprise IT
Technology Infrastructure
Architecture
Software Architecture, Network Architecture, Storage Architecture, . . .
E
n
t
e
r
p
r
i
s
e
S
e
c
u
r
i
t
y

A
r
c
h
i
t
e
c
t
u
r
e
E
n
t
e
r
p
r
i
s
e
G
o
v
e
r
n
a
n
c
e

A
r
c
h
i
t
e
c
t
u
r
e
Solution
Architecture
Includes:
Business
Information,
Apps Systems,
Infrastructure.
Security and
Governance
Figure 1. Types of Architecture
4
.
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 5
ServiceOriented Architecture the way we see it ServiceOriented Architecture the way we see it
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:
n
Enterprise Architecture details the structure and relationships of the
Enterprise, its business models, the way an organization will work, and
how and in what way Information, Information Systems and Technology
will support the organizations 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 that supports these objectives and goals. Enterprise
Architecture is often likened to City Planning.
n
Enterprise Business Architecture (or Business Architecture) defines the
integrated structure of the overall business itself (in terms of organization,
people and processes). 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.
n
Enterprise IT Architecture defines and describes the structure and
relationships of IT systems at the Enterprise level in terms of how IT supports
the organization to achieve its business goals. This typically includes standards
and guidelines that are applied within Solution Architectures.
n
Solution Architecture defines architecture for a specific solution that is
either business or IT related. It provides structure, standards and guidance
for the detailed design of a solution, and is typically guided by Enterprise
Architecture. Solution Architecture is often described as Solution IT
Architecture or sometimes as Project Architecture, and is often likened to
Building Architecture.
n
Governance Architecture defines not only the traditional IT Systems
Management capabilities, organization and systems, but also addresses business
governance (how to manage overall business processes, both formal and
informal). It is increasingly critical for legislation and compliance.
n
Security Architecture defines not only traditional IT security but also addresses
business and information security, as well as resulting organizational and
business-related services to deliver the required security. It is often linked to
governance aspects to address security management.
This holistic view of architecture is directly reflected in Capgeminis IAF approach
with specific Aspect Areas that focus on Business, Information, Information
Systems, Technology Infrastructure, Security and Governance.
Note that the Software, Network and Storage Architecture(s) shown in the
diagram are outside the scope of IAF. Capgemini positions these as being in the
engineering/design focused methods such as the Rational Unified Process (RUP) for
Software Engineering and Capgeminis Infrastructure Design Framework (IDF) for
Network, Storage, etc. Together, these all form a coherent suite of frameworks in
Capgeminis Quality System, DELIVER.
666
3.2 Architecture and the Business Lifecycle
Capgeminis experience is that architecture only delivers maximum value when
it is an integral part of the overall business change lifecycle. In this way, the
whole enterprise (business and technology) can be designed together, informing
and supporting the business and IT strategies as well as shaping the business
and IT itself.
As organizations have to respond to changes in market conditions, the Enterprise
Architecture must be updated to reflect new business situations. Figure 2 below
demonstrates the way in which Enterprise Architecture drives and responds to the
overall Business and IT environment changes, once it has been established, and
governs and learns from the specific solutions needed to deliver on this vision.
Stepping through this, it is clear that there is a symbiotic relationship between
Enterprise Architecture and Solutions Architecture:
n
The Enterprise Architecture reacts to the changes inside and outside of the
organization so that it can continue to provide a complete and coherent view
of how it will support delivery of the business vision and goals.
n
The Enterprise Architecture informs and governs the business and IT project
portfolios (both business and IT) needed for the organization to move towards
the resulting target architecture.
n
The Enterprise Architecture also informs and governs the solutions
themselves by providing the structure, principles, guidelines and standards to
which the projects should adhere. This ensures that individual projects move
the organization towards its target architecture.
n
The Solution Architectures provide the detailed structure, principles, guidelines
and standards that govern and support the delivery of specific initiatives within
the overall Enterprise Architecture. In general, these are focused on a small part
of the overall architecture, although in absolute terms this may still be significant.
n
The Enterprise Architecture must learn the lessons from the development and
deployment of solutions, ensuring that it remains practical and pragmatic, and
not just an ivory tower.
Enterprise Architecture
EA governs
solution
Architecture
Projects
deliver the
EA vision
EA governs
the Project
Portfolio
EA learns
from the
projects
C
h
a
n
g
e
s
in
B
u
s
in
e
s
s
V
is
io
n
a
n
d
S
t
r
a
t
e
g
y
Changes in
Business
Technology
Context
R
e
g
u
la
t
o
r
y
C
h
a
n
g
e
s
&
E
x
t
e
r
n
a
t
In
f
lu
e
n
c
e
s
Triggers for
Change
Triggers for
Change
Projects
governed
by Solution
Architecture
Figure 2. The Learning Enterprise Architecture
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 7
ServiceOriented Architecture the way we see it
Architecture thus bridges the gap between Business/IT Strategy and the projects
that are needed to deliver this strategy. Aligning projects (business or IT) to an
overall Enterprise Architecture provides an often missing link in the governance
chain between vision, strategy and implementation. Architecture is, in effect, a
major part of the continuous improvement function for the Enterprise.
Architecture is a means to an end and not specifically an end in itself.
3.3 What is Good Architecture?
One common challenge when designing architecture is that it is easy for it to
become an end in its own right, rather than something that is there to help the
business. As a result, it can be difficult to assess when to stop designing the
architecture.
In fact, the reality for a majority of businesses is that, due to inevitable cost
and time constraints, changes to business objectives or strategy mean that
the architecture will rarely be 100% complete, perfect or even fully achieved!
Architecture represents the aspiration (or target to reach) and provides the
support framework to make decisions along a journey. The deciding factor
revolves around when the Architecture is good enough for its scope and
objectives to ensure that results deliver expected business benefits.
A number of ways can help an organization to understand when it has good
architecture, much of which is commonly understood as leading practice for
architecture frameworks. These include:
n
Understanding the Scope and Objectives of the architecture work, to know
when the results are good enough.
n
Understanding the Business (and IT) Context, including external facts
(regulation, etc.) that may affect the results.
n
Formalized and traceable Business Objectives and Principles, driven by the
Business Mission and Vision.
n
Looking at the Solution or Enterprise in a holistic manner across disciplines to
understand the impact of decisions.
n
Documenting the Rationale for all Architectural and Design Decisions, ideally
reflecting the Principles/Business Needs.
n
Providing clear Traceability back to the Business Objectives within the
architecture.
n
Investigating Solution Alternatives to ensure that decisions are made in a
holistic manner and not in isolation.
n
Capturing, validating and managing any Assumptions and Constraints that
affect the architecture.
n
Proactively Managing Risks and Issues, both of the process as well as the results.
As covered later, Capgeminis Integrated Architecture Framework (IAF) has been
specifically designed to enable architects to deliver these criteria, by providing
the necessary structure and architectural artifacts together with documented best
practice, supported by a comprehensive education program.
ServiceOriented Architecture the way we see it
Architecture must not be seen as just a purely academic exercise, but it must
clearly deliver (and continue to deliver) value to a business. There are many ways
that this value can be realized, either through reduced cost or through increased
value/competitiveness:
The following are some examples of the values that can be realized through the
effective deployment and use of architecture.
Value for the Business
11. Providing a full and coherent overview and understanding of an enterprise,
and where the competitive value exists i.e. people, roles, processes,
organization, goals, policies, rules, events, locations, etc.
12. Enabling business process improvement by structuring the business
according to key services needed by the enterprise, based on a clear
understanding of the goals and drivers of the business.
13. Identifying and eliminating (or resolving) duplication across the enterprise,
enabling a move towards a shared service model, including identification
of those non-core services that may be better sourced externally.
14. Ensuring business compliance.
Value for IT
15. Reducing solution delivery time and development costs by maximizing
reuse of architecture models and existing systems, services and solutions.
16. Improving project success by reducing risk and complexity and having early
visibility of IT and business issues inside and outside the project.
17. Reducing the risk of IT non-compliance with key regulations, especially as
business becomes more regulated, e.g. HIPAA, Sarbanes-Oxley, etc.
4 The Value of
Architecture
You can collaborate more
effectively than your
competition with your
customers, suppliers and
partners
Expand Reach
Increase Project Success
Increase Business Agility
Reduce Cost and Risk
You can continuously adapt
your business and IT more
quickly and with lower risk
than your competition
You can significantly
improve your success with
your investment in business
and IT projects - doing the
right projects, at the right
time and doing them right
You can better understand
the impact, cost and risk of
change.
You can deliver more cost
effective solutions than your
competitors.
Reduce Cost
Increase
Value
Figure 3. The Value of Architecture

8

18. Improving IT planning and the management of IT roadmaps and portfolios,
also enabling improved planning for resource skills and training.
19. Implementing and managing security by design instead of reacting to
breaches as they are discovered.
10. Delivering solutions that meet IT Service Level definitions that are linked
back to real business objectives. This will reduce instances of costly, over-
engineered solutions.
11. Reducing the cost of Business As Usual by better managing operational
costs through the consideration of Governance as part of the overall
architecture and not, as is often the case, an afterthought.
Value for Business and IT
12. Improving Business and IT alignment, allowing, for example, the
identification of misalignment of individual projects with strategic outcome
in early stages.
13. Cost Control and Improved ROI by ensuring departmentally-focused
project teams can understand what shared or reusable services are available
and long-term costs of not using these.
14. Increased Agility and Competitiveness where IT becomes an enabler and
partner for the business, instead of being seen as a cost or constraint.
15. Helping Deliver Strategy and Better Business/IT Alignment through the
governance model for solution development and portfolio management
from an Enterprise Architecture.
16. Ensuring alignment of data and information management with business
objectives (e.g. partnerships)
17. Creating and maintaining a common vision of the future that is shared by
both the Business and IT communities.
Thus, the effective use of architecture within an organization can help reduce
business and IT costs in those areas needed to run the business (e.g. for
regulatory compliance, etc.), freeing up resources for new investment in areas
that can really deliver improved competitiveness.
The above illustration shows how a small improvement in the cost of normal
business can free up proportionately more funds for investment in delivering
improved competitiveness.
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 9
ServiceOriented Architecture the way we see it
Architecture can enable
Improved responsiveness to Business Change
Increase Flexibility within the Business and IT
Innovation/leveraging of new technology Competi-
tiveness
Cost
Compliance
Reduce cost of environment
Increased project success
Reduced project risk
Leverage new capabilities
for competitive advantage
Reduce costs
What you have to do
to run your business
What you have to do
to be in business
Small %
decrease in costs
frees significant %
increase in ability
to invest
B
u
s
i
n
e
s
s

B
e
n
e
f
i
t
Spend
Based on Maslows Hierarchy of Needs
Figure 4. The Three C's in Business

10
5. Capgeminis Integrated
Architecture Framework
In 1993, the architecture approaches that were to become the basis for the
Integrated Architecture Framework were developed by Capgemini in the UK,
France and the Netherlands in response to specific engagements. The value
of a repeatable and portable architectural approach in these areas was quickly
recognized, leading to the development of the first version of the Integrated
Architecture Framework (IAF) and the first formal training for architects.
Since its inception, IAF has evolved and matured as a result of real life
experiences of Capgeminis global Architecture Community. Training events
which often comprise more than 16 nationalities is evidence of the international
adoption of IAF across Capgemini. As a result, major versions have been
delivered to reflect increased breadth of the framework, incorporation of Business
Architecture and greater maturity of the discipline as a profession.
In 2001, Capgemini released the third major iteration (IAFv3), when Business
and Information became fundamental aspects of thinking, and services based
elements (which have always been a part of IAF) were further infused into the
approach. IAFv3 has been successfully used in hundreds of major programs with
many clients, and has been deployed in a number of major client organizations as
the basis for their Architecture Framework.
In 2006, Capgemini released a significant update, IAF 4.0, to clarify material and
incorporate Business and Information aspects based on its field experience over
the previous five years.
Figure 5. Evolution of 1AF
Zachman
1992
93 94 95 96 97 98 99 00 01 02 03 04 05 06 07
TOGAF 8 TOGAF 7 TOGAF 1,2,3... TOGAF 8.1 TOGAF 9
IAF 4.0 IAF 3.0 IAF 2
Zachman
1987
IAD (nl)
AD-IS AD-IS A.A. (fr)
AD-BEA
AD-DSE
AD-GOV
ADM (uk) AD-TI AD-TI
IAF 1
Information
Information Systems
Governance
IEEE
1471.2000
IEEE
1003.23
IAF 3.9
Business
Technology Infrastructure
Security
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 11
ServiceOriented Architecture the way we see it
5.1 Principles and Characteristics of IAF
In developing IAF, Capgemini specified the framework based on key requirements
and fundamental principles:
To achieve these, the Integrated Architecture Framework explicitly separates
Process from Content; the content is formally described in the content
framework, whilst process is incorporated in Engagement Roadmaps, supported
by tools and techniques.
Value
focused
Traceable
to business
Address
Complexity
Holistic &
integrated
Considers
different
aspects
Allows
special
focus
Stable
Flexible
Scalable
Fast and
efficient
Provides a
common
language
The approach must be focused on delivering value
to clients
The architecture and any decisions made as part of the
architecture must be clearly justified and traceable back
to the needs of the business.
Architecture structures complex problems; the way to
address this is by using different levels of abstraction.
The architecture approach must integrate the full scope
of business and technology issues.
Architecture must support different business issues and
domains of architecture.
Developments in business and technology require the
capability to provide special attention to specific areas.
The architecture approach requires a stable content that
is easy to handover and easy to communicate.
The approach must support architecture work in
projects and stand-alone architectural services. The
approach must not contain a prescriptive methodology,
but must provide a stable platform for innovation.
The approach must scale from Solution to Enterprise
level architecture.
The market demands that the architecture approach be
as fast and efficient as possible.
Use of a common language improves communication
between business and IT, leads to more efficient team
working and is crucial to knowledge sharing.
12
ServiceOriented Architecture the way we see it
5.2 Capgemini IAF Credentials
The Integrated Architecture Framework (IAF) enables architecture to be defined
and justified in business terms and provides a reference model to plan, design
and implement required services. It achieves this by capturing the business need
and aspirations primarily in terms of guiding principles. These principles provide
a reference point throughout the engagement, which is used to ensure that the
developing solution continues to meet the overriding business need.
IAF also helps create an early mock-up of the final solution, which enables
the client to analyze and evaluate the impact of organizational principles and
requirements without the need to go into an expensive design or prototype
project. This capability is even more important where work is moved offshore
by organizations.
IAF has been successfully used throughout Capgemini on hundreds of
engagements covering IT Solution Architectures for systems development, systems
integration and package-based solutions, Business Architectures and Enterprise
Architectures. This includes engagements with a number of high profile clients in
North America, Europe and Asia, spanning all sectors, for example:
n
Cadbury Schweppes
http://www.capgemini.com/resources/success-stories/cadbury_schweppes/
n
Corus plc, UK
http://www.capgemini.com/resources/success-stories/corus/
n
Croydon Borough Council, UK
n
Ericsson, Sweden
n
Electricit de France (EDF)
n
HM Revenue and Customs, UK
n
KBC Group, Belgium
http://www.capgemini.com/resources/success-stories/kbc_group/
n
NATO
http://www.capgemini.com/resources/success-stories/nato/
n
UK Ministry of Defence (DECS)
n
Vodafone, Sweden
IAF has been extremely well received by our clients, and in a number of cases,
Capgemini has been engaged to assist them in developing their own internal
architectural capability supported by frameworks based on IAF and tailored to their
specific needs, for example, at KBC, Dutch Rail, Corus and Cadbury Schweppes.
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 13
ServiceOriented Architecture the way we see it
The Integrated Architecture Framework is used to structure and define the
architecture content. The framework:
n
provides a model for architecture development and usage;
n
describes the format and content of elements of the architecture;
n
specifies the way in which these elements relate to each other.
The following diagram shows the basic structure of IAF. The model is broken
down into Aspect Areas and Abstraction Levels. Each cell in this model has a
defined set of Artifacts. Views then allow architects to bring together and visualize
the artifacts to help model the architecture and communicate results with the
various stakeholders.
Within this framework, IAF describes the architecture using two basic constructs.
The first construct, Artifacts, describes the architecture elements. Artifacts belong
to, and are derived from specific areas in the architecture framework.
The second, Views, is used to analyze and present the architecture from different
perspectives and to document relationships between Artifacts. Views show why
the architecture is what it is, providing both traceability of, and the justification
for decisions made when developing the architecture. Views also provide a way
to present architecture in an appropriate form for various stakeholders, thereby
building acceptance.
6. An Outline of the
Integrated Architecture
Framework
Figure 6. The Integrated Architecture Framework
Governance
Security
B
u
s
i
n
e
s
s
I
n
f
o
r
m
a
t
i
o
n
I
n
f
o
r
m
a
t
i
o
n
S
y
s
t
e
m
s
T
e
c
h
n
o
l
o
g
y

I
n
f
r
a
s
t
r
u
c
t
u
r
e

WHY?
Contextual
WHAT?
Conceptual
HOW?
Logical
WITH WHAT?
Physical
The following sections describe in a little more detail what IAF consists of. More
detailed information and guidance is available to IAF users through detailed
reference manuals, courses and internal knowledge repositories.
6.1 Abstraction Levels
Abstraction allows a consistent level of definition and understanding to be
achieved in each area of the architecture. It is especially useful when dealing
with large and complex architectures, as it allows relevant issues to be identified
before further detailing is attempted. This approach is found in most architectural
approaches including The Open Group Architecture Framework (TOGAF) and
the Zachman Framework for Enterprise Architecture. The Integrated Architecture
Framework (IAF) defines four levels of abstraction:
The Contextual Level, characterized by Why?, is not about understanding
what the new architecture will be. It helps to identify boundaries (i.e. scope and
objectives) for the new architecture and its context. Specifically, this level focuses
on the business aspirations and drivers, capturing the Principles on which the
architecture will be based. Unlike some approaches, these Principles are formally
described to include their rationale, implications, priority and even assurance
measures for compliance, so that they reflect the often conflicting requirements of
stakeholders in a business.
The Conceptual Level, characterized by What?, is when requirements and
objectives are analyzed and elaborated. It ensures that all aspects of the scope are
explored, relevant issues identified and resolved, without concern over how the
architecture will be realized.
The Logical Level, characterized by How? helps to find an ideal solution that is
independent from implementation. From this, several solution alternatives can
be developed that either provide the same outcome, or alternatively test different
priorities and scenarios to understand the implication of different potential outcomes.
The outcome of logical level analysis is the vision of the desired to-be state.
The Physical Level (With what?) helps to determine the real world structure
and organization, by translating the desired logical level structure and
organization into an implementation-specific one bounded by standards,
specifications and guidelines. At the physical level, the outcome is a description
of how the desired state will be achieved. The physical level may produce several
physical architectures depicting a series of steps along a road to achieving the
desired state, or simply the first, depending on the architecture objectives.
The physical architecture provides standards, guidance and a degree of
specifications within which detailed design will take place. It does not replace
detailed design.
It is important to remember that any architecture model cannot include the
complete functional, data or user requirements for a solution at a detailed
level. The selection of physical products therefore has to be driven by detailed
functional/user criteria in addition to architectural fit.
14
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 15
ServiceOriented Architecture the way we see it
6.2 Fundamental Artifacts
There are a number of fundamental Artifacts used across IAF to make the
model as consistent and simple as possible. These are detailed in the Aspects
Areas (e.g. Business Service) and, together with aspect-specific Artifacts, make
up the IAF model.
Services are a fundamental construct in IAF and describe specifically what is
required (but not how it is done). Services are defined at the conceptual level and
describe the capabilities, or what must be done in each aspect area to support
business objectives. Services interact with other services and this interaction is
described through Collaboration Contracts.
Many services within a system are not technology services. They can have many
attributes and effects that are not defined or measured by technology. In IAF,
Services reflect not only the characteristics at the lower levels (e.g. technology)
but also the impact of higher level agreements (e.g. business KPIs).
Components are Logical or Physical entities in IAF that represent the solution with
a clearly defined scope and role. Logical Components provide an implementation
independent description of the solution, whilst Physical Components provide the
implementation-specific description, including standards and potential products.
Components deliver one or more services (or logical components in the case of
physical components) and there is usually more than one way to organize them
(see Solution Alternatives in section 6.5).
Collaboration Contracts describe the behavior of the interaction between the
services (or components). This is distinct from the characteristics of the services
(or components) themselves, allowing for rigorous analysis of integration
requirements and enables the decoupling required for Service-Oriented
Architecture (SOA).
Collaboration Contracts are first derived between Services at the Conceptual
Level. These contracts are then used to define the required Collaboration
Contracts between the Components, first at the Logical, and then Physical levels.
6.3 Aspect Areas
To break down the complexity of the architecture, IAF recognizes four major
Aspect Areas which focus exclusively on the core aspects of the overall
architectureBusiness, Information, Information Systems and Technology
Infrastructure. The Business aspect area is especially important, as this not only
allows modeling of the business to deliver IT solutions, but also provides a way to
architect the Business.
IAF also explicitly recognises two additional, special Aspect Areas that specifically
address the Governance and Security perspective of the architecture. These are
deemed special (and are shown in the third-dimension of the model) because
they:
n
represent a set of requirements driven across all core aspect areas
n
apply to all the other aspect areas but may be applied stand-alone
n
use artifacts from the other aspect areas to describe themselves
n
may significantly change the architecture structure across one or more core
aspect areas.
16

The Business aspect area adds knowledge about business objectives, activities,
and organizational structure. Key artifacts in this aspect area include:
n
Business Role
n
Business Activity
n
Business Goal
n
Business Service
n
Business Object
n
Logical Business Components
n
Business Actor
n
Physical Business Component
n
Business Specification
n
Business Guidelines
n
Business Standards
The Information aspect area adds knowledge about information that the business
uses, its structure and relationships. Key artifacts in this area include:
n
Information Object
n
Business Information Service
n
Logical Information Component
n
Logical Business Information Service Component
n
Business Communication Specification/Guidelines/Standards
n
Information Specification/Guidelines/Standards
The Information System aspect area adds knowledge about types of information
systems (packaged or bespoke) that can automate and support the processing of
information used by the business. Key artifacts include:
n
Information System Service
n
Logical Information System Component
n
Physical Information System Component
n
Standards, Specifications and Implementation Guidelines
The Technology Infrastructure aspect area adds knowledge about types and
structure of components that support the information systems and actors. These
may be hardware or network related. They may include fundamental services
such as databases, etc. and key security and other commodity shared services.
Key artifacts include:
n
Technology Infrastructure Service
n
Logical Technology Infrastructure Component
n
Physical Technology Infrastructure Component
n
Standards, Specification and Implementation Guidelines

Enterprise, Business and IT Architecture and the Integrated Architecture Framework 17
ServiceOriented Architecture the way we see it
The Governance aspect area focuses on the manageability and quality of the
architecture implementation (both business and IT) that is required to satisfy
the services levels required by the business for its processes and systems. The
artifacts for this area are all fundamentally defined within the core aspect areas
(Business, Information, Information Systems and Technology Infrastructure),
although the outcome from this aspect area will be new specialized Services
and Components to deliver the governance.
The Security aspect area focuses on the mitigation of known risks to the
architecture implementation (both business and IT). The artifacts for this area are
also all fundamentally defined within the core aspect areas (Business, Information,
Information Systems and Technology Infrastructure). The outcome from this
aspect area will be new specialized Services and Components to deliver the
required security.
6.4 Views
Views are a fundamental part of the approach defined in the Integrated
Architecture Framework. They are used to present the architectural model to
various stakeholders. They offer an important tool to help architects develop
the architecture by allowing them to inspect and validate it as a whole from one
perspective (viewpoint) to build a complete, composite and consistent picture of
the solution across all areas.
Views are highly context dependant. Their applicability and use will depend on the
client, stakeholders and engagement type. Some views that may be needed include:
Models and Cross-Reference Views are two techniques to link services and/or
components in IAF. Interaction Models capture links between artifacts of the same
type, helping identify interfaces and the Collaboration Contracts needed. Cross-
Reference Views capture connections between different types of artifacts (e.g.
Business to IS) providing traceability across aspect areas and to business needs.
Major Information System Interfaces Model helps visualize major Information
System Service Interactions.
Integration View allows logical components from the perspective of Collaboration
Contracts to be visualized, highlighting different integration approaches needed.
Distribution View visualizes the distribution of components of the solution, typically
across topographical or geographic areas such as data centers and office locations.
Security View to focus on how security components or requirements are overlaid
on other aspects of the architecture, typically as an end-to-end view across the
architecture showing security domains and services that will be required.
Governance View to focus on how the architecture will be governed in terms of
quality objectives such as availability, performance and restorability, and how they
will be addressed by governance components.
Migration view to illustrate how the architecture will be implemented over
time, describing different stages of the migration and linking them to available
capabilities within the organization.
18
6.5 Solution Alternatives
In determining the most appropriate architecture solution, it is critical that
different options are considered and the rationale for specific design decisions
captured. Solution Alternatives are a way to achieve this within IAF.
Solution Alternatives are used in the Logical and Physical levels to work through
implications of different options, either architecture-wide or at the major
component (or sub-system) level. They are often used to demonstrate the impact
of conflicting needs expressed by the business (e.g. 24x7, secure, flexible, etc.).
The selection of the various candidate Solution Alternatives and the identification
of the best fit solution is driven from the principles and priorities originally
defined in the Contextual level, and refined throughout the rest of the architecture
process. This ensures that the solution and design decisions reflect, and are
traceable back to, business requirements.
Typically, at least two Solution Alternatives will be considered in both the Logical
and Physical levels. Seen as a fundamental part of the architecture approach, this
is recognized in most frameworks as the way to help make informed decisions.
The use of Solution Alternatives ensures that wider implications of available
options can be seen in context rather than allowing individual selections to be
applied in isolation.
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 19
ServiceOriented Architecture the way we see it

The previous section describes the overall structure and language that Capgemini
has developed to be able to deliver architectures. To use this model to deliver
architectures, the content is supplemented by:
n
Tools including templates and supporting tools, etc.
n
Techniques including Workshops, Focused Interviews, etc.
n
Engagement Roadmaps to bring all the outputs together.
These elements of the approach were deliberately separated from the content
definition to provide the flexibility required by clients when adopting IAF, making
it more agile and able to evolve with the industry. This approach also ensured
that the overall model defined (the Layers, Aspects and Artifacts) could be kept
as simple as possible whilst supporting the use of IAF in a wide range of diverse
architecture situations and engagements.
Despite the approach having been developed in 2001, its benefit is demonstrated
through regular and successful use of IAFv3 to deliver SOA-based solutions well
before the industry and analysts started viewing Service-Oriented Architecture as
an important differentiator for enterprises.
7.1 Engagement Roadmaps
The Engagement Roadmap provides the process element for an architectural
engagement to bring together:
n
clear definition of the scope and focus across various aspect areas of IAF,
including artifacts and required views
n
plans (typically describing outcomes/milestones) that include stakeholder
interactions and other communication activities
n
definition of deliverables from the work, both in terms of scope and content
as well as format.
The Engagement Roadmap also identifies key tools and techniques to be used in the
study, for example Templates, Reference Architectures and Patterns, Workshops and
Focused Interviews. The construction of the Engagement Roadmap is dependant
on the specific context, architectural objectives and scope of the architecture work.
There are a number of patterns that provide the basis for many types of architectural
engagements to help accelerate the creation of the appropriate Engagement Roadmap.
This clear separation of content from process allows IAF to provide the content
for other, industry frameworks such as The Open Group Architecture Framework
(TOGAF), with the TOGAF Architecture Development Method (ADM) providing
the process for IAFs content.
7. Applying the
Integrated Architecture
Framework
20
7.2 Tools and Techniques
The final aspect of applying the Integrated Architecture Framework is the use of
relevant tools and techniques.
Tools can include anything from standard templates through standard office tools
such as Microsoft Word, Excel, PowerPoint and Visio, through to specialized
Enterprise Architecture tools.
Given the wide range of clients and engagements that Capgemini architects are
involved with, it is often the case that the office tools provide the necessary
flexibility for Capgemini and accessibility for the client. Furthermore, as
communication with stakeholders is such a critical element of any architectural
engagement, the use of tools such as Microsoft Word and PowerPoint will almost
always be required.
This range of clients also brings with it a diverse range of corporate standards for
tools (business, EA and development). IAF is inherently flexible so that it can be
captured in many of these tools, allowing the architectural content to be easily
linked to the development process. Examples of tools that have been used to
capture IAF artifacts include Metis, Mega, System Architect and iServer, as well as
development tools such as Rational.
When organizations are developing an internal architecture capability, the
question of tools support takes on a different perspective. There is a clear need
to be able to manage vast amounts of information (including understanding the
impact of potential changes) across a number of teams. Capgemini leverages its
experience implementing various Enterprise Architecture tools to support EA
functions using IAF.
The concept of techniques allows various approaches to be used to gather
information, make decisions and solve problems across disparate environments,
for different types of architecture work as well as different types of businesses and
corporate cultures.
These techniques can include various approaches to workshops, use of focused
interviews and war rooms to show work in progress as well as derive specific
techniques like launch Business Services.
IAF, when applied using relevant tools and techniques through an agreed
Engagement Roadmap, delivers the combination of flexibility and rigor required
to support design principles for an organization (section 5.1).
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 21
ServiceOriented Architecture the way we see it

7.3 Using IAF for Enterprise Architecture
At an Enterprise level, the architecture focus is broad and decisions are much
more strategic in nature, concerned with setting direction and policy. In this
context, answering What is the priority along with a broad indication of How.
With what tends to drive out policies and principles to be followed. In some
cases this may extend to products and standards often in the form of architecture
constraints, for example, We will use our current investment to support all
subsequent ERP solutions.
This is where the architecture scope and objectives are crucial to selecting the
correct areas of the framework to use, and even more importantly, the level of detail
required to achieve the architecture objectives. For example, is the architecture
being used to answer a Business Transformation objective or an IT Enablement
question? In the former, the focus may be to view the Business and Information
aspects in more detail, whereas the latter will focus more on the IS aspects.
The deliverables from the two examples would often be the same but with
different focus and detail:
n
Business and Technology Context focusing on business context and principles
for Business Transformation and on the IT context, and business and IT
principles for IT Enablement.
n
Enterprise Architecture covering the requirements and derived Logical
Architecture together with Standards and Guidelines needed to govern
Solution Architectures:
Business Transformation will focus on Conceptual and Logical Business
and Information aspects and the Business policies and Guidelines;
IT Enablement will focus on Conceptual and Logical Information,
Information System/Technology Infrastructure aspects together with the
Standards and Guidelines for the use and development of Information,
IS and IT.
n
Project Portfolio plans or guidance and/or Roadmaps to show how the
architecture vision is achieved over time, informing either the Transformation
strategy or the IT Strategy.
n
Governance Model to use the Enterprise Architecture to guide (and learn from)
solutions being delivered.
22
7.4 Using IAF for IT Solution Architecture
When using IAF to develop an IT Solution Architecture, the overall approach
will depend on the availability of appropriate input. Ideally, an existing Enterprise
Architecture will exist, although care should be taken to ensure its scope and
objectives are aligned to the scope and objectives of the Solution Architecture.
Using the example from the previous section, it is unlikely that the IT enablement
Enterprise Architecture would be sufficiently complete to support the elaboration
of a Business Solution Architecture, although it would provide a lot of valuable
information. This is a very common trap (irrespective of approach, tools and
methods used) where the presence of an Enterprise Architecture leads to
assumptions about completeness of information to support Solution Architectures.
It is also worth remembering that the IAF is a content framework, not a process
framework. This means that relationships between artifacts indicate starting
points for each aspect area. Completeness of information required from other
aspect areas to support a specific aspect comes from all levels. For example, the
organizational disposition of business components in reality is not the outcome of
logical business levels but part of the physical business specification, i.e. similar
specifications exist in the physical information specification for the disposition of
master data sources. Whilst the desired logical state of business and information
would support a desired IS solution, the absence of this information could
significantly affect the physical outcomes of an IS/IT Solution Architecture.
Deliverables from such an engagement would therefore typically include clear
documentation of the:
n
Business, Technology and Architecture Context together with the Overarching,
Business and IT Principles
n
Conceptual Architecture covering the detailed requirements, often with the
relevant Business Architecture
n
Resulting Logical Architecture including the rationale for any decisions made
and relevant Solution Alternatives
n
The Physical Architecture, covering Specifications, Products, Standards and
Guidelines needed to govern the design.
7.4.1 IT Solutions Architecture and the Design Continuum
Successfully delivering IT solutions requires architecture to reflect the type of
solution being addressed and link effectively into design stages of the overall
project. To this end, the architecture has to be seen as just part of the overall
process to deliver a solution.
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 23
ServiceOriented Architecture the way we see it
Figure 7 below shows the context of IT Solution Architecture within the overall
solution lifecycle, including the clear need for architectural governance (the
Technical Design Authority role) throughout the design and implementation
stages of the project.
Figure 8 below illustrates how IAF aligns/works with existing design methods
(in this case, RUP , the Rational Unified Process) to ensure that the outputs from
architecture feed directly into design.
It is worth noting that, to ensure this design continuum in a Solution
Architecture, it is important that the lead Software, Infrastructure and other
Engineers are involved in the development of the Physical Architecture wherever
possible, aiding both feasibility and handover.
Solution and Service Delivery Models
Delivery Transformation
Transformational Outsourcing
Commercial Engagement Models
Business Strategy
Business Operating Models
IT Strategy
Enterprise
Architecture
Enterprise
Architecture Value
Maintain
& Evolve
Project/
Solution
Architecture
System/
Solution
Design
Project/
Solution
Development
Systems/
Solution
Integration &
Test
System/
Solution
Deployment
User
Acceptance
Production
Support
Version Control, Configuration Management,
Release Management
Project Infrastructure and Tools Support
Technical Design Authority
Technical Management Value
D
r
iv
e
s

S
u
p
p
o
r
t

&

E
n
a
b
le
r
s

Figure 7. IT Solution Architecture and the Design Continuum
Contextual
Conceptual
Context
Conceptual
Architecture
Logical
Architecture
Physical
Architecture
Analysis & Design
Requirement
Business Model
Implementation
Test
Deployment
Configuration & Change Management
Project Management Engagement Mgt.
Environment
Architecture Inception Elaboration Construction Transition
IAF
RUP
F
u
n
c
t
i
o
n
a
l

S
c
o
p
e
M
a
j
o
r

S
o
l
n
C
o
m
p
o
n
e
n
t
s
N
o
n

F
u
n
c
t
i
o
n
a
l
s
G
u
i
d
e
l
i
n
e
s

a
n
d
S
t
a
n
d
a
r
d
s
Figure 8. Alignment of Architecture (IAF) and Design (RUP)
24

7.4.2 IT Solution Architecture for Package-Based Solutions
Package-Based Solutions, for example Enterprise Resource Planning (ERP)
packages such as SAP, Oracle Applications or Microsoft Dynamics have become
increasingly important for many organizations. Although it is often thought that
such packages do not need an IT Solution Architecture (as it is believed that the
package defines the architecture), experience shows that there is just as much
need for an architecture when deploying Package-Based Solutions as there is for
other solutions.
The IT Solution Architecture approach for Package-Based Solutions is
fundamentally no different from that required for custom solutions, although
the focus of the architecture may be somewhat different. The key architectural
challenge faced with such packages is often that, whilst they impose constraints
on all of the architecture aspects, (primarily because the services and inter-
relationships in a package are predetermined, to a greater or lesser extent), they
exist within and must integrate with the organizations wider application (and
business) landscape.
Irrespective of whether the package is to be selected as part of the project, or
(as is often the case) has already been selected and needs to be deployed and
integrated with other systems, the architecture work will therefore typically need
to focus on:
n
validation of business objectives and the business architecture against the
package in context identifying areas where a package may need to be
customized and/or extended
n
identifying and designing how the package (services) relate and interact with
other services (package or custom, new or existing)
n
understanding the information architecture aspect, to provide guidelines and
specifications for Master Data Management
n
understanding requirements that the package in context will place on the
infrastructure (and any resulting changes)
n
ensuring appropriate levels of security and governance for the overall solution.
Capgeminis IAF successfully enables and supports the architecture required for
Package-Based Solutions, both for package selection and for the implementation
and integration of a specific package.
The need for architecture becomes even more important now that Package-Based
Solution vendors are re-orienting (and often fundamentally redeveloping) their
products to be more Service-Aware. This drive towards a Service-Oriented
Architecture (SOA) approach is intended to enable these packages to become
more agile, enabling the organizations using them to develop more adaptable
solutions to meet, and often develop, emerging or new ways of working,
potentially even building completely new markets. To support the desire for
agility, there is also a push to develop specific business processes rather than
relying on a packages embedded processes. This means that the architecture
approach used to support these changes needs to have an enterprise-wide,
services-based holistic view of both business and IT. However, whilst the new
service-aware Package-Based Solutions enable and support this flexibility, many
of the vendors deployment approaches are still based on the view of a package as
a black box and a new approach is needed.
IAF successfully delivers an architectural approach that supports and enables this
business agility with a holistic view of business and IT underpinned by its clear
linkage from business drivers and objectives through to the deployed services.

Enterprise, Business and IT Architecture and the Integrated Architecture Framework 25
ServiceOriented Architecture the way we see it
7.5 Using IAF for Business Solution Architecture
Using an architectural approach to support and drive business change brings
many benefits, including the holistic approach and rigorous analysis that is
fundamental to architecture. As more organizations look to evolve towards the
Service-Oriented Enterprise, Business Architecture helps develop a service-based
view of the businessan important first step.
Capgeminis IAF delivers this by providing support for stand-alone Business
Architecture or for concurrent Business and IT Architecture support as described
in 7.3 - Using IAF for Enterprise Architecture.
It would be rare for the Business Architecture to not incorporate extensive IT
considerations. The IAF supports this by providing a common language to
describe business and IT elements and more importantly, demonstrate linkages
and traceability between these different aspects
Using IAF to produce stand-alone Business Architecture will focus on the
Business and Information aspects, and more importantly, the Security and
Governance aspects, as these two should be regarded as business issues especially
critical in todays world of compliance (IT merely implements security and
governance policies).
Business Architecture may still be a largely undefined concept, so the IAF Business
Aspect area focuses on key structural aspects of business, primarily in terms of:
n
What activities does the business conduct?
n
What roles are needed to support those activities?
n
How are those activities and roles organized and governed?
n
Required levels of resource and information to support these?
Deliverables from such an engagement would therefore typically include clear
documentation of the:
n
Business Context together with the Overarching and Business Principles
n
Conceptual Business Architecture providing a holistic view of the detailed
requirements, often for the first time, in which case it may be used to inform
the Business Strategy
n
Logical Business Architecture covering roles, organizational structure and
logical processes
n
Physical Architecture covering Specifications, Products, Standards and
Guidelines needed to govern the detailed design of the organization, roles/
capabilities and processes
26

Developing an architecture capability (especially at Enterprise level) is an
important (and growing) objective for clients. To be credible and successful within
an organization, an architecture function needs to be sponsored and supported
at the board level. It demands close collaboration between the business and
technical functions of the entire organization.
The function also needs a well defined governance structure, clearly defined roles,
as well as the development of architecture processes and how they integrate into
the business change process. The architecture function will also need to develop
training and succession plans as well as considering whether to implement some
form of certification and accreditation schemes.
Experience shows that there are some fundamental challenges to move
Enterprise Architecture from a good idea to a mature, value-adding professional
discipline. Capgeminis practical and proven approach helps clients overcome
these challenges and accelerates the realization of tangible business benefits of
Enterprise Architecture.
A number of key ingredients must be combined to create an effective internal
Enterprise Architecture capability. Developing an Enterprise Architecture
capability needs to address the following areas:
n
Enterprise Architecture Strategy. Enterprise Architecture translates the strategic
objectives and vision of an enterprise into a realizable blueprint for business and
IT change. There must therefore be a clear strategy, value case and mandate for the
role of Enterprise Architecture within the organization. Without such a strategy and
vision to steer overall direction and principles, there is little chance of Enterprise
Architecture demonstrating tangible value.
n
Framework, Method and Tools. Enterprise Architecture occupies a broad
spectrum from strategic planning to project-level solution design. There are tools
and techniques that support activities across this, but no single tool or technique
provides the whole answer. The organization must therefore choose a framework,
method and tools that are robust, scalable and sustainable for both architecture
development and its ongoing maintenance.
n
Capability and Competency. Enterprise Architecture is complex and requires
a strong blend of capabilities, competencies and experiences. A common
misconception is that IT people are best suited for this role. Experience shows
that it is essential to achieve a balance between technical, business and managerial
skills, supported by well-structured skills development and training.
n
Architecture Content. Enterprise Architecture is expressed through often complex
and interdependent content that defines the business and technology landscape
of an organization. Whilst it is essential to have knowledge and understanding of
the current landscape to plan for and define what the future should look like, it is
critical to focus on content that addresses the strategic change agenda and presents
a realizable vision of the future. Many Enterprise Architecture initiatives have failed
because one or more of these ingredients is missing. Even where projects possess all
of them, it is often tempting to focus on a particular enterprise problem, resulting in
an output that cannot evolve into a sustainable Enterprise Architecture capability.
8. Building an
Architecture Capability
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 27
ServiceOriented Architecture the way we see it
n
Community and Culture. Enterprise Architecture is expressed through often
complex and interdependent content that defines the business and technology
landscape of an organization. Whilst it is essential to have knowledge and
understanding of the current landscape to plan for and define what the future
should look like, it is critical to focus on content that addresses the strategic change
agenda and presents a realizable vision of the future.
n
Governance and Assurance. Enterprise Architecture is a knowledge-intensive
activity. Experience shows that good governance and a well-defined architecture
management process is critical to ensure that knowledge is captured effectively so
that it can be applied, managed and maintained at all stages from its initial creation
through business and IT change projects.
By bringing ingredients together in the right order, at the right time and
involving the right people, it is possible to create the basis of a successful and
sustainable Enterprise Architecture function.
Capgemini uses a practical and proven approach that ensures all key ingredients
are in place to facilitate return on investment to meet strategic business and IT
goals for an organization. The approach is iterative to ensure that the right balance
is struck between investment in capability development, strategic needs of the
business and capacity of an organization to embrace Enterprise Architecture as a
professional discipline. It comprises the following phases:
n
Define
n
Design
n
Setup and Establish
n
Test (Value)
n
Implement and Embed
n
Refine and Evolve
The work is framework independent with one of the activities being selection
and customization of the most appropriate framework. However, use of
Capgeminis IAF as the framework (or the basis) offers many advantages to
organizations building such a capability. It offers a proven, comprehensive and
coherent framework complete with supporting material and training.
More details on the approach can be found in a separate Thought Leadership
paper Enterprise Architecture, developing the capability to deliver value.
Framework,
Method & Tools
Capability &
Competency
Enterprise
Architecture
Strategy
Architecture
Content
Governance
& Assurance
Community
& Culture
Figure 9. Enterprise Architecture Capability
28

Capgeminis architecture capability is delivered throughout the world by
experienced professionals across the organization. A global Community of
Practice, formed at the very start of IAF development, supports individuals and
remains at the core of the capability to support its evolution.
At the time of writing, the worldwide organization has around 1000 professionals
delivering architecture services as experienced Business or IT specialists. The
Global Architecture Community numbers some 1500 active members, including
senior designers and engineers as well as technical specialists. This Community is
supported by comprehensive knowledge and collaboration tools.
The Community represents a vast amount of experience and knowledge, both
through technology as well as a global network of people who share experiences
with each other as well as delivering benefit to clients. Regular Architects Week
(A-Week) events delivering the Architecture Learning Program allow networks to
be built and refreshed.
The Community also owns and undertakes development of the approach (IAF) as
well as training and certification programs. This ensures that the framework and
supporting training and certification evolve in line with the real world. An elected
Community Council facilitates the latter, providing necessary governance and
prioritization.
The Architecture Learning Programme (ALP) and Capgemini Architects
Certification Programme are a critical part of Capgeminis support for the
Architects profession.
9.1 Architects Certification
Certification for Architects was launched within Capgemini in 1998. This
program is based on candidates demonstrating their architecture capabilities, their
experience of delivering architecture and knowledge and experience of IAF.
Capgemini is also working closely with organizations, including The Open Group
and Microsoft, who have themselves launched industry Certification programs for
IT Architects. The specific schemes launched are The Open Group IT Architect
Certification (ITAC) and Microsoft Certified Architect (MCA).
Investment in these training and certification programs is clear evidence of the
importance of architecture to Capgemini.
9. Supporting and
Developing the Capability
within Capgemini
9.2 Architects Training
The Architects Learning Programme (ALP) is the premier program for architects
in Capgemini and is designed to nurture professionalism amongst those with no
architecture experience as well as experienced architects looking to sharpen their
skills and adopt best practice:
Development and delivery (facilitation) of the material is undertaken by
experienced Capgemini Architects, bringing their knowledge and experience of
real-world projects into the material and the classroom.
Training is run around six times a year at the Capgemini University near Paris,
as part of a week-long training event, A-Week, attended by professionals from
across the group (often over 16 nationalities). Additional events are run in North
America and India.
Since the inception of training at the University, around 55 A-Weeks have been
run worldwide, which together with specific courses run at country levels, have
reached over 2,500 attendees.
Courses can be customized and delivered to clients who have already adopted IAF
as their framework.
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 29
ServiceOriented Architecture the way we see it
Figure 10. Architecture Learning Program
IAF Advanced
Business & Info
IAF Advanced
IS & TI IAF Refresher
(e-Learning)
IAF Essentials
Architecture
Awareness
(e-Learning)
Experienced
Architects
Capgemini
Professionals Advanced Master
Architecture
Master Class
EA Capability
Development

ServiceOriented Architecture the way we see it
30

9.3 Ongoing Development
The overall development approach for IAF and the ALP is based on a
Community Development Model, tapping into the members of the Architects
Community worldwide to incorporate feedback and real-world experience from
clients.
The Integrated Architecture Framework was updated to IAF 4.0, and the
Architecture Learning Programme courses were refreshed during 2006.
At the same time, Capgemini is actively engaging with industry bodies like The
Open Group and OASIS (the Organization for the Advancement of Structured
Information Standards) to share best practice and lessons learned from thousands
of man-years of experience across the Capgemini community.
Enterprise, Business and IT Architecture and the Integrated Architecture Framework 31
ServiceOriented Architecture the way we see it
During the evolution of IAF, and various other industry standards, many areas
have converged in terms of overall positioning. IAF is compatible with The
Open Group Architecture Framework (TOGAF) and with IEEE 1471-2000
Recommended Practice for Architectural Description of Software-Intensive Systems.
As an example, the following key definitions are taken directly from TOGAF
version 8.1, Developing Architecture Views (Introduction):
The architecture of a system is the systems fundamental organization, embodied in its
components, their relationships to each other and to the environment, and the principles
guiding its design and evolution.
A view is a representation of a whole system from the perspective of a related set
of concerns.
Both of these key definitions are compatible with the use of these terms within
IAF, especially when you consider system to cover both Business and IT
systems. It is also worth noting that both of these definitions are based on, and
compatible with those definitions in IEEE 1471-2000.
In looking at TOGAF it is clear that it provides best practice around the
organization and processes required for an Enterprise Architecture function within
an organization, but does not restrict the architecture models and language to be
applied. This allows organizations to select a model that is most appropriate for
their business.
IAF itself provides a complete and consistent way to describe the architecture,
which is applied for different clients and in different contexts using the relevant
Engagement Roadmap. TOGAF can be used as the basis for the process and
organization for an architecture function (providing the Engagement Roadmap
for IAF) with IAF providing the architectural models and language.
The Open Group has formally accepted IAF as a recognized method within its
IT Architect Certification (ITAC) program.
10. IAF, TOGAF and IEEE
1471-2000
32
Since 1993, Capgemini has been using Business and IT Architecture to help reduce
project risk, improve Business/IT Alignment and add value to client businesses.
Architecture is all about the business: even for IT-centric projects, the solution
must deliver business value and be clearly aligned to the business direction if it is
to be successful. For architecture to be able to deliver this, all decisions must be
clearly justified and traceable to business needs.
The Integrated Architecture Framework (IAF), underpinned by the Architects
Learning Programme, Capgeminis Architects Community and Architects
Certification Programme, provides the foundation on which architecture is
delivered by Capgemini.
The Integrated Architecture Framework is also successfully deployed in a number
of major client organizations, as part of their architecture capability, and offers
these advantages to the client organization.
Further information on the organisations, frameworks and certification schemes
mentioned in this document can found on the Internet using the following links
(correct at the time of publication):
n
IEEE 1471-2000
http://www.ieee.org
n
The Open Group
http://www.opengroup.org
n
The Open Group Architecture Framework (TOGAF)
http://www.opengroup.org/togaf
n
Zachman Framework for Enterprise Architecture
http://www.zifa.com
n
The Open Groups IT Architect Certification (ITAC)
http://www.opengroup.org/itac
n
Microsofts Certified Architect (MCA)
http://www.microsoft.com/learning/mcp/architect
n
Organization for the Advancement of Structured Information Standards
http://www.oasis-open.org
11. Summary
32

S
O
A
2
0
0
7
0
5
3
0
_
1
5
2
Copyright 2007 Capgemini. All rights reserved.
Disclaimer
All advice given and statements and recommendations made in this document are:
1. Provided in good faith on the basis of information provided by you, third parties
and/or otherwise generally available or known to Capgemini at the time of writing.
2. Made strictly on the basis that in no circumstances shall they constitute or be
deemed to constitute a warranty by Capgemini as to their accuracy or completeness.
Capgemini shall not be liable for any loss, expense, damage or claim arising out of, or
in connection with the making of them in this document or for any omission from them.
3. The information contained within this document is and shall remain the property
of Capgemini. This White Paper is supplied in strict confidence and must not be
reproduced in whole or in part, used in tendering or for manufacturing purposes or
given or communicated to any third party without the prior consent of Capgemini.
Capgemini, one of
the worlds foremost
providers of Consulting, Technology and
Outsourcing services, has a unique way
of working with its clients, called the
Collaborative Business Experience.
Backed by over three decades of industry
and service experience, the Collaborative
Business Experience is designed to
help our clients achieve better, faster,
more sustainable results through
seamless access to our network of
world-leading technology partners and
collaboration-focused methods and tools.
Through commitment to mutual success
and the achievement of tangible value,
we help businesses implement growth
strategies, leverage technology, and thrive
through the power of collaboration.
Capgemini employs approximately
68,000 people worldwide and reported
2006 global revenues of 7.7 billion euros.
More information about our services,
offices and research is available
at www.capgemini.com.
About Capgemini and the
Collaborative Business Experience
www.capgemini.com/soa
France
Coeur Dfense Tour A110
esplanade du Gnral de Gaulle
92931 Paris La Dfense
+33 (0)1 49 67 30 00
Germany
Berliner Strae 76
D-63065 Offenbach am Main
+49 (0) 69 95 150
Netherlands
Papendorpseweg 100
3528 BJ Utrecht
Postbus 2575
3500 GN Utrecht
+31 30 689 00 00
United Kingdom
76-88 Wardour Street
London W1F 0UU
+44 870 238 8779
United States
750, 7th Avenue
New York, NY 10019
+1 917 934 8402