An Introduction To Fundamental Architecture Concepts

An Introduction to Fundamental
Architecture Concepts
Warren Weinmeyer
Updated: May 2023

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 over 30 years of experience in a variety of industries
(manufacturing, transportation, energy, finance, retail, entertainment,
utilities and government), mostly in large, complex projects.
• I’ve worked in high-tech startups and multi-national corporations
• I’ve been working across the Architecture space for about 20 years
• 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 are ignorant of the great
leading practices that are out there, are two common causes for failure of
an Architecture Practice.

Contents
• Architecture vs. Design
• Architecture Models vs Diagrams
• Architectural Abstraction
• Viewpoints and Views
• Architecture as a Unified Concept
• Standard Architecture Domains
• Standard Architecture Tiers (Levels)
• TOGAF and Continuous Improvement
• Integrating Architecture into the Greater Corporate
Processes
• Integrating Architecture into Projects
5

Standardization of Architecture Definitions
• Architecture has long had a problem of consistency in the definition of
foundational concepts: this is a natural result of having many different
“authoritative” voices coming from many backgrounds
• To make it more complicated, many of these ideas exist on gradients (i.e.
within a spectrum or continuum) with lots of “grey areas” of overlap
• However, there’s better agreement on certain topics, such as tiers of
architecture or the standard architecture domains
• It’s important in your Practice to standardize definitions to create a
coherent framework that will help achieve consistency in quality and
in format for architectural work and products
• This document adopts the current state-of-the-art thinking from
influential thought-leaders (complemented by published references for
certain topics) into an easily-consumable, consistent and coherent
conceptual framework
• This is a living document and I update it regularly (typically once or
twice a year)
6

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
8

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)
9

Architecture vs. Design
• Most agree that there’s a difference between architecture and design
• Both talk about specification, but to different degrees: an Architecture
specification can be implemented in more than one way, but a detailed
design can’t.
• A design (that complies with the Architecture) is therefore required
to proceed to implementation
• 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
More Abstract More Concrete
Abstraction Continuum
Architecture Detailed Design
Context-
dependent

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

Summary: Arch vs Detailed Design
14
Note: Thanks to Pele Williams, PhD, who contributed this tabularized Summary

15
Architecture Models vs
Diagrams

Models/Diagrams - The Essential Difference
• The terms “model” and “diagram” are often used interchangeably, but there are
times when the differences are important.
• While a Diagram is a drawing, a Model is a representation that must follow
formal rules of association between the elements.
• These rules are called a metamodel, and are the foundation of
architecture modeling: every good framework has a metamodel
• The metamodel ensures that any models that are created based on its rules
provide accurate information in a repeatable and reliable manner
• An analogy: databases.
• Every database has a schema that all the data entities must comply to.
• The schema serves to ensure that all the data relationships are properly
observed, so that you can get accurate information and reporting out
from the database, in a repeatable and reliable manner.
• One other difference: a Diagram is always a drawing, but while a Model is often
a drawing, it could be represented in other forms, such as a table.
• Note: As with many words, you will find variation in how “diagram” and “model” are
defined, especially in the vocabulary of various products. Sometimes “model” is used to
describe the underlying data and relations, and the representations of the data and relations
is called a diagram, view or viewpoint. In these cases, you just have to roll with it.
16

Example: Metamodel and Model
• Here is a look at part of TOGAF’s metamodel:
17
• Here is a visual model that is compliant to the above metamodel:
• Note the application of rules:
• An Actor or Role can only be connected to a
Process via a Function.
• An Actor *could* be connected to a Function
(see the light, thin line in the metamodel) but
the recommended way is via a Role.
• A Function and a Product could be connected
to the Organizational Unit but it wasn’t
important for this model, so the architect left
it out

Model or Diagram – How To Choose?
• The primary guideline is: use the right tool for the job, and this
applies to model vs diagram.
• If a model would be too difficult for your audience to understand,
but a diagram would be consumable, choose the diagram
• If you are creating an architectural document (or similar
specification-oriented content), such as a Solution Architecture
Description, then the majority of your drawings should be
models, and supplement with diagrams only if needed
• If your company has an EA tool that supports model-making then you
should maximize creating models, because each model contributes
real and reusable data into the enterprise repository, while the
knowledge embedded in a diagram is trapped in that diagram.
• Many companies just use something like Visio instead of an EA tool:
there is still great value in developing and adhering to a metamodel to
guide model creation: you will get consistently better quality results.
• You will also be in a position to import all those Visio models into
a modeling tool in the future, should you upgrade.
• Remember: it’s still a model, even if you just used Visio
18

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 them…aim 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)
20

