© CGI Group Inc. CONFIDENTIAL

The Life and Times of an ArchitectureFinding the common ground between traditional and agile architecting

Eltjo PoortSATURN 2017

What do we architect?

Internal structure of software Software CI/CD pipelines

IT infrastructure for application landscape Embedded systems

Integrated software systems Enterprise IT systems Outsourcing services The world’s largest robot

2

3

When do we architect?

Traditional governance

Project

Agile governance

Architectural Epic

TransformConstructElaborateConceive

Funnel Backlog Analysis Implement

4

Definition of Solution

Changes: solution elements are created, modified or removedDelivered: coordination depends on governance model:• agile or traditional• value stream, program or project• contractual or otherwiseDefined: depends on governance model:• Epic / set of (user) stories• Program / project definition• Contract• Change request

Solution: a coherent set of changes delivered to address a defined set of stakeholder needs

5

How do we architect?

Architecture as a stream of design decisions lowers the cost of change:

• Convey rationale and options• Convey changes and implications• Deal with changing context

Knowing the “Why?” behind an architectural decision is key to revisiting that decision when things change

6

Why do we architect?

Architecture’s primary business goal is risk and cost reduction, and it works.

Projects that apply architecture practices have:• Reduced uncertainty in feasibility of solution• Reduced risk of delivery troubles• Better predictability of solution cost• Less budget overrun

Source: Raymond Slot, PhD Thesis, 2010.

“Architecture is about the important stuff.Whatever that is.”

The Architecting MicrocycleWorkflow for architectural decision making

7

Identify & prioritize

architectural concerns

Research possible

strategies

Decide best fitting

strategy

Architectural concerns(backlog)

Architecturaldecisions

8

Cone of Uncertainty

Evolution of amount of uncertainty (in solution life cycle)

Cone is narrowed by:• Research• Decision making

Architecture narrows the cone by researching strategies to architectural concerns and making architectural decisions.

Source: Steve McConnell, Barry Boehm

t

9

Architectural Decisions throughout the life cycle

All architectural decisions are based on incomplete information…

…and the highest impact decisions are taken while the least factual knowledge is available.

Source: Philippe Kruchten

Architecture decision impact Available knowledge

# Decisions

Cone of uncertaintyt

The life and times of an architecture

10

t

Birth: from stakeholder need to solution conceptGraduation: making the business case

Marriage: committing to the architectureCareer and home life

Children: revolutionary changes

Legacy

BirthSolution concept

Typical concerns

• What do the stakeholders need?• How can we give it to them?

11

Typical output

• Business goals• Scope• First solution concept

BirthSolution concept

Typical concerns

• What do the stakeholders need?• How can we give it to them?

Traditional

• Project Brief• Inception• Solution Outline

12

Typical output

• Business goals• Scope• First solution concept

Agile

• Capture• Funnel

GraduationBusiness case

Typical concerns

• Is it worth doing this?• Are we confident risks and costs are

under control?

13

Typical output

• Business case• Solution design• Delivery concept

GraduationBusiness case

Typical concerns

• Is it worth doing this?• Are we confident risks and costs are

under control?

Traditional

• Project Initiation Documentation• Elaboration• Architectural Design

14

Typical output

• Business case• Solution design• Delivery concept

Agile

• Value statement, ROI• Refine understanding• Analysis

Tip: document this evidence in architectural views that address uncertainty-related concerns:• Operational View• Delivery Breakdown View

15

Graduation

• Stakeholder(s) funding solution (project/epic) agree that uncertainty in risk and cost is below a threshold

• Architecture is (part of) evidence that threshold is reached

Cone of uncertainty

Budget approval

Acceptable risk threshold

Graduation: making the business case

t

All architecture documentation methods use views• ISO 42010, TOGAF, Archimate, 4 + 1, ‘Views and Beyond’

• Viewpoints address concerns per stakeholder (group)• Budget go/no-go concerns are common across traditional and agile contexts

GraduationViews and Viewpoints

Graduation ViewsOperational View: Context Diagram

Context Diagram:Solution in its operational environment

• “What’s in scope and what is not?” Solution Boundary

• “What external systems/actors?” Interface Overview

Source: Wikimedia

Graduation ViewsOperational View: Operational Decomposition

Operational Decomposition:Components interact in running solution

• “How do run-time elements depend on each other?”

• “How does information flow through the solution?”

Transient Solutions:• “How is the system operated now?”

CMO, As-is• “How will it run after transformation?”

FMO, To-beSource: ibm.com

Graduation ViewsSolution Breakdown Structure

“How can the solution be decomposed to manage delivery?”

Basis for organizational allocation, solution costing, project planning / story decomposition

Solution

SW systemMaintenanceorganization

Supporting system

modifications

Hosting

App 1 Lib 5

Solution Breakdown Structure

MarriageCommitting to the architecture

Typical concerns

• How confident are we about this architecture?

• What are the alternatives?

20

Typical output

• Comparative / trade-off analysis• Elaborated solution design• Design review

MarriageCommitting to the architecture

Typical concerns

• How confident are we about this architecture?

• What are the alternatives?

Traditional

• Project Initiation Documentation• Elaboration• Critical Design Review

21

Typical output

• Comparative / trade-off analysis• Elaborated solution design• Design review

Agile

• Refine understanding• Review, evaluation• Evaluation

22

Marriage

Cost of change to architecture quickly grows after a point in time, e.g.:• Size of realization refactoring• Divestments in training,

development environment, third party products/commitments

t

Cost of architecture change

Cone of uncertainty

Realized solution

Marriage: committing to the architecture

Tip: organize independent architecture assessment before crossing this line• Cf. Kahneman “Outside View”• E.g. ATAM

Business Criticality

23

Marriage preparationHow many architectural decisions before commitment?

Cost of architecture change

Source: Barry Boehm

Cost of architecture change# Decisions

# Decisions

Marriage

Size

Volatility

Higher

Lower

Lower

Higher

Smaller/Simpler Larger/Complexer

Marriage

Career and Home LifeFulfilling the architecture

tCone of uncertainty

Realized solution

Career: fulfilling the architecture

25

Career and Home LifeFulfilling the architecture

Cone of uncertainty

Realized solution

Career: fulfilling the architecture• Ensure realization of all elements• Based on Delivery Breakdown View

Completeness

• Verify NFRs and other architectural requirements

Testing

• Architect involved in integration• Minimize inter-team dependencies

Coherence

• Architecture views, wallpaper, telling, training

Communication

• Identify & manage (new) architectural concerns

Risk Management

Def.of Done/Project plan

Backlog/Project plan

Team organization

Risk logConcern register

Team organization

t

26

Career and home lifeHealth and Debt Control

What’s in your backlog? (or Work Breakdown Structure / Project Portfolio / Change Requests)

New featuresAdded

functionality

Architectural,Structural features

Defects Technical Debt

Visible Invisible

PositiveValue

NegativeValue

Source: Philippe Kruchten

Health and Debt Control using SCRUM & RCDA

27

Health and Debt ControlArchitecture Roadmapping with Just Enough Anticipation

Just Enough Anticipation achieved by:

• Dependency Analysis• Technical Debt Control• Economic Reasoning

28

Source: Nanette Brown, Rod Nord, Ipek Ozkaya

ChildrenRevolutionary Changes

29

Typical concerns

• What has changed since the previous generation?

• Prevent damage to existing status quo

Typical output

• Business goals• Scope• First solution concept

ChildrenRevolutionary Changes

30

Typical concerns

• What has changed since the previous generation?

• Prevent damage to existing status quo

Traditional

• Project Brief• Inception• Solution Outline

Typical output

• Business goals• Scope• First solution concept

Agile

• Capture• Funnel

Our commitment to youWe approach every engagement with one objective in mind: to help clients succeed

Spare slides follow

Architectural Decision MakingTiming of architectural decisionsCertainty of correct architectural decision depends on knowledge:• relative cost of the alternative solutions• value and impact on the business• delivery times

Timing architectural decision is balancing risk, cost and delivery time:• too little information risk of not meeting key requirements• waiting too long project delays, wasted resources

Key skills of Solution Architect:• timing of architectural decisions• making decisions based on incomplete information• dealing with the resulting risks

There's an art of knowing when.Never try to guess.

Toast until it smokes and thentwenty seconds less.

- Pat Hein

t

RiskCost of delay

Cost + Risk

Decisiontime

Solution CostingExample: Package Implementation

1. Configuration2. Custom built functionality3. Core module(s) / standard functionality4. External interfaces5. Internal interfaces6. Data

33

Solution CostingExample: Package Implementation Decisions

34

D1 – Choice of ERP Vendor: TBQD2 – Core modules selected: Finance & OrderD3 – Extend Order module with bespoke Order Routing functionalityD4 – Extend Finance module with bespoke Internal Clearing functionalityD5 – Build custom functionality using Mill platformD6 – Payments will be handled by partner PayUpD7 – Order related e-mails sent through existing mail distribution serverD8 – Order Routing module will interface with Fleet mgt partner AphlasD9 – Data to be converted: Ledger, Catalog, Stock (no open orders)D10 – Selected ETL tool: Barn

Solution CostingExample: Operational View

35

TBQ Finance Core

Internal Clearing (custom)

TBQ Order Core

Order Routing (custom)

TBQ Solution

PayUp

Aphlas

Mail

Users

Solution CostingExample: Construction View

36

TBQ Finance Core

Internal Clearing (custom)

TBQ Order Core

Order Routing (custom)

TBQ Solution

PayUp

Aphlas

Mail

Barn

Barn

CatalogStock

Mill

Mill

Ledger

Solution CostingExample: Package Implementation SBS

Package Implementation

Configuration

Finance config

Order config

Custom built functionality

Internal Clearing

Order Routing

Core modules

Finance

Order

External interfaces

Payments

Mail

Fleet

Internal interfaces

Finance Order

Data

Converted Ledger

Converted Catalog

Converted Stock

37

Solution CostingExample: Package Implementation Cost Drivers

38

Deliverable Elements Typical cost drivers (realization) Parameter examples

Configuration Solution complexity #Config parameters

Organization complexity #Stakeholder workshops

Custom built functionality Functional size #Use cases, function pts

Implementation technology API callsProgramming language

Core module(s) / standard functionality

Vendor IP pricing Modules, options#Users, #Transactions…

External interfaces Interface complexity I/F protocol, technologyNon-functional reqs

Commercial availability Vendor pricing

Internal interfaces Interface complexity I/F protocol, technologyNon-functional reqs

Data Data size #TB, #tables, #records

Data quality Pollution, redundancy

Data compatibility (ETL) tooling availability