An Introduction to Fundamental

Architecture Concepts

Warren Weinmeyer
Warren Weinmeyer
March, 2013

May 2012

Updated: Sept. 2014

Updated: Oct. 2015

Usage and Attribution

You are free and welcome to use and apply the
information in this slide deck, including the copying
of any diagrams and text
I would appreciate, but not require, an acknowledgement
should you do so

To Avoid Confusion: This deck is not about Building Architecture

This deck is for you if any of the following search terms are of
relevance:

IT Architecture

Enterprise Architecture

Business Architecture

Physical Architecture

This deck is likely to disappoint you if any of the following search

terms are of relevance:

City Planning

High-rise construction

BIM

Building massing and sizing

Who am I?

I have 30 years of experience in a variety of industries (manufacturing,

transportation, energy, finance, retail, entertainment, utilities and
government), mostly in large, complex projects.

Ive worked in high-tech startups and multi-national corporations

Ive been working as an Architect for about 15 years, and am certified

(some might say, certifiable!).

I have built or re-built Architecture Practices at two reasonably large

corporations, and consulted on practice improvements at others.

My philosophy on Architecture is that it needs to be holistic, and that

one should leverage best practices instead of home-baking everything
from scratch.

This philosophy has evolved from my repeated observation that managers

who create a fragmented Architecture Practice that is not embedded into
everyday corporate processes, and Architects who ignore the great work
that is already out there, are two common causes for failure of an
Architecture Practice.

Contents
Architecture vs. Design
Architectural Abstraction
Viewpoints and Views
Standard Architecture Domains
Standard Architecture Tiers
TOGAF and Continuous Improvement
Integrating Architecture into the Annual Cycle
Integrating Architecture into Projects

Standardization of Architecture Definitions

There is little in the way of universal agreement on
rigorous definitions of:

Architecture vs. Design

Conceptual/Logical/Physical Architecture
To make it more complicated, these ideas exist on gradients
with lots of grey areas

Theres better agreement on tiers of architecture

Also better agreement on standard architecture
domains
Its important to standardize definitions to create a
coherent framework that will help achieve
consistency in quality and in format for architectural
artifacts
6

Architecture vs. Design