Conceptual vs. Logical vs. Physical Architecture
• Conceptual, Logical, and Physical representations
are the most common layers of architectural
abstraction
• 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
21
More Abstract More Concrete
Architecture Abstraction Continuum
Conceptual Physical
Logical

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:
22

• Here’s a typical example of a conceptual solution model. Notice the flows
indicate relationships not processing sequence or data flow:
23

• .
24
• Here’s an example of a
conceptual model for
enterprise reporting and
analytics
• Notice the architect chose
to express the elements of
the conceptual model in
terms of Capabilities
(from the enterprise
Capability Model)
• You don’t have to use
Capabilities but this is a
great way to tie
solution architecture
into the strategic
elements of the
enterprise architecture

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)
• Below, is a detailed logical model that maps almost 1:1 with a physical architecture
model that would implement it
• As discussed, logical models can span a range from high-level to detailed.
25

• This is also a logical model
of enterprise reporting and
analytics but instead of
reusing the Capabilities
from the conceptual model,
I created logical info
systems (applications) to
reflect the functional steps
in the solution.
• I’m still able to show
traceability back to the
conceptual model by
annotating each logical info
system with the capability
or capabilities that it will
implement.
• You don’t have to do that,
but it’s good to.
• I’ve also added in here
generic supporting infra-
structure that will deliver
or support some of these
logical info systems.
• This version is a little more
“concrete” than the prior
logical model
26
Logical Architecture – High Level Example

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.
• Physical Architecture diagrams are what most non-
Architects are most familiar with: it’s what people think
when you say the term “Architecture Model”
27

28
• Recall that this is where
over-architecting is
most likely to occur,
and the Architect must
concentrate on what is
salient.
• 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.
Example: Physical Architecture

Example: Physical Architecture vs. Design
29
• Here’s the prior slide’s
Physical Architecture
refined into a detailed
design: notice how there
are still design decisions
to be made!
• In this example, the
detail designer (solution
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.

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 it’s done in a controlled way:
• Your Modeling Framework should specify which
models can contain mixed elements
• Modeling Framework: 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 (more on this later in the deck)
• 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.
30

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 (loosely, sort of) 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
• Views are critical: Architecture Concepts are organized
taxonomically by Domains (discussed later), but Architecture
itself marches on the backs of Views
• 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
32

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 metamodel:
• 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.
33

Viewpoints
34
• 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
• 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
• (Full disclosure: the topics of View Frameworks and Viewpoint Frameworks are my own
concept, so you are not likely to find a lot of discussion about them elsewhere)
• 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
35

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
36

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.
37

38
Architecture as a
Unified Concept

• Because Architecture involves
analysis, many organizations regard
Architecture as an exercise in
decomposition.
• As a result, often EA is regarded as a
separate thing entirely from SA, or
Business Architecture a separate thing
from Application Architecture
• This perspective is often at the root of
low-value and poorly-functioning
Architecture Practices
• Architecture provides the most
value when it involves synthesis
and supports corporate processes
from strategy creation at the
highest corporate levels all the way
through to systems and processes.
• Instead of a fragmented exercise in
analysis or decomposition, visualize
Architecture as a continuous three-
dimensional conceptual space
• However, because it is such a large
space, it is still necessary to be able
to focus on specific aspects, and to
enable this, we talk about sub-sets
of Architecture: Domains and Tiers.
39
Architecture is a Large, Continuous Conceptual Space
Stakeholder
Concerns
Technical
Solutions
The Architecture Conceptual Space

40
Standard Architecture
Domains

Architecture Overview – Architecture Domains
• Business Architecture:
Vision, Strategy, Objectives,
Processes, Principles, Capabilities,
Actors, Use Cases, Organization,
etc.
• Application Architecture:
Functions, Systems, Applications,
Services, Protocols, Messages,
Interfaces, Transactions, etc.
• Data/Information Architecture:
Information Entities, Ontologies, Data
Transformation, Data Schemas, Data
Storage, etc.
• Technical Architecture:
Network, Servers, Storage,
Communications, Platforms,
Nodes, etc.
• The scope of concerns that Architecture deals with is so broad that we categorize them
into different “buckets”, typically called Domains. Domains are simply the basic
taxonomical structure of Architecture concepts: the idea is that each concept can get
placed into one of the Domains
• While we categorize Architecture concepts into Domains, we create Architecture
deliverables based on Views
41
Note: this visualization was adapted from the Software
AG/IDS Scheer ARIS manual…so… thanks, Software AG!
A commonly-referenced framework
of architectural domains is:

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 organization’s 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)
42

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)
43

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 enterprise’s 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)
44

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)
45

