An Introduction to Fundamental Architecture Concepts
Warren Weinmeyer
March, 2013Warren Weinmeyer
May 2012
Updated: Sept. 2014
Contents
• Architecture vs. Design
• Architectural Abstraction
• Viewpoints and Views
• Standard Architecture Domains
• Standard Architecture Tiers
• TOGAF and Continuous Improvement
• Integrating Architecture into the IT Annual Cycle
• Integrating Architecture into IT Projects
2
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
3
4
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
5
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)
6
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.
7
More Abstract More ConcreteAbstraction Continuum
Architecture
DesignContext-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
8
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
9
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”.
10
• Examples:
11
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
12
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.
13
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)
14
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
• Logical Architecture applies to a wide range of abstraction levels between Conceptual and Physical
• Physical Architecture is the least abstract representation
15
More Abstract More ConcreteArchitecture Abstraction
Continuum
Conceptual PhysicalLogical
Conceptual Architecture• Conceptual architecture diagrams are static 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.
• Some examples of Conceptual Models:
16
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)
• Examples: a high-level and more detailed example of a Logical Model:
17
Logical Architecture
• Example: a very detailed logical model
18
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 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.
19
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• Your Viewpoint Framework (designed in context of
your Stakeholder Framework) will provide guidance to your Modeling Framework
• If it’s not done in a controlled manner then you will end up with a repository of models that are not consistent, which will make it very difficult for your repository tool to generate good analytics from.
20
21
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 a huge amount of 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
• Views are derived from Viewpoints
• 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
22
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.
• 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.
23
Viewpoints
24
• 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 of the Viewpoint)
• The viewpoint language, or modeling techniques, or analytical methods used to construct, depict and analyze the resulting view
• 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
25
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
26
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.
27
28
Standard Architecture
Domains
Architecture Overview – Architecture Domains
Application Architecture
InformationArchitecture
Business Architecture
TechnicalArchitecture
• 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 categories, typically called domains. A very common definition of architectural domains is:
29
Note: this visualization was adapted from the Software AG/IDS Scheer ARIS manual…so… thanks, ARIS!
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)
30
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)
31
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)
32
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)
33
34
Standard Architecture
Tiers
Architecture Overview – Architecture Tiers
Enterprise Architecture
Organizational Scope
Scope of Problem Domain
Tech
nolo
gy H
ori
zon
• 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.
35
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.
Tech
nolo
gy H
ori
zon
36
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.
Tech
nolo
gy H
ori
zon
Portfolio Architecture = Segment Architecture
37
Architecture Overview – Architecture Tiers
SolutionArchitecture
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.
Tech
nolo
gy H
ori
zon
38
All Architecture Domains are addressed at every Tier
SolutionArchitecture
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.
ProjectBusinessArchitect
ProjectInformationArchitect
ProjectApplicationArchitect
ProjectTechnicalArchitect
• 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.
Tech
nolo
gy H
ori
zon
ProjectIntegrationArchitect
ProjectDataArchitect
Etc.
39
Tiers and Domains does NOT mean Silos!
SolutionArchitecture
Portfolio Architecture
Enterprise Architecture
Organizational Scope
Scope of Problem Domain
Tech
nolo
gy H
ori
zon
40
• 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 – it is a complete 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.
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
41
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
42
• 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.
The Basic Annual IT Cycle
43
• Most companies tend to keep to a traditional, fundamental annual rhythm that has 3 basic phases:
• Planning for the upcoming year
• Executing Delivery projects that were identified in the planning stage
• Maintaining delivered solutions as part of corporate operations• Includes the monitoring,
operating and supporting of systems
Opportunity Identifi-cationService Strategy Capture
Service Road-mapping
Portfolio Strategy Capture
Capability Planning
Strategy Capture /Review
Help Desk
Demand Mgmt. IT Road-
mapping
Project PortfolioMgmt.
Project Mgmt.
Change Mgmt.
The Basic IT Cycle Exists at Multiple Levels of IT
44
• At the IT 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
Technology Landscape Mgmt.
Program Mgmt.
IT Organization
IT Portfolio
IT Service
Master Data Mgmt.
Service Support Operations Change
Mgmt.
ServiceStrategy
Service Support
Opportunity Identification Service
Road-mapping
Project Mgmt.
Change Mgmt.
Service Operations
Service
Service
Portfolio
Portfolio
45
•IT Organization level:• Architecture is focused on EA
concerns, such as the business priorities, investment prioritization, architectural governance (standards, arch. patterns and compliance) and future-state visioning/planning
•Portfolio/segment level:• Architecture is concerned with
portfolio management and capability planning.
•IT Service level:• Architecture is concerned with the
application of Solution Architecture practices within service delivery projects
Portfolio
Architecture Integrates into the IT Cycle at Each Level
Portfolio Strategy Capture
Capability Planning
Technology Landscape Mgmt.
Program Mgmt.
Master Data Mgmt.
ITStrategy Capture /Review
Help Desk
Demand Mgmt.
IT Road-mapping
Project PortfolioMgmt.
Change Mgmt.
Architecture is about far more than just “popping in” on a Project!
Design & Build
TestAnalyze
Elaboration Construction Transition
Chg Mgmt
Deploy Support & Warranty
Project Charter
PortfolioArchitect
Solution Architect
Non-functRequirmts
RFx
SystemSelectn
DetailedNon-functRequirmts
DetailedSoln Arch
TestPlan
Iterations or Sprints
DeploymtPlan
Operational Support Model
Legend
Architectural inputs
Architectural deliverable
Strategic Roadmap
(DemandPlanning)
TransitionPlan
RetirementPlan
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
46
Conceptual& Logical Soln Arch
Business Case
Tactical Roadmap
An Architect creates this
An Architect contributes to this
47