SlideShare uma empresa Scribd logo
1 de 60
Baixar para ler offline
An Introduction to Fundamental
Architecture Concepts
Warren Weinmeyer
March, 2013
Warren Weinmeyer
May 2012
Updated: Sept. 2014
Updated: Oct. 2015
Updated: June 2017
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 the Architecture of
Buildings
• 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 am an independent consultant (and therefore always looking for work!) with
30 years of experience in a variety of industries (manufacturing, transportation,
energy, finance, retail, commercial software, utilities and government), in
everything from high-tech startups to multi-national corporations
• I’ve been working as an Architect for about 15 years, and base most of my
architecture framework off TOGAF, but with influences from ITIL (around
Service, Process and Function concepts), BizBok (to beef up the Business
Architecture domain of TOGAF), SABSA (to beef up the Security view) and a
sprinkling of DoDAF and PEAF.
• 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, that one should
leverage best practices instead of home-baking everything from scratch, and
that it should be an outward-facing practice (evangelized and embedded into
the greater corporate processes, not a black-box that spews out inscrutable
artifacts to no-one’s general understanding or interest).
• 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
common causes for the failure of an Architecture Practice.
Table of Contents
Topic Slide#
• Architecture vs. Design 7-15
• Architecture Models vs Diagrams 16-19
• Architectural Abstraction 20-27
• Viewpoints and Views 28-34
• Standard Architecture Domains 35-40
• Security: Domain or View? 41
• Standard Architecture Tiers 42-48
• TOGAF and Continuous Improvement 49-51
• Integrating Architecture into the Annual Cycle 52-55
• Integrating Architecture into Projects 56-58
• Key Points to Take Away 59
5
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”
• There’s better agreement on tiers of architecture
• Also better agreement on standard architecture
domains
• It’s important to standardize definitions to create a
coherent framework that will help achieve
consistency in quality and in format for architectural
artifacts
6
7
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
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: a detailed
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 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
• Examples:
14
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.
Example: Physical Architecture vs. Design
Example: Physical Architecture vs. Design
15
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.
16
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 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.
17
Example: Metamodel and Model
• Here is a look at part of TOGAF’s metamodel:
18
• 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
19
20
Architectural Abstraction
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)
21
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
22
More Abstract More Concrete
Architecture Abstraction Continuum
Conceptual PhysicalLogical
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 and diagrams:
23
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:
24
Logical Architecture
• Example: a detailed logical model that almost maps
1:1 with the corresponding physical model that
realizes the Logical architecture
25
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.
26
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
• 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.
27
28
Viewpoints and Views
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
29
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.
30
Viewpoints
31
• 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
• 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
32
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
33
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.
34
35
Standard Architecture
Domains
Architecture Overview – Architecture Domains
• Business Architecture:
Vision, Strategy, Objectives,
Processes, Principles, Capabilities,
Actors, Use Cases, Organization,
etc.
• Application Architecture:
Systems, Applications, Services,
Protocols, Messages, Interfaces,
Transactions, etc.
• Data/Information Architecture:
Information Entities, Ontologies,
Taxonomies, Data Relationships,
Schemas, etc.
• Technical Architecture:
Network, Servers, Storage,
Communications, Platforms,
etc.
• The scope of concerns that Architecture deals with is so broad that we divide it into
different foundational categories, typically called domains. The idea of a Domain as a
foundational category means that a particular thing resides in one Domain only.
36
Note: this visualization was adapted from the Software
AG/IDS Scheer ARIS manual…so… thanks, ARIS!
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)
37
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)
38
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)
39
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)
40
41
Security: Domain or View?
• 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 as 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.
42
Standard Architecture
Tiers
Architecture Overview – Architecture Tiers
Enterprise Architecture
Organizational
Scope
Scope of Problem Domain
TechnologyHorizon
• 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.
43
Architecture Overview – Architecture Tiers
Segment
Architecture
Enterprise Architecture
Organizational
Scope
Scope of Problem Domain
• 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.
TechnologyHorizon
44
Architecture Overview – Architecture Tiers
Portfolio
Architecture
Enterprise Architecture
Organizational
Scope
Scope of Problem Domain
• 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.
TechnologyHorizon
Portfolio Architecture = Segment Architecture
45
Architecture Overview – Architecture Tiers
Solution
Architecture
Portfolio
Architecture
Enterprise Architecture
Organizational
Scope
Scope of Problem Domain
• 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.
TechnologyHorizon
46
All Architecture Domains are addressed at every Tier
Solution
Architecture
Portfolio
Architecture
Enterprise Architecture
Organizational
Scope
Scope of Problem Domain
• 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
Business
Architect
Project
Information
Architect
Project
Application
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.
• Often, a lead programmer or
technical specialist is actually what’s
required, not a specialist architect.
TechnologyHorizon
Project
Integration
Architect
Project
Data
Architect
Etc.
47
Tiers and Domains does NOT mean Silos!
Solution
Architecture
Portfolio
Architecture
Enterprise Architecture
Organizational
Scope
Scope of Problem Domain
TechnologyHorizon
48
• 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.
• 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.
49
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
50
Plan
DoCheck
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
51
• 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.
52
Integrating Architecture
into the Annual
Corporate Cycle
The Basic Annual Corporate Cycle
53
• 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
54
• 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
55
• 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.
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. The next slide shows more explicitly exactly how
Architecture acts as an agent of integration across organization levels.
56
Integrating Architecture
into Projects
Architecture Engagement Across the Project Lifecycle
57
• 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 for a Project
Design
& Build
TestAnalyze
Elaboration Construction Transition
Chg
Mgmt
Deploy Support &
Warranty
Project
Charter
Portfolio
Architect
Solution
Architect
Non-funct
Requirmts
RFx
System
Selectn
Detailed
Non-funct
Requirmts
Detailed
Soln Arch
Test
Plan
Iterations
or Sprints
Deploymt
Plan
Operational
Support
Model
Legend
Architectural inputs
Architectural deliverable
Strategic
Roadmap
(Demand
Planning)
Transition
Plan
Retirement
Plan
Conceptual & high-level Logical
solution architecture is required
before starting an RFx, performing
System Selection, or beginning
detailed architecture and design
Requires non-functional
requirements,
Conceptual and high-
level Logical architecture
to be completed
Requires non-
functional
requirements,
Conceptual and high-
level Logical
architecture to be
completed
This is the
Support
Sustainment
“bible”
SA provides technology
retirement, resource
reclamation and
information disposition
plans
Depending on SDLC, may
iterate as far as
development milestones or
all the way to incremental
deploytments
Depending on SDLC, may
iterate as far as
development milestones or
all the way to incremental
deployments
Detailed
Logical
architecture
and physical
architecture;
may be done
in iterations
for agile
projects
SA reviews
development
team test plans,
contributes
non-functional
test plans
SA provides
backup,
technical
deployment
and rollback
plans
SA provides
cut-over plan,
including data
migration
Project
Phase Inception
PA provides Architect FTE estimate
for budgeting, and provides tasks
& work estimates for scheduling
Portfolio, Investment
Theme and Program
strategic roadmaps
Portfolio application
roadmap(s) PA provides complexity
& tech assessment
content, reads final
doc: this ensures early
visibility into the
approved project
58
Conceptual
& Logical
Soln Arch
Business
Case
Tactical
Roadmap
An Architect creates this
An Architect contributes to this
Key Take-Aways
59
• 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: if you are not considering the full scope of domains, it
is questionable whether you are creating Architecture – you are probably designing!
• 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.
60
I hope you have found this instructional
slide deck of some use in your research to
better understand the modern practice of
Architecture!