46
A Short Digression… Security: Domain or View?
• We have described both Views (slides 28-34) and Domains (just now)
in this deck.
• We have described the standard Architecture Domains as Business,
Application, Information, and Technology (also known as BAIT)
• Some organizations include other areas they term domains. For
example, Security Architecture, or Enterprise Architecture.
• Neither of these comply to the definition of Domain being a
foundational category
• Security Architecture consists of elements of process, information,
technology, and people: all of these elements fit into one of the existing
standard Domains.
 Security is a slice of a complete architecture from a given
perspective – does that sound familiar? It should: Security is a View.
Views can cross-cut Domains.
• Similarly Enterprise Architecture consists of elements from across the
standard Domains, therefore it is not itself a Domain. In this case,
Enterprise Architecture is a Tier (or Level) of Architecture, which is the
next topic of discussion.

47
Standard Architecture
Tiers

Architecture Overview – Architecture Tiers
Enterprise Architecture
Organizational
Scope
Scope of Problem Domain
Level
of
Detail
• 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.
48

Segment
Architecture
Organizational
Scope
• Segment Architecture is much like
EA but is applied to a specific sub-
section (segment) of the
enterprise.
• A segment can be a Portfolio, a
Line-of-Business, a Capability, a
technology or any other division
that makes sense to the company.
• Segment Architecture, because
the scope is more focused, takes
a closer look at the technology
and information landscape than at
the enterprise level.
49
Level
of
Detail

Portfolio
Architecture
Organizational
Scope
• Some companies choose to define
their segments by Portfolio, so
use the term Portfolio
Architecture.
• Portfolio Architecture can address
technological details to a greater
degree than EA, but does not
have the visibility across the
enterprise that EA does.
• In some companies, Portfolio
Architecture is just folded into EA,
so each enterprise architect is
assigned a portfolio to manage.
• Portfolio Architecture in many
ways is Enterprise Architecture
within a constrained boundary,
but with more exposure to
technology specifics.
Portfolio Architecture = Segment Architecture
50
Level
of
Detail

Solution
Architecture
Portfolio
Architecture
Organizational
Scope
• 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.
• 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).
• 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.
• Note: under a Product/Service
Management paradigm, Solution
Architecture also becomes more of
a continuous activity.
51
Level
of
Detail

All Architecture Domains are addressed at every Tier
Solution
Architecture
Portfolio
Architecture
Organizational
Scope
• Each of these tiers of architecture
(Enterprise, Portfolio, Solution)
address all architectural domains
(Business, Application, Information,
and Technical Architecture; i.e.,
“BAIT”) – but they do so based on
their different scopes of mandate.
• These are the most standard and
recognized tiers (or levels) of
Architecture, and therefore the
interaction between them is fairly
well-defined. (See my deck, “Introduction
to Architecture and Architects”)
• There is nothing wrong with a
company defining a different set of
layers, as long as it’s conceptually
robust, but few companies have the
need to really do that.
Project
Process
Architect
Project
Data
Architect
Project
Software
Architect
Project
Technical
Architect
• 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.
• Usually, though, this is actually
Design work - not Architecture –
regardless of the job title.
Project
Integration
Architect
Etc.
52
Level
of
Detail

Tiers and Domains does NOT mean Silos!
53
• These divisions are simply tools to
understand where and how to apply
architectural discipline, and to
break down the challenge.
• The actual process of Architecture
is continuous and holistic across
Tiers and Domains – it is a
continuous-improvement lifecycle.
• If EA strategic roadmaps do not see
realization in operational solutions,
then EA is irrelevant, and SA is at
best an incremental value-add.
• Breaking up EA, PA, and SA into
silos (which many companies do) is
contrary to the whole value
proposition of Architecture for
spanning silos.
Enterprise
Architecture
(layer/tier)
Solution
Architecture
(layer/tier)
Portfolio
Architecture
(layer/tier)
Business
(domain)
Application
(domain)
Information
(domain)
Technology
(domain)
Capability
Model,
Value Chain,
Business
Model
App
Rational-
ization,
App-to-
Capability
Mapping
Enterprise
Taxonomy,
Master Data
Mgmt.
Technical
Standards,
Trend
Forecasting
Business
Process,
Product,
Portfolio
Roadmap
Asset
Valuation,
SOA,
Application
Lifecycle
Mgmt.
Official
Source of
Record,
Information
Lifecycle
Mgmt.
Platform
Service,
Technology
Lifecycle
Mgmt.
Workflow,
Actor,
SLA
Integration
Pattern,
API,
Application
Structure
Data
Schema,
Data Flow,
Security
Control
HA,
DR,
Protocol,
Compute
Footprint
Representative
example
concepts