DEFINITIONS:
Architecture:
The fundamental organization of a system, embodied in its components, their relationships
to each other and the environment, and the principles governing its design and evolution.
(ANSI/IEEE 1471-2000)
A representation of a system in which there is a mapping of functionality onto hardware and
software components, a mapping of the software architecture onto the hardware
architecture, and human interaction with these components.
(Carnegie Mellon University's Software Engineering Institute)
An architecture is the most important, pervasive, top-level, strategic inventions, decisions,
and their associated rationales about the overall structure (i.e., essential elements and their
relationships) and associated characteristics and behavior. (OPEN Process Framework)
A description of the design and contents of a computer system. If documented, it may
include information such as a detailed inventory of current hardware, software and
networking capabilities; a description of long-range plans and priorities for future
purchases, and a plan for upgrading and/or replacing dated equipment and software.
(National Center for Education Statistics).
The structure of components, their interrelationships, and the principles and guidelines
governing their design and evolution over time. (TOGAF)
In the end, architecture boils down to whatever the important stuff is Martin Fowler

DEFINITIONS:
Design:
Realization of a concept or idea into a configuration, drawing, model,
mould, pattern, plan or specification (on which the actual or commercial
production of an item is based) and which helps achieve the item's
designated objective(s). (BusinessDictionary.com)
A specification or plan for making a particular artifact or for undertaking
a particular activity. A design is the basis for, and precursor to, the
making of an artifact. (Terence Love, 2002)
The process of refining and expanding the preliminary design phase
(i.e. the architecture) of a system or component to the extent that the
design is sufficiently complete to be implemented. (IEEE Standard
Glossary of Software Engineering Terminology)

Architecture vs. Design

Most agree that theres a difference between architecture and design

Both talk about specification, but to different degrees: a detailed
Architecture specification can be implemented in more than one way,
but a detailed design cant.
A design (that complies with the Architecture) is therefore required
to proceed to implementation
Contextdependent

Architecture
More Abstract

Abstraction Continuum

Design
More Concrete

Architecture applies analysis along dimensions that Design usually does

not:
organizational/technical/legal risks, impacts and dependencies
future-state projections (transitional solutions, roadmaps),
deviations from Strategy or standards
solution qualities (scalability, reliability, )
etc.

Architecture addresses alignment, construction, deployment, operational

and retirement aspects of a solution; Design often is just about
construction.
10

Architecture: Know When to Stop!

The deficiencies of under-architecting are fairly obvious:

the architecture description is fundamentally not useful
and serves only as a checkbox on some stage-gate.
the Architecture team can become irrelevant

The deficiencies of over-architecting are more subtle but no

less important:
over-specification impedes project velocity, adds too
much overhead
reduces the availability of the Architect to other initiatives
the resulting architecture description is more difficult to
re-use
it adds avoidable cost: Architects are more expensive
it can spark resentment from other team members who
are deprived of meaningful design influence
11

Attributes of a good Architecture Description

Provides enough detail to:

describe the salient properties of the solution
describe the salient technical and organizational risks,
impacts and inter-dependencies
confirm that any compliant solution fulfills the salient
Business (functional) and Technical (non-functional)
requirements
give designers real guidance to specify a compliant
solution

Provides analysis and context that addresses the concerns of

all stakeholders

Can be physically implemented in more than 1 way (i.e. is not

tied down to a single solution specification): is NOT directly
implementable
12

What is Salient?
It depends!
this is one reason why an Architect is a senior
role
what is salient is based on the concerns of the
stakeholders, the greater picture of the current
and future state of the organizational and
technical environment, the need to deliver
actionable guidance, etc.
Over-specification is a result of the Architect
performing design work by virtue of not making
good decisions about what is salient.

13

Example: Physical Architecture vs. Design

Examples:

A Physical Architecture

In this example, the

architect decided the
following were salient:
The Windows version of the
application-hosting servers
is specified because it is a
product dependency and is
therefore architecturally
significant.
SQL Server is specified
because it the mandated
standard.
Also, SQL Server is specified
as 64-bit due to identified
processing bandwidth
requirements, as well as in a
cluster due to reliability
requirements: these are
architecturally significant.

14

Example: Physical Architecture vs. Design

A Design that is
Compliant to the
Physical Architecture
In this example, the
designer decided the
following were salient:
Many of the servers are
specified to be VMs running
in the corporate VM pool,
with a specified amount of
dedicated compute capacity.
The version/release of all
technical software
components is specified.
The required drive mappings
and drive sizes are
indicated, as are DNS
names.
Infrastructure hardware like
the load balancer that is
explicitly part of the solution
is specified, while the rest,
like switches and firewalls,
are not.
15

Architectural Abstraction

16

DEFINITIONS:

Conceptual Architecture:

shows of a set of relationships between factors that are believed to impact or lead
to a target condition; a diagram that defines theoretical entities, objects, or
conditions of a system and the relationships between them. (Dictionary.com)

represents 'concepts' (entities) and relationships between themaim is to express

the meaning of terms and concepts used by domain experts to discuss the
problem, and to find the correct relationships between different concepts.
(Wikipedia.com)

Logical Architecture:

logical relationships between the resources, activities, outputs and outcomes of a

program the underlying purpose is to assess the causal relationships between
the elements of the program. (Wikipedia.com)

Logical architecture addresses the information system seen macroscopically, by

focusing on its main components, their interconnections and the flows exchanged,
and by structuring them by group into larger-scale modules. (Softeam)

Physical Architecture:

details network capabilities, server specifications, hardware requirements and

other information related to deploying the proposed system. (Sparx)

17

Conceptual vs. Logical vs. Physical Architecture

Conceptual, Logical, and Physical representations
are the most common layers of architectural
abstraction
Conceptual

More Abstract

Logical

Physical

Architecture Abstraction Continuum

More Concrete

Conceptual Architecture is the highest level of

abstraction, and often does not get very detailed
Logical Architecture applies to a wide range of
abstraction levels between Conceptual and Physical
and can be very detailed
Physical Architecture is the least abstract
representation and typically is very detailed
18

Conceptual Architecture

Conceptual architecture diagrams are static (structural) models

The focus is on the relationship of the concepts central to the topic, not
on how things work

that is the fundamental differentiator of a Conceptual model from a high-level

Logical model.
If arrows or connectors are shown in a Conceptual model, it is only to show
which conceptual entities are related to each other, never to show sequence
or process flow.

Typically, the intent is to provide a 1-page visual introduction to the

topic, though multi-level and more detailed models are possible.

APQC, Capability Models and similar structural models are Conceptual

Some other examples of Conceptual Models:

19

Logical Architecture

Describes how a solution works, in terms of function and logical information.

Can be at a very high level down to a very detailed level

at the highest levels may map essentially 1:1 with the conceptual entities
described in the Conceptual models
at the lowest levels may map essentially 1:1 to physical entities that are
described in the Physical models.

Can show a static view (for example, connectivity) or a dynamic view (for example,
process flow)

The following models describe the same thing, at different levels of Logical detail:

20

Logical Architecture
Example: a detailed logical model that almost maps
1:1 with the corresponding physical model that
realizes the Logical architecture

21

Physical Architecture
Refers to specific products, protocols, and data
representation where/when/if it is architecturally
salient to do so
This is where over-architecting can most easily
occur
Even when specifying real-world products, there
is typically missing information for detailed
design to provide

for example: Product Versions, 32/64-bit,

physical/virtual platform, etc.

22

Mixed Models
Sometimes, it is desirable to create a model that is
not a pure Physical or pure Logical model.
It is ok to do that if its done in a controlled way:
Your Modeling Framework should specify which
models can contain mixed elements

You should standardize the types of models you create

by defining a framework that defines all the models
and how they conceptually relate to each other

If you are not consistent in how you create your

models, then it will make it very difficult for your
repository tool (if you have one) to generate good
analytics from, but it also just in general impedes
understandability of your models.
23

Viewpoints and Views

24

Definitions:

Viewpoints and Views are described in ISO/IEC/IEEE 42010

(previously, 1471-2000 - IEEE Recommended Practice for Architectural
Description for Software-Intensive Systems)
TOGAF complies (essentially) with IEEE
These terms have been around for a long time: the IEEE
description adds rigour to the concepts

A Viewpoint identifies the set of concerns and the

representations/modeling techniques, etc. used to describe the
architecture that addresses those concerns

A View is a concrete description of a specific aspect of the entire

solution
A View is a realization of a (corresponding) Viewpoint

Viewpoint vs. View have a relationship that is analogous to that of

Pattern vs. Implementation, or (perhaps more accurately) Class vs.
Object or (perhaps most accurately) Schema vs. Message

25

Viewpoints

Viewpoints serve to provide the underlying guidance for how to describe an architectural
perspective: they are based on the Architectural Concerns (i.e. interests) of one or more
Stakeholders.

Therefore, Viewpoints ensure that architecture descriptions are geared to their

Stakeholders information needs.

You need multiple Viewpoints to create the complete architectural description

The diagram below shows a portion of the ISO 42010 conceptual model:

An Architecture Description is organized into one or more Views.

Each View is constructed conforming to/governed by a Viewpoint

A Viewpoint addresses an audience (Stakeholders) by framing out specific

information (Concerns) through employing specific models.

26

Viewpoints
IEEE specifies that a viewpoint description
includes:
The Viewpoint name
The stakeholders addressed by the
viewpoint
The architectural concerns framed by the
viewpoint (i.e. the purpose)
The language, or modeling techniques, or
analytical methods used to construct,
depict and analyze the resulting view
Note: the models you use should be
organized into a coherent framework of
models (in this example: TOGAF)

The source, if any, of the viewpoint (e.g.,

author, literature citation)
A viewpoint may optionally include:
Consistency or completeness checks
associated with the underlying method to be
applied to models within the view
Evaluation or analysis techniques to be
applied to models within the view
Heuristics, patterns, or other guidelines
which aid in the synthesis of an associated
view or its models

27

By understanding your Stakeholders and

what their information requirements are (i.e.
their Architectural Concerns), you can
construct a library of pre-defined, re-usable
Viewpoints.

Viewpoint Frameworks

Constructing a library of Viewpoints, however, is not sufficient

to ensure that a resulting set of views properly illustrates all
the architectural characteristics and all the stakeholder
concerns.

It is necessary that the relationships between all the

Viewpoints in the library be defined in a manner that they
aggregate to cover the entire scope of architecture description,
and do not overlap (at least significantly) each other.
This is what is referred to as a Viewpoint Framework.
If the Viewpoints are constructed into a well-structured
framework, then the Views that are generated out of that
Viewpoint framework will describe the architecture of the given
solution in a consistent, coherent and comprehensive manner.
Viewpoint Frameworks increase the velocity, consistency
and quality of the task of creating architecture
descriptions

28

Viewpoint Framework Example

The Viewpoints in a Viewpoint

Framework have well-defined
conceptual relationships with
each other.

As an aggregation, the
Viewpoints in the Framework
cover the entire scope of
architectural concerns from all
the Stakeholders
Note that the Viewpoints
(mostly) fall into the category
of a particular branch of
Architecture (referred to as a
Domain)
Domains are explained
later in this deck

29

View Frameworks

Just as a Viewpoint Framework is a structured set of Viewpoints, a

View Framework is a structured set of Views.
The conceptual relationships between Viewpoints that is the
essence of the Viewpoint framework are identically reflected in
the resulting View framework.

However there is a further difference between a View framework and

a Viewpoint framework aside from abstraction:
the Viewpoint framework encompasses the full suite of
Viewpoints in the library, but the View framework consists only
of the Views that will be constructed for the solution in
question.
As a contrived (not realistic) example
take a very simple Viewpoint framework consisting of a Business
Process, an Infrastructure and a Security viewpoint.
the solution architecture is to simply implement a network.
there is no requirement for a Business Process view so the View
framework for this would not include a Business Process view, even
though there exists a Business Process viewpoint.
30

Standard Architecture
Domains

31

Architecture Overview Architecture Domains

The scope of concerns that Architecture deals with is so broad that we divide it into
different categories, typically called domains but it is all Architecture: if you are not
considering the full scope of domains, it is questionable whether you are actually doing
Architecture!

A commonly-referenced framework
of architectural domains is:
Business
Architecture:
Vision, Strategy,
Objectives, Processes,
Principles, Capabilities,
Actors, Use Cases,
Application
Organization, etc.
Architecture:

Business
Architect
ure
Applicati
on
Architect
ure
Technical
Architect
ure

Informati
on
Architect
ure

Systems, Applications,
Services, Protocols,
Messages, Interfaces,
Data/Information
Transactions, etc.

Architecture:

Information Entities,
Ontologies, Taxonomies, Data
Relationships,
Technical Schemas, etc.

Architecture:

Note: this visualization was adapted from the Software

AG/IDS Scheer ARIS manualso thanks, ARIS!

32

Network, Servers,
Storage,
Communications,
Platforms, etc.

DEFINITIONS:
Business Architecture:
Graphical representation of a business model, showing the networks through
which authority, information, and work flows in a firm. It serves as the blueprint
of a firm's business structure, and clarifies how the firm's activities and policies
will affect its defined objectives. (BusinessDictionary.com)
The practice of creating a design to satisfy an organizations strategic and tactical
directives by providing an enterprise-wide, holistic business view, and identifying
and monitoring both internal and external impacting factors and
interdependencies. (Business Architects Association)
A blueprint of the enterprise that provides a common understanding of the
organization and is used to align strategic objectives and tactical demands. (OMG
Business Architecture Special Interest Group (BASIG))
A description of the structure and interaction between the business strategy,
organization, functions, business processes, and information needs. (TOGAF)
The structure and behavior of a business system (not necessarily related to
computers). Covers business goals, business functions or capabilities, business
processes and roles etc. Business functions and business processes are often
mapped to the applications and data they need. (Wikipedia)
33

DEFINITIONS:
Application Architecture:
Application architecture is the organizational design of an entire software
application, including all sub-components and external applications interchanges.
(wiseGeek.com)
A description of the structure and interaction of the applications as groups of
capabilities that provide key business functions and manage the data assets.
(TOGAF)
The structure and behavior of applications used in a business, focused on how
they interact with each other and with users. Focused on the data consumed and
produced by applications rather than their internal structure. In application
portfolio management, the applications are usually mapped to business functions
and to application platform technologies. (Wikipedia)

34

DEFINITIONS:
Data/Information Architecture:
The data structures used by a business and/or its applications. Descriptions of
data in storage and data in motion. Descriptions of data stores, data groups and
data items. Mappings of those data artifacts to data qualities, applications,
locations etc. (Wikipedia)
A description of the structure and interaction of the enterprises major types and
sources of data, logical data assets, physical data assets, and data management
resources. (TOGAF)
Information Architecture is about organizing and simplifying information,
designing and integrating information spaces/systems, and creating ways for
people to find and interact with information content. Its goal is to help people
understand and manage information and make right decisions accordingly. (Wei
Ding, Xia Lin Information Architecture)
Set of rules that determine what, and how and where, information will be
collected, stored, processed, transmitted, presented, and used.
(BusinessDictionary.com)

35

DEFINITIONS:
Technical/Technology Architecture:
A description of the structure and interaction of the platform services, and logical
and physical technology components. (TOGAF)
The structure and behavior of the technology infrastructure. Covers the client
and server nodes of the hardware configuration, the infrastructure applications
that run on them, the infrastructure services they offer to applications, the
protocols and networks that connect applications and nodes. (Wikipedia)

36

Standard Architecture
Tiers

37

Architecture Overview Architecture Tiers

Organizational
Scope

Scope of Problem Domain

Technology Horizon

Enterprise Architecture

The industry recognizes 3

general tiers of architecture.
These can be visualized using a
grid of Problem Domain scope,
Technology Horizon (depth of
technology, and Organizational
scope
Enterprise Architecture (EA)
looks at the goals, opportunities
and challenges facing the
company, and seeks to propose
solutions that can holistically
improve the enterprise.
EA takes a strategic, inclusive
and long-term view, thinking in
terms
of
the
enterprise,
Capabilities, Business Processes
and
Services
rather
than
focusing
on
technological
details.

38

Architecture Overview Architecture Tiers

Organizational
Scope

Scope of Problem Domain

A segment can be a Portfolio, a

Line-of-Business, a Capability, a
technology or any other division
that
makes
sense
to
the
company.

Enterprise Architecture
Technology Horizon

Segment Architecture is much

like EA but is applied to a specific
sub-section (segment) of the
enterprise.

Segment
Architecture

Segment Architecture, because

the scope is more focused, takes
a closer look at the technology
and information landscape than at
the enterprise level.

39

Architecture Overview Architecture Tiers

Organizational
Scope

Scope of Problem Domain

Portfolio Architecture can address

technological details to a greater
degree than EA, but does not
have the visibility across the
enterprise that EA does.

Enterprise Architecture
Technology Horizon

Some companies choose to define

their segments by Portfolio, so
use
the
term
Portfolio
Architecture.

Portfolio
Architecture

In some companies, Portfolio

Architecture is just folded into EA,
so each enterprise architect is
assigned a portfolio to manage.

Portfolio Architecture = Segment Architecture

40

Portfolio Architecture in many

ways is Enterprise Architecture
within a constrained boundary,
but with more exposure to
technology specifics.

Architecture Overview Architecture Tiers

Organizational
Scope

Scope of Problem Domain

Solution Architecture addresses

technological details to the level
required to ensure the resulting
solution is compliant in all
relevant ways (the rest is part of
Detailed Design).

Enterprise Architecture
Technology Horizon

Solution Architecture is focused

on a specific solution and is
concerned with compliance to
standards, roadmaps and greater
strategic objectives, in addition to
finding a solid solution.

Portfolio
Architecture

Unlike
EA
and
Portfolio
Architecture,
which
are
continuous activities, the activity
of
Solution
Architecture
is
typically tied to a project lifecycle
or delivery of some similar work
product.

Solution
Architecture

41

All Architecture Domains are addressed at every Tier

Organizational
Scope

Scope of Problem Domain

Technology Horizon

Enterprise Architecture

Each of these 3 tiers of

architecture
(Enterprise,
Portfolio,
and
Solution)
include all four architectural
domains
(i.e.,
Business,
Application, Information, and
Technical Architecture) but
they do so based on their
different scopes of mandate.
Project Architects operate in a niche
and can be brought into a project
under the oversight of the Solution
Architect in order to provide specialist
expertise or to lighten the workload
of the SA.

Portfolio
Architecture

Solution
Architecture
Project
Etc.
Project
Project Project
Project
Project
Business Information Application Technical Integration Data
Architect Architect
Architect Architect Architect Architect

42

Often, a lead programmer or

technical specialist is actually whats
required, not a specialist architect.

Tiers and Domains does NOT mean Silos!

Organizational
Scope

Scope of Problem Domain

The
actual
process
of
Architecture is continuous and
holistic
across
Tiers
and
Domains it is a continuousimprovement lifecycle.

Enterprise Architecture
Technology Horizon

These divisions are simply

tools to understand where and
how to apply architectural
discipline, and to break down
the challenge into parts that
are easier to grasp.

If EA strategic roadmaps do
not
see
realization
in
operational solutions, then
EA is irrelevant, and SA is at
best an incremental valueadd.

Portfolio
Architecture

Solution
Architecture

43

Breaking up EA, PA, and SA

into silos (which many
companies do) is contrary to
the whole value proposition
of Architecture for spanning
silos.

TOGAF and Continuous

Improvement

44

TOGAF as a Modified Deming Cycle

Are the results

netting the expected
benefits?

Are we doing
the right things?

The Deming Cycle is an iterative

process
(originating
in
the
manufacturing sector) for quality
management
and
continuous
improvement.
It consists of 4 steps:
Plan: Establish objectives
Do: Implement the plan

Deming
Cycle

Check: Study the results

Act: Adjust to bring results in line with
objectives

Are we getting
the expected
results?

Are we doing
things right?

TOGAF also is based on a continuous

improvement lifecycle

45

TOGAF as a Modified Deming Cycle

Here is a diagram of TOGAFs
ADM (architecture development
method). Colour-coding is used
to map TOGAF stages to
Deming Cycle steps.
Quality control and continuous
improvement entails:
iterating and going back to
previous
steps
when
necessary
constant
cross-references
between
Requirements as
they
evolve
versus
the
architecture specifications as
they evolve.
assessing gaps, redundancies
and performance of delivered
architectures
defining future states with
capability maturity models
and roadmaps,
transitional architectures to
guide progress to the future
state.
46

Integrating Architecture
into the Annual
Corporate Cycle

47

The Basic Annual Corporate Cycle

Most companies tend to
keep to a traditional,
fundamental
annual
rhythm that has 3 basic
phases:
Planning
for
the
upcoming year
Executing projects that
were identified in the
planning stage
Maintaining/operating
the changes delivered
as project outcomes
Includes the monitoring,
operating and supporting
of systems

48

The Basic Cycle Exists at Multiple Corporate Levels

Strategy
Capture
/Review

Demand
Mgmt.

IT Roadmapping
Project
Portfolio
Mgmt.

i
IT
izat
n
a
Org
Help
Change
Desk n
o
Mgmt.

IT
olio
f
t
Technolo
r
gy Po
Land

Service
Strategy
Capture

Service
Support

Program
Mgmt.

Master
Data
Mgmt.

O pp o
rt
Iden unity
tif
catio in

Service
Roadmapping

IT
v ic e
r
e
S

Operations

49

Change
Mgmt.

At the Organization Level:

Involves
strategically
prioritizing
and
sequencing Business demand
Governance
of
delivery
and
change
management
Centralized Help Desk function

At the Portfolio Level:

Capability
Planning

Portfolio
Strategy
Capture

scape
Mgmt.

The basic annual cycle discussed in the

previous slide can be seen expressed at
various levels throughout the corporation:

Project
Mgmt.

Involves identifying and planning strategic

capability enhancements
Management and synchronization of projects
impacting the portfolio technical landscape
Identifying capability gaps and redundancies
in the technical landscape of the portfolio
Managing the portfolio information landscape

At the Service Level:

Involves identifying and planning service
improvements
Managing delivery projects
Managing the introduction of new solutions
into the technical landscape
Operating,
monitoring,
supporting
and
maintaining solutions

Architecture is Continuous Across Organization Levels

Por
io

tfol

Demand
Mgmt.
IT Roadmapping

Strategy
Capture /
Review

Project
Portfolio
Mgmt.

Help
Desk

Change
Mgmt.

ol
f
t
r
Po
io

Capability
Planning

Portfolio
Strategy
Capture

Program
Mgmt.
Master
Data
Mgmt.

Service
Strategy

Opportunity
Identification Service
Roadmapping
Project
Mgmt.

Serv
ice
Ope
rati
ons

Or
g.

tf
Por
io

vi
Ser
ce

ic
v
r
Se
e

Architecture integrates into the basic Corporate cycles at each level of the
organization, and helps to provide a vertical backbone of integration
between levels. The next slide shows more explicitly exactly how
Architecture acts as an agent of integration across organization levels.

50

ol

The process of Architecture is a

holistic and continuous integration of
EA
(Enterprise
Architecture),
PA
(Portfolio/Segment Architecture) and
SA (Solution Architecture):
At the Organization level:

Architecture is practiced through

EA involvement in strategic issues,
such as the business priorities,
prioritization of investments across
Portfolios, architectural governance
(i.e.,
standards,
architectural
patterns, and compliance) and
future-state visioning/planning

At the Portfolio/segment level:

Architecture is practiced through PA

involvement in strategic issues such
as portfolio management, portfolio
road-mapping, capability planning
and
project
opportunity
identification, in alignment with EA
planning and prioritization.

At the Service level:

Architecture is practiced through

Solution Architecture within service
delivery projects, which themselves
produce solutions that operate
within the managed Portfolios that
requested the projects.

Integrating Architecture
into Projects

51

Architecture Engagement Across the Project Lifecycle

Architecture, executed
holistically at the EA,
PA and SA tiers, is
involved
in
the
complete lifecycle of
an idea, right from
strategic
planning
through
realization
and assessment of the
operating state, and
back
again
to
strategic planning.
EA
activities
(are
baked
right
into
corporate processes)
spawn PA activities
(which are baked right
into
portfolio
processes) spawn SA
activities (which are
baked into project
processes).
vi
Ser
ce
tfol
Por
io

.
Org

EA = Enterprise Architecture/Enterprise Architect

PA = Portfolio Architecture/Portfolio Architect
SA = Solution Architecture/Solution Architect

52

Here is a closer look at some of the Architectural Inputs for a Project

Projec (Dema
t
Incepti
nd
Portfolio,
Investment
Phase Planni
on
Theme and
Program
strategic
ng)
roadmaps
Strategic
Roadmap
Portfolio
Architect

Business
Case

Tactical
Roadmap

Portfolio
application
roadmap(s)

Project
Charter

PA provides
complexity & tech
assessment
content, reads final
doc: this ensures
early visibility into
the approved
project

Conceptual & high-level

Logical solution architecture
is required before starting
an RFx, performing System
Selection, or beginning
detailed architecture and
design

Solution
Architect

Legend
Architectural inputs
Architectural deliverable

Elaborat
ion

Construct
ion
Design

Analyze

& Build

PA provides Architect FTE

estimate for budgeting, and
provides tasks & work
estimates for scheduling
Requires nonfunctional
requirements,
Conceptual and
high-level Logical
architecture to be
completed

Non-funct
Requirmts

Requires nonfunctional
requirements,
Conceptual and
high-level Logical
architecture to be
completed

RFx

Detailed
Logical
architectur
e and
physical
architectur
e; may be
done in
iterations
for agile
projects

Detailed Detailed
Non-funct Soln Arch
Requirmts

Test Chg
SA Mgmt
reviews

Test Deploymt
Plan Plan

Depending on SDLC,
may iterate as far as
development
milestones or all the
way to incremental
deploytments
deployments

Warranty

SA provides
technology
retirement,
resource
reclamation and
information
SA provides
disposition plans
cut-over
plan,
including
data
migration

Transition
Plan

Operational
Support
Model
Iterations
or Sprints

An Architect
53 creates
this

Deploy

development
team test
plans,
contributes
nonfunctionalSA
test plans
provides
backup,
technical
deployme
nt and
rollback
plans

Conceptual
System
& Logical
Selectn
Soln Arch

An Architect contributes to
this

Transiti
on
Support &

Retirement
Plan
This is the
Support
Sustainme
nt bible

Key Take-Aways
Architecture in practice is a holistic endeavour of continuous improvement that is both
broad and deep:
Architecture Domains (Business Architecture, Application Architecture, Information
Architecture, Technical Architecture) and Architecture Tiers (Enterprise Architecture,
Portfolio Architecture, Solution Architecture) are simply a way to overlay conceptual
columns and rows against this broad topic to allow us to artificially subdivide it and get
our heads around it. But we must NEVER actually practice Architecture in
deconstructed isolation like that.
Views are slices of the complete architectural description, oriented to a specific
stakeholder audience.
Views contain artefacts (models, diagrams, tables, etc.) and narrative text to address
specific Stakeholders architectural Concerns.

The models in a View may be Conceptual, Logical or Physical (or a controlled mix), depending on
how preliminary or high-level the architectural perspective is:
Models developed during Enterprise Architecture or Portfolio Architecture, or during the
earlier stages of Solution Architecture are likely to be Conceptual and non-detailed Logical
models
Models developed during later stages of Solution Architecture are likely to be detailed
Logical and Physical models.

You need multiple Views to create a complete architectural description (to cover all the
Concerns of all the Stakeholders)

Viewpoints are the schema that specify what a View that realizes that Viewpoint must
contain
You should structure your Viewpoints into a framework to minimize redundant overlap
between them while ensuring that the entire scope of stakeholder architectural
concerns are addressed.
54

I hope you have found this instructional

slide deck of some use in your research to
better understand the modern practice of
Architecture!

55