Mais conteúdo relacionado

Mais procurados

A Summary of TOGAF's Architecture Capability Framework
A Summary of TOGAF's Architecture Capability FrameworkA Summary of TOGAF's Architecture Capability Framework
A Summary of TOGAF's Architecture Capability FrameworkPaul Sullivan
 
Intro to Enterprise Architecture (EA)
Intro to Enterprise Architecture (EA)Intro to Enterprise Architecture (EA)
Intro to Enterprise Architecture (EA)Fahmi Abdul Latip
 
Learn Togaf 9.1 in 100 slides!
Learn Togaf 9.1 in 100 slides!Learn Togaf 9.1 in 100 slides!
Learn Togaf 9.1 in 100 slides!Sam Mandebvu
 
Togaf introduction and core concepts
Togaf introduction and core conceptsTogaf introduction and core concepts
Togaf introduction and core conceptsPaul Sullivan
 
Understanding and Applying The Open Group Architecture Framework (TOGAF)
Understanding and Applying The Open Group Architecture Framework (TOGAF)Understanding and Applying The Open Group Architecture Framework (TOGAF)
Understanding and Applying The Open Group Architecture Framework (TOGAF)Nathaniel Palmer
 
ArchiMate 3.0: A New Standard for Architecture
ArchiMate 3.0: A New Standard for ArchitectureArchiMate 3.0: A New Standard for Architecture
ArchiMate 3.0: A New Standard for ArchitectureIver Band
 
EA Intensive Course "Building Enterprise Architecture" by mr.danairat
EA Intensive Course "Building Enterprise Architecture" by mr.danairatEA Intensive Course "Building Enterprise Architecture" by mr.danairat
EA Intensive Course "Building Enterprise Architecture" by mr.danairatSoftware Park Thailand
 
What is the Value of Mature Enterprise Architecture TOGAF
What is the Value of Mature Enterprise Architecture TOGAFWhat is the Value of Mature Enterprise Architecture TOGAF
What is the Value of Mature Enterprise Architecture TOGAFxavblai
 
A Brief Introduction to Enterprise Architecture
A Brief Introduction to  Enterprise Architecture A Brief Introduction to  Enterprise Architecture
A Brief Introduction to Enterprise Architecture Daljit Banger
 
How to Articulate the Value of Enterprise Architecture
How to Articulate the Value of Enterprise ArchitectureHow to Articulate the Value of Enterprise Architecture
How to Articulate the Value of Enterprise Architecturecccamericas
 
TOGAF 9.2 - Transforming Business
TOGAF 9.2  -  Transforming BusinessTOGAF 9.2  -  Transforming Business
TOGAF 9.2 - Transforming BusinessReal IRM
 
Software Architecture: views and viewpoints
Software Architecture: views and viewpointsSoftware Architecture: views and viewpoints
Software Architecture: views and viewpointsHenry Muccini
 
Enterprise Architecture & Project Portfolio Management 1/2
Enterprise Architecture & Project Portfolio Management 1/2Enterprise Architecture & Project Portfolio Management 1/2
Enterprise Architecture & Project Portfolio Management 1/2Jean Gehring
 
Enterprise Architecture Frameworks
Enterprise Architecture FrameworksEnterprise Architecture Frameworks
Enterprise Architecture FrameworksStephen Lahanas
 
Implementing Effective Enterprise Architecture
Implementing Effective Enterprise ArchitectureImplementing Effective Enterprise Architecture
Implementing Effective Enterprise ArchitectureLeo Shuster
 
Enterprise Architecture using TOGAF 's ADM - Architecture Delivery Method (...
Enterprise Architecture using TOGAF 's ADM - Architecture Delivery Method (...Enterprise Architecture using TOGAF 's ADM - Architecture Delivery Method (...
Enterprise Architecture using TOGAF 's ADM - Architecture Delivery Method (...Chandrashekhar More
 
Design Science and Solution Architecture
Design Science and Solution ArchitectureDesign Science and Solution Architecture
Design Science and Solution ArchitectureAlan McSweeney
 
Enterprise Architecture & Project Portfolio Management 2/2
Enterprise Architecture & Project Portfolio Management 2/2Enterprise Architecture & Project Portfolio Management 2/2
Enterprise Architecture & Project Portfolio Management 2/2Jean Gehring
 

Mais procurados (20)

A Summary of TOGAF's Architecture Capability Framework
A Summary of TOGAF's Architecture Capability FrameworkA Summary of TOGAF's Architecture Capability Framework
A Summary of TOGAF's Architecture Capability Framework
 
Intro to Enterprise Architecture (EA)
Intro to Enterprise Architecture (EA)Intro to Enterprise Architecture (EA)
Intro to Enterprise Architecture (EA)
 
Learn Togaf 9.1 in 100 slides!
Learn Togaf 9.1 in 100 slides!Learn Togaf 9.1 in 100 slides!
Learn Togaf 9.1 in 100 slides!
 
Togaf introduction and core concepts
Togaf introduction and core conceptsTogaf introduction and core concepts
Togaf introduction and core concepts
 
Understanding and Applying The Open Group Architecture Framework (TOGAF)
Understanding and Applying The Open Group Architecture Framework (TOGAF)Understanding and Applying The Open Group Architecture Framework (TOGAF)
Understanding and Applying The Open Group Architecture Framework (TOGAF)
 
ArchiMate 3.0: A New Standard for Architecture
ArchiMate 3.0: A New Standard for ArchitectureArchiMate 3.0: A New Standard for Architecture
ArchiMate 3.0: A New Standard for Architecture
 
EA Intensive Course "Building Enterprise Architecture" by mr.danairat
EA Intensive Course "Building Enterprise Architecture" by mr.danairatEA Intensive Course "Building Enterprise Architecture" by mr.danairat
EA Intensive Course "Building Enterprise Architecture" by mr.danairat
 
What is the Value of Mature Enterprise Architecture TOGAF
What is the Value of Mature Enterprise Architecture TOGAFWhat is the Value of Mature Enterprise Architecture TOGAF
What is the Value of Mature Enterprise Architecture TOGAF
 
A Brief Introduction to Enterprise Architecture
A Brief Introduction to  Enterprise Architecture A Brief Introduction to  Enterprise Architecture
A Brief Introduction to Enterprise Architecture
 
How to Articulate the Value of Enterprise Architecture
How to Articulate the Value of Enterprise ArchitectureHow to Articulate the Value of Enterprise Architecture
How to Articulate the Value of Enterprise Architecture
 
TOGAF 9.2 - Transforming Business
TOGAF 9.2  -  Transforming BusinessTOGAF 9.2  -  Transforming Business
TOGAF 9.2 - Transforming Business
 
TOGAF 9.2 - the update
TOGAF 9.2 - the updateTOGAF 9.2 - the update
TOGAF 9.2 - the update
 
Archimate Viewpoints
Archimate ViewpointsArchimate Viewpoints
Archimate Viewpoints
 
Software Architecture: views and viewpoints
Software Architecture: views and viewpointsSoftware Architecture: views and viewpoints
Software Architecture: views and viewpoints
 
Enterprise Architecture & Project Portfolio Management 1/2
Enterprise Architecture & Project Portfolio Management 1/2Enterprise Architecture & Project Portfolio Management 1/2
Enterprise Architecture & Project Portfolio Management 1/2
 
Enterprise Architecture Frameworks
Enterprise Architecture FrameworksEnterprise Architecture Frameworks
Enterprise Architecture Frameworks
 
Implementing Effective Enterprise Architecture
Implementing Effective Enterprise ArchitectureImplementing Effective Enterprise Architecture
Implementing Effective Enterprise Architecture
 
Enterprise Architecture using TOGAF 's ADM - Architecture Delivery Method (...
Enterprise Architecture using TOGAF 's ADM - Architecture Delivery Method (...Enterprise Architecture using TOGAF 's ADM - Architecture Delivery Method (...
Enterprise Architecture using TOGAF 's ADM - Architecture Delivery Method (...
 
Design Science and Solution Architecture
Design Science and Solution ArchitectureDesign Science and Solution Architecture
Design Science and Solution Architecture
 
Enterprise Architecture & Project Portfolio Management 2/2
Enterprise Architecture & Project Portfolio Management 2/2Enterprise Architecture & Project Portfolio Management 2/2
Enterprise Architecture & Project Portfolio Management 2/2
 

Destaque

How to Break the Requirements into User Stories
How to Break the Requirements into User StoriesHow to Break the Requirements into User Stories
How to Break the Requirements into User StoriesShriKant Vashishtha
 
Agile User Stories | The complete Review
Agile User Stories | The complete ReviewAgile User Stories | The complete Review
Agile User Stories | The complete ReviewDavid Tzemach
 
Concept design
Concept designConcept design
Concept designNIELITA
 
Writing GREAT Agile User Stories
Writing GREAT Agile User StoriesWriting GREAT Agile User Stories
Writing GREAT Agile User StoriesAgileDad
 
Enterprise Architecture - An Introduction from the Real World
Enterprise Architecture - An Introduction from the Real World Enterprise Architecture - An Introduction from the Real World
Enterprise Architecture - An Introduction from the Real World Daljit Banger
 
EAPJ Vol IV July 2017
EAPJ Vol IV July 2017EAPJ Vol IV July 2017
EAPJ Vol IV July 2017Darryl_Carr
 
What Can We Do With The ArchiMate Language?
What Can We Do With The ArchiMate Language?What Can We Do With The ArchiMate Language?
What Can We Do With The ArchiMate Language?Iver Band
 
European Interoperability Framework For European Public Services Draft 2.0
European Interoperability Framework For European Public Services Draft 2.0European Interoperability Framework For European Public Services Draft 2.0
European Interoperability Framework For European Public Services Draft 2.0Friso de Jong
 
Delivering enterprise architecture
Delivering enterprise architectureDelivering enterprise architecture
Delivering enterprise architectureBas van Gils
 
Enterprise Architecture Overview
Enterprise Architecture OverviewEnterprise Architecture Overview
Enterprise Architecture OverviewTim Murphy
 
Integrating architecture and itil
Integrating architecture and itilIntegrating architecture and itil
Integrating architecture and itilwweinmeyer79
 
Agile, TOGAF and Enterprise Architecture: Will They Blend?
Agile, TOGAF and Enterprise Architecture:  Will They Blend?Agile, TOGAF and Enterprise Architecture:  Will They Blend?
Agile, TOGAF and Enterprise Architecture: Will They Blend?Danny Greefhorst
 
Structured Approach to Solution Architecture
Structured Approach to Solution ArchitectureStructured Approach to Solution Architecture
Structured Approach to Solution ArchitectureAlan McSweeney
 
Generating Architectural Concepts & Design Ideas
Generating Architectural Concepts & Design IdeasGenerating Architectural Concepts & Design Ideas
Generating Architectural Concepts & Design IdeasWan Muhammad / Asas-Khu™
 
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...Iver Band
 

Destaque (20)

Concepts in Architecture
Concepts in ArchitectureConcepts in Architecture
Concepts in Architecture
 
Unit 05: Physical Architecture Design
Unit 05: Physical Architecture DesignUnit 05: Physical Architecture Design
Unit 05: Physical Architecture Design
 
How to Break the Requirements into User Stories
How to Break the Requirements into User StoriesHow to Break the Requirements into User Stories
How to Break the Requirements into User Stories
 
How to write good user stories
How to write good user storiesHow to write good user stories
How to write good user stories
 
Agile User Stories | The complete Review
Agile User Stories | The complete ReviewAgile User Stories | The complete Review
Agile User Stories | The complete Review
 
Concept design
Concept designConcept design
Concept design
 
Writing GREAT Agile User Stories
Writing GREAT Agile User StoriesWriting GREAT Agile User Stories
Writing GREAT Agile User Stories
 
Enterprise Architecture - An Introduction from the Real World
Enterprise Architecture - An Introduction from the Real World Enterprise Architecture - An Introduction from the Real World
Enterprise Architecture - An Introduction from the Real World
 
EAPJ Vol IV July 2017
EAPJ Vol IV July 2017EAPJ Vol IV July 2017
EAPJ Vol IV July 2017
 
What Can We Do With The ArchiMate Language?
What Can We Do With The ArchiMate Language?What Can We Do With The ArchiMate Language?
What Can We Do With The ArchiMate Language?
 
Albertin Hp - Unified communication
Albertin Hp - Unified communicationAlbertin Hp - Unified communication
Albertin Hp - Unified communication
 
14.1 features
14.1 features14.1 features
14.1 features
 
European Interoperability Framework For European Public Services Draft 2.0
European Interoperability Framework For European Public Services Draft 2.0European Interoperability Framework For European Public Services Draft 2.0
European Interoperability Framework For European Public Services Draft 2.0
 
Delivering enterprise architecture
Delivering enterprise architectureDelivering enterprise architecture
Delivering enterprise architecture
 
Enterprise Architecture Overview
Enterprise Architecture OverviewEnterprise Architecture Overview
Enterprise Architecture Overview
 
Integrating architecture and itil
Integrating architecture and itilIntegrating architecture and itil
Integrating architecture and itil
 
Agile, TOGAF and Enterprise Architecture: Will They Blend?
Agile, TOGAF and Enterprise Architecture:  Will They Blend?Agile, TOGAF and Enterprise Architecture:  Will They Blend?
Agile, TOGAF and Enterprise Architecture: Will They Blend?
 
Structured Approach to Solution Architecture
Structured Approach to Solution ArchitectureStructured Approach to Solution Architecture
Structured Approach to Solution Architecture
 
Generating Architectural Concepts & Design Ideas
Generating Architectural Concepts & Design IdeasGenerating Architectural Concepts & Design Ideas
Generating Architectural Concepts & Design Ideas
 
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...
 

Semelhante a An introduction to fundamental architecture concepts

An Introduction To Fundamental Architecture Concepts
An Introduction To Fundamental Architecture ConceptsAn Introduction To Fundamental Architecture Concepts
An Introduction To Fundamental Architecture ConceptsHannah Baker
 
Togaf 9 introduction
Togaf 9 introductionTogaf 9 introduction
Togaf 9 introductionVinod Wilson
 
An introduction to architecture and architects
An introduction to architecture and architectsAn introduction to architecture and architects
An introduction to architecture and architectswweinmeyer79
 
Architecture Design
Architecture DesignArchitecture Design
Architecture DesignSaqib Raza
 
Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Tra...
Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Tra...Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Tra...
Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Tra...NUS-ISS
 
The Profession Of IT Architecture
The Profession Of IT ArchitectureThe Profession Of IT Architecture
The Profession Of IT ArchitectureChristopher Grant
 
Software Architecture Introduction
Software Architecture IntroductionSoftware Architecture Introduction
Software Architecture IntroductionSARCCOM
 
Software architecture introduction
Software architecture introductionSoftware architecture introduction
Software architecture introductionFreddy Munandar
 
O.Savchenko FWDays workshop Software Architecture
O.Savchenko FWDays workshop Software ArchitectureO.Savchenko FWDays workshop Software Architecture
O.Savchenko FWDays workshop Software ArchitectureAlexandr Savchenko
 
Frayed Edges - Architecture In Practice
Frayed Edges - Architecture In PracticeFrayed Edges - Architecture In Practice
Frayed Edges - Architecture In PracticeAman Kohli
 
Shop Drawings, Construction Drawings and As-Built Drawings - What’s the diffe...
Shop Drawings, Construction Drawings and As-Built Drawings - What’s the diffe...Shop Drawings, Construction Drawings and As-Built Drawings - What’s the diffe...
Shop Drawings, Construction Drawings and As-Built Drawings - What’s the diffe...Hitech CADD Services
 
Ten Advices for Architects
Ten Advices for ArchitectsTen Advices for Architects
Ten Advices for ArchitectsEberhard Wolff
 
10 Hinweise für Architekten
10 Hinweise für Architekten10 Hinweise für Architekten
10 Hinweise für Architektenadesso AG
 
Working with software architects - advice to project managers
Working with software architects - advice to project managersWorking with software architects - advice to project managers
Working with software architects - advice to project managersYaniv Pessach
 
Integrating Advanced Analytics with Autodesk Solutions
Integrating Advanced Analytics with Autodesk SolutionsIntegrating Advanced Analytics with Autodesk Solutions
Integrating Advanced Analytics with Autodesk SolutionsRich Hanapole
 
Enhancing clean architecture: 2 n-dimensional layers
Enhancing clean architecture: 2 n-dimensional layersEnhancing clean architecture: 2 n-dimensional layers
Enhancing clean architecture: 2 n-dimensional layersValentin-Tudor Mocanu
 

Semelhante a An introduction to fundamental architecture concepts (20)

An Introduction To Fundamental Architecture Concepts
An Introduction To Fundamental Architecture ConceptsAn Introduction To Fundamental Architecture Concepts
An Introduction To Fundamental Architecture Concepts
 
Togaf 9 introduction
Togaf 9 introductionTogaf 9 introduction
Togaf 9 introduction
 
An introduction to architecture and architects
An introduction to architecture and architectsAn introduction to architecture and architects
An introduction to architecture and architects
 
Architecture Design
Architecture DesignArchitecture Design
Architecture Design
 
Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Tra...
Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Tra...Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Tra...
Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Tra...
 
The Profession Of IT Architecture
The Profession Of IT ArchitectureThe Profession Of IT Architecture
The Profession Of IT Architecture
 
Software Architecture Introduction
Software Architecture IntroductionSoftware Architecture Introduction
Software Architecture Introduction
 
Software architecture introduction
Software architecture introductionSoftware architecture introduction
Software architecture introduction
 
The Role of the Architect
The Role of the ArchitectThe Role of the Architect
The Role of the Architect
 
IndEA.pptx
IndEA.pptxIndEA.pptx
IndEA.pptx
 
O.Savchenko FWDays workshop Software Architecture
O.Savchenko FWDays workshop Software ArchitectureO.Savchenko FWDays workshop Software Architecture
O.Savchenko FWDays workshop Software Architecture
 
Frayed Edges - Architecture In Practice
Frayed Edges - Architecture In PracticeFrayed Edges - Architecture In Practice
Frayed Edges - Architecture In Practice
 
Shop Drawings, Construction Drawings and As-Built Drawings - What’s the diffe...
Shop Drawings, Construction Drawings and As-Built Drawings - What’s the diffe...Shop Drawings, Construction Drawings and As-Built Drawings - What’s the diffe...
Shop Drawings, Construction Drawings and As-Built Drawings - What’s the diffe...
 
Ten Advices for Architects
Ten Advices for ArchitectsTen Advices for Architects
Ten Advices for Architects
 
Software design
Software designSoftware design
Software design
 
10 Hinweise für Architekten
10 Hinweise für Architekten10 Hinweise für Architekten
10 Hinweise für Architekten
 
Working with software architects - advice to project managers
Working with software architects - advice to project managersWorking with software architects - advice to project managers
Working with software architects - advice to project managers
 
Integrating Advanced Analytics with Autodesk Solutions
Integrating Advanced Analytics with Autodesk SolutionsIntegrating Advanced Analytics with Autodesk Solutions
Integrating Advanced Analytics with Autodesk Solutions
 
Enhancing clean architecture: 2 n-dimensional layers
Enhancing clean architecture: 2 n-dimensional layersEnhancing clean architecture: 2 n-dimensional layers
Enhancing clean architecture: 2 n-dimensional layers
 
تحليل النظم
تحليل النظمتحليل النظم
تحليل النظم
 

Último

Industrial Air Pollution studying Bhopal Gas Tragedy and Its impact in ecolog...
Industrial Air Pollution studying Bhopal Gas Tragedy and Its impact in ecolog...Industrial Air Pollution studying Bhopal Gas Tragedy and Its impact in ecolog...
Industrial Air Pollution studying Bhopal Gas Tragedy and Its impact in ecolog...Hem Chand
 
Understanding of Post-Event Press Release .pdf
Understanding of Post-Event Press Release .pdfUnderstanding of Post-Event Press Release .pdf
Understanding of Post-Event Press Release .pdfprnewswireagency
 
10032024_First India Newspaper Jaipur.pdf
10032024_First India Newspaper Jaipur.pdf10032024_First India Newspaper Jaipur.pdf
10032024_First India Newspaper Jaipur.pdfFIRST INDIA
 
Court Denies Rust Request for an Injunction to stay on the ballot
Court Denies Rust Request for an Injunction to stay on the ballotCourt Denies Rust Request for an Injunction to stay on the ballot
Court Denies Rust Request for an Injunction to stay on the ballotAbdul-Hakim Shabazz
 
A young black boy that lives in the ghetto
A young black boy that lives in the ghettoA young black boy that lives in the ghetto
A young black boy that lives in the ghettoterryhords56
 
Dep.Baptista.Jr - Termo de depoimento
Dep.Baptista.Jr - Termo de depoimentoDep.Baptista.Jr - Termo de depoimento
Dep.Baptista.Jr - Termo de depoimentoEditora 247
 
Pakistan Propaganda Needs Effective Rebuttal.
Pakistan Propaganda Needs Effective Rebuttal.Pakistan Propaganda Needs Effective Rebuttal.
Pakistan Propaganda Needs Effective Rebuttal.Nilendra Kumar
 
Dep. Freire Gomes - Termo de depoimento.
Dep. Freire Gomes - Termo de depoimento.Dep. Freire Gomes - Termo de depoimento.
Dep. Freire Gomes - Termo de depoimento.Editora 247
 

Último (9)

Industrial Air Pollution studying Bhopal Gas Tragedy and Its impact in ecolog...
Industrial Air Pollution studying Bhopal Gas Tragedy and Its impact in ecolog...Industrial Air Pollution studying Bhopal Gas Tragedy and Its impact in ecolog...
Industrial Air Pollution studying Bhopal Gas Tragedy and Its impact in ecolog...
 
Understanding of Post-Event Press Release .pdf
Understanding of Post-Event Press Release .pdfUnderstanding of Post-Event Press Release .pdf
Understanding of Post-Event Press Release .pdf
 
10032024_First India Newspaper Jaipur.pdf
10032024_First India Newspaper Jaipur.pdf10032024_First India Newspaper Jaipur.pdf
10032024_First India Newspaper Jaipur.pdf
 
Court Denies Rust Request for an Injunction to stay on the ballot
Court Denies Rust Request for an Injunction to stay on the ballotCourt Denies Rust Request for an Injunction to stay on the ballot
Court Denies Rust Request for an Injunction to stay on the ballot
 
A young black boy that lives in the ghetto
A young black boy that lives in the ghettoA young black boy that lives in the ghetto
A young black boy that lives in the ghetto
 
Dep.Baptista.Jr - Termo de depoimento
Dep.Baptista.Jr - Termo de depoimentoDep.Baptista.Jr - Termo de depoimento
Dep.Baptista.Jr - Termo de depoimento
 
Why democracy dies in Trumpian boredom (by Edward Luce)
Why democracy dies in Trumpian boredom (by Edward Luce)Why democracy dies in Trumpian boredom (by Edward Luce)
Why democracy dies in Trumpian boredom (by Edward Luce)
 
Pakistan Propaganda Needs Effective Rebuttal.
Pakistan Propaganda Needs Effective Rebuttal.Pakistan Propaganda Needs Effective Rebuttal.
Pakistan Propaganda Needs Effective Rebuttal.
 
Dep. Freire Gomes - Termo de depoimento.
Dep. Freire Gomes - Termo de depoimento.Dep. Freire Gomes - Termo de depoimento.
Dep. Freire Gomes - Termo de depoimento.
 

An introduction to fundamental architecture concepts

  • 1. An Introduction to Fundamental Architecture Concepts Warren Weinmeyer March, 2013 Warren Weinmeyer May 2012 Updated: Sept. 2014 Updated: Oct. 2015 Updated: June 2017
  • 2. 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
  • 3. To Avoid Confusion: This deck is not about the Architecture of Buildings • 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
  • 4. Who am I? • I am an independent consultant (and therefore always looking for work!) with 30 years of experience in a variety of industries (manufacturing, transportation, energy, finance, retail, commercial software, utilities and government), in everything from high-tech startups to multi-national corporations • I’ve been working as an Architect for about 15 years, and base most of my architecture framework off TOGAF, but with influences from ITIL (around Service, Process and Function concepts), BizBok (to beef up the Business Architecture domain of TOGAF), SABSA (to beef up the Security view) and a sprinkling of DoDAF and PEAF. • 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, that one should leverage best practices instead of home-baking everything from scratch, and that it should be an outward-facing practice (evangelized and embedded into the greater corporate processes, not a black-box that spews out inscrutable artifacts to no-one’s general understanding or interest). • 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 common causes for the failure of an Architecture Practice.
  • 5. Table of Contents Topic Slide# • Architecture vs. Design 7-15 • Architecture Models vs Diagrams 16-19 • Architectural Abstraction 20-27 • Viewpoints and Views 28-34 • Standard Architecture Domains 35-40 • Security: Domain or View? 41 • Standard Architecture Tiers 42-48 • TOGAF and Continuous Improvement 49-51 • Integrating Architecture into the Annual Cycle 52-55 • Integrating Architecture into Projects 56-58 • Key Points to Take Away 59 5
  • 6. 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” • There’s better agreement on tiers of architecture • Also better agreement on standard architecture domains • It’s important to standardize definitions to create a coherent framework that will help achieve consistency in quality and in format for architectural artifacts 6
  • 8. 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
  • 9. 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
  • 10. Architecture vs. Design • Most agree that there’s 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 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 Design Context- dependent
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. • Examples: 14 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. Example: Physical Architecture vs. Design
  • 15. Example: Physical Architecture vs. Design 15 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.
  • 17. 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 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. 17
  • 18. Example: Metamodel and Model • Here is a look at part of TOGAF’s metamodel: 18 • 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
  • 19. 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 19
  • 21. 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) 21
  • 22. 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 22 More Abstract More Concrete Architecture Abstraction Continuum Conceptual PhysicalLogical
  • 23. 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 and diagrams: 23
  • 24. 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: 24
  • 25. Logical Architecture • Example: a detailed logical model that almost maps 1:1 with the corresponding physical model that realizes the Logical architecture 25
  • 26. 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. 26
  • 27. 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 • 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. 27
  • 29. 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 29
  • 30. 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. 30
  • 31. Viewpoints 31 • 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.
  • 32. 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 32
  • 33. 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 33
  • 34. 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. 34
  • 36. Architecture Overview – Architecture Domains • Business Architecture: Vision, Strategy, Objectives, Processes, Principles, Capabilities, Actors, Use Cases, Organization, etc. • Application Architecture: Systems, Applications, Services, Protocols, Messages, Interfaces, Transactions, etc. • Data/Information Architecture: Information Entities, Ontologies, Taxonomies, Data Relationships, Schemas, etc. • Technical Architecture: Network, Servers, Storage, Communications, Platforms, etc. • The scope of concerns that Architecture deals with is so broad that we divide it into different foundational categories, typically called domains. The idea of a Domain as a foundational category means that a particular thing resides in one Domain only. 36 Note: this visualization was adapted from the Software AG/IDS Scheer ARIS manual…so… thanks, ARIS! A commonly-referenced framework of architectural domains is:
  • 37. 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) 37
  • 38. 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) 38
  • 39. 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) 39
  • 40. 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) 40
  • 41. 41 Security: Domain or View? • 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 as 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.
  • 43. Architecture Overview – Architecture Tiers Enterprise Architecture Organizational Scope Scope of Problem Domain TechnologyHorizon • 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. 43
  • 44. Architecture Overview – Architecture Tiers Segment Architecture Enterprise Architecture Organizational Scope Scope of Problem Domain • 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. TechnologyHorizon 44
  • 45. Architecture Overview – Architecture Tiers Portfolio Architecture Enterprise Architecture Organizational Scope Scope of Problem Domain • 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. TechnologyHorizon Portfolio Architecture = Segment Architecture 45
  • 46. Architecture Overview – Architecture Tiers Solution Architecture Portfolio Architecture Enterprise Architecture Organizational Scope Scope of Problem Domain • 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. TechnologyHorizon 46
  • 47. All Architecture Domains are addressed at every Tier Solution Architecture Portfolio Architecture Enterprise Architecture Organizational Scope Scope of Problem Domain • 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 Business Architect Project Information Architect Project Application 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. • Often, a lead programmer or technical specialist is actually what’s required, not a specialist architect. TechnologyHorizon Project Integration Architect Project Data Architect Etc. 47
  • 48. Tiers and Domains does NOT mean Silos! Solution Architecture Portfolio Architecture Enterprise Architecture Organizational Scope Scope of Problem Domain TechnologyHorizon 48 • 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. • 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.
  • 50. 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 50 Plan DoCheck 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?
  • 51. TOGAF as a Modified Deming Cycle 51 • 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.
  • 52. 52 Integrating Architecture into the Annual Corporate Cycle
  • 53. The Basic Annual Corporate Cycle 53 • 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
  • 54. The Basic Cycle Exists at Multiple Corporate Levels 54 • 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
  • 55. 55 • 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. 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. The next slide shows more explicitly exactly how Architecture acts as an agent of integration across organization levels.
  • 57. Architecture Engagement Across the Project Lifecycle 57 • 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
  • 58. Here is a closer look at some of the Architectural Inputs for a Project Design & Build TestAnalyze Elaboration Construction Transition Chg Mgmt Deploy Support & Warranty Project Charter Portfolio Architect Solution Architect Non-funct Requirmts RFx System Selectn Detailed Non-funct Requirmts Detailed Soln Arch Test Plan Iterations or Sprints Deploymt Plan Operational Support Model Legend Architectural inputs Architectural deliverable Strategic Roadmap (Demand Planning) Transition Plan Retirement Plan Conceptual & high-level Logical solution architecture is required before starting an RFx, performing System Selection, or beginning detailed architecture and design Requires non-functional requirements, Conceptual and high- level Logical architecture to be completed Requires non- functional requirements, Conceptual and high- level Logical architecture to be completed This is the Support Sustainment “bible” SA provides technology retirement, resource reclamation and information disposition plans Depending on SDLC, may iterate as far as development milestones or all the way to incremental deploytments Depending on SDLC, may iterate as far as development milestones or all the way to incremental deployments Detailed Logical architecture and physical architecture; may be done in iterations for agile projects SA reviews development team test plans, contributes non-functional test plans SA provides backup, technical deployment and rollback plans SA provides cut-over plan, including data migration Project Phase Inception PA provides Architect FTE estimate for budgeting, and provides tasks & work estimates for scheduling Portfolio, Investment Theme and Program strategic roadmaps Portfolio application roadmap(s) PA provides complexity & tech assessment content, reads final doc: this ensures early visibility into the approved project 58 Conceptual & Logical Soln Arch Business Case Tactical Roadmap An Architect creates this An Architect contributes to this
  • 59. Key Take-Aways 59 • 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: if you are not considering the full scope of domains, it is questionable whether you are creating Architecture – you are probably designing! • 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.
  • 60. 60 I hope you have found this instructional slide deck of some use in your research to better understand the modern practice of Architecture!