Enterprise
Architecture
(layer/tier)
Solution
Architecture
(layer/tier)
Portfolio
Architecture
(layer/tier)
Business
(domain)
Application
(domain)
Information
(domain)
Technology
(domain)
Capability
Model,
Value Chain,
Business
Model
App
Rational-
ization,
App-to-
Capability
Mapping
Enterprise
Taxonomy,
Master Data
Mgmt.
Technical
Standards,
Trend
Forecasting
Business
Process,
Product,
Portfolio
Roadmap
Asset
Valuation,
SOA,
Application
Lifecycle
Mgmt.
Official
Source of
Record,
Information
Lifecycle
Mgmt.
Platform
Service,
Technology
Lifecycle
Mgmt.
Workflow,
Actor,
SLA
Integration
Pattern,
API,
Application
Structure
Data
Schema,
Data Flow,
Security
Control
HA,
DR,
Protocol,
Compute
Footprint
Representative
example
concepts
Conceptual
Rows in
the Arch
Space
Conceptual Columns in the Arch Space
Think of Tiers
and Domains
as conceptual
rows and
columns
across the
Architecture
space.

55
TOGAF and Continuous
Improvement

TOGAF as a Modified Deming Cycle
• 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
• Check: Study the results
• Act: Adjust to bring results in line with
objectives
• TOGAF also is based on a continuous
improvement lifecycle
56
Plan
Do
Check
Act
Deming
Cycle
Are we doing
the right things?
Are we doing
things right?
Are we getting
the expected
results?
Are the results
netting the expected
benefits?

TOGAF as a Modified Deming Cycle
57
• Here is a diagram of TOGAF’s
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.

58
Integrating Architecture
into the
Greater Corporate Processes
of the
Ideation-to-Realization Cycle

The Basic Annual Corporate Cycle
59
• 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

The Basic Cycle Exists at Multiple Corporate Levels
60
• The basic annual cycle discussed in the
previous slide can be seen expressed at
various levels throughout the corporation:
• 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:
• 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

61
• 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/Product 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.
Architecture is Continuous Across Organization Levels
Architecture integrates into the basic Corporate cycles at
each level of the organization and helps to provide a vertical
backbone of integration between levels.
As an idea proceeds through its lifecycle, it also proceeds
down layers of the organization, and often back up again.

62
Architecture Applies Across the Ideation-to-Realization Cycle
• In this diagram, I have
compressed the 3 levels
shown on the previous slides
into one layer:
• The outer (tri-coloured) ring
plots standard corporate best
practices that are often
applied.
• The inner (yellow) ring plots
typical activities that are
undertaken within each of
these best practices.
• The brown inner circle shows
representative (this is not
comprehensive) Architecture
activities that are conducted
within each of the corporate
activities.
• Includes the monitoring,
operating and supporting of
systems

63
• Here’s a simplified “system interaction” type of view of how key best practices from the I2R
cycle interact, and how Architects of various levels have roles in these practices:
• Note: this is not meant to represent left-to-right order of processing.

64
• Here’s a simplified “process” type of view of how key best practices from the I2R cycle
interact, and how Architects of various levels have roles in these practices:

65
Integrating Architecture
into Projects

Architecture Engagement Across the Project Lifecycle
66
• 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).
EA = Enterprise Architecture/Enterprise Architect
PA = Portfolio Architecture/Portfolio Architect
SA = Solution Architecture/Solution Architect

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

68
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 silos like that:
Architects do perform analysis, but it is the synthesis that makes it Architecture!
• 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 Stakeholder’s 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.

69
I hope you have found this instructional
slide deck of some use in your research to
better understand the modern practice of
Architecture!

An Introduction To Fundamental Architecture Concepts

More Related Content

Similar to An Introduction To Fundamental Architecture Concepts (20)

More from Hannah Baker (20)

Recently uploaded (20)

An Introduction To Fundamental Architecture Concepts