adapting architecture practices to changing … · adapting architecture practices to changing...

© CGI Group Inc.

Adapting Architecture Practices to Changing TimesFrom What to Why and Back Again

Eltjo PoortSATURN, 5 May 2016

2

Eltjo Poort

CGI Architecture Community of Practice lead• Solution Architect, Reviewing Bids & Projects• Standardizing & Improving Architecture Practices

Researcher• With Universities (VU, Twente, Utrecht, Eindhoven)• Member of IFIP WG 2.10 Software Architecture

http://eltjopoort.nl

http://eltjopoort.nl/

Founded in 1976, CGI is one of the largest IT and business process services providers in the world, delivering high-quality business

consulting, systems integration and managed services. With a deep commitment

to providing innovative services and solutions, CGI has an industry-leading track record of delivering 95% of projects on time and within budget, aligning our teams with

clients’ business strategies to achieve top-to-bottom line results.

3

4

1996 – An Emerging Discipline

Architecture as a high-level structure

needed to reason about a software system.

2001: Manifesto for Agile Software Development

5

agilemanifesto.org

“The best architectures, requirements, and

designs emerge from self-organizing teams.”

http://agilemanifesto.org/

2005: Software Architecture as Design Decisions

6

Focus on Architectural Decisions• Convey change• Convey implications• Convey rationale & options• Ease of traceability• Agile documentation

Why?

7

Simon Sinekted.com

Why do we still need Architecture?

Result Correlation with applying architecture practicesBudget predictability 2-3 x better Std dev 32 13

Budget overrun 7 x less 22% 3%

Time overrun 6 x less 48% 8%

Troubled projects 3 x less 38% 13%

Customer satisfaction 1-2 points better 10 point scale

Results delivered +10%

8

Survey among 49 software development projects between €50,000 and €2,500,000. Reported by Raymond Slot, PhD Thesis, 2010.

What is architecture about?

9

After talking to architects and stakeholders on dozens of projects, we have come to equate the “important stuff” with the stuff that has most impact on risk and costs.

Important high risk and cost

“Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principlesof its design and evolution”.

[ISO/IEEE]

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

[Fowler]

RCDA: Risk and Cost Driven Architecture

10

Solution architecting principles and practices based on a view of architecture as a risk and cost management discipline• Works because it uses informal practices• Architectural decision making based on

economic trade-offs• Architecture communication in economic terms• Traceability from requirements to cost

Basis of RCDA Solution Architecture

Experience in Solution AssuranceReviewing 100s of architectures

Industry Leading Architecture visionsSEI, TOGAF

Research in Architecture Knowledge ManagementFocus on Architectural Decisions

Feedback from CGI Architect Community Network

Environment

Business Process

Information Systems

Technology

SaaS

InfraS

OA

App

BP

O

Solution

11

“RCDA helps us to map out the required quality of IT-based systems in a structured way and provide governance to system development.”

Klaas van der Ploeg, Architect, ProRail.

RCDA track record

12

Proven benefits:• Improved control over IT solution risks and costs• Reduced risk of delayed delivery and

budget overruns• Transparency in solution costing• Enhanced solution quality

Dissemination:• Journal of Systems and Software• IEEE Software Magazine • Leading architecture conferences: SATURN,

LAC, WICSA (best paper award)• Linda Northrop Software Architecture Award

500Architects trained

19Proven practices

300Pages of guidance

12Peer-reviewed

publications

RCDArecognized in the

Open Group Certified Architect program

Principles of Agile Architecting

Decisions are your main deliverable

Keep a backlog of architectural concerns

Let economic impact determine your focus

Keep it small

Use just enough anticipation

13


14




Keep it small


Traditional architect involvement

15

Solution Delivery

Check points

Architecture Department

BUFD

Agile team perception of architect involvement

MYOB

Architecture Guidance


16




Keep it small


The Architecting Microcycle

Research possible solutions

Decide best fitting

solution

Identify & prioritize

architectural concerns

Architectural concerns(backlog)

Architecturaldecisions

17


18




Keep it small


Architecture should be minimal

19

Avoid trap of “architecting everything”• Architectures are hard to change• Big architectures obstruct agility• Give designers/developers as much freedom as

they can handle• Give yourself chance to keep total overview

Three factors determine optimal amount of up-front design:

Business criticality + Size – VolatilityBarry Boehm


20




Keep it small


SCRUM and the Architecture Microcycle

Sprint

Daily

Solution Increment

Solution Backlog Sprint Backlog

Architectural concerns

Architectural decisions

ArchitectureMicrocycle

Architecture Runway

Technical Debt

User Features

Defects

Stakeholders

21

Challenges ahead:Adding the time dimension to architecting

Rel 1.3Q1 2017

Rel 2.0Q2 2017

Rel 2.1Q3 2017

Rel 2.2Q4 2017

Rel 2.3Q1 2018

Project Wfinishes

New Reporting

Regulations

Competitor Releases NextGen

A

F

T

Technical debt reduction

Architectural improvementUser feature

Defect removalDependencyLegend

Backlog colors: Philippe Kruchten

22

Thank you

Spare slides follow

Hans van VlietPhilippe KruchtenPaul ClementsLenn BassPatricia LagoRick KazmanJohn KleinIpek OzkayaJudy StaffordAnonymous reviewers

Andrew KeyWouter GeurtsPeter de WithRich HilliardEoin WoodsGeorge FairbanksRemco de BoerRik FarenhorstJos van Dijck

23

RCDA Practices

LifecyclesRCDA Core Process

Bid

RUP Software Development

Blended Delivery

Enterprise to Solution

Agile Development

Waterfall Project

Requirements Analysis

Solution Shaping

Architecture Validation

Architecture Fulfillment

Core Practices Supporting Practices

Architectural Requirements Prioritization

Solution Selection

Architecture Evaluation

Stakeholder Workshop

Dealing with NFRs

Cost-Benefit Analysis

Documenting Architectural Decisions

Architectural Prototyping

Supplier Evaluation

Requirements Convergence Plan

Architecture Implementation

Solution Shaping Workshop

Solution Costing

Architecture Documentation

Applying Architectural Strategies

Independent Architecture Assessment

Architecture Roadmapping

Architecture Maintenance Technical Debt Control

24

References

Abrahamsson, P., Babar, M. A., & Kruchten, P. (2010, March/April). Agility and Architecture: Can They Coexist? IEEE Software.

Boehm, B. (2010). Architecting: How Much and When? In A. Oram, & G. Wilson, Making Software: What Really Works, and Why We Believe It . O'Reilly Media.

Brown, N., Nord, R. L., & Ozkaya, I. (2010, November/December). Enabling Agility Through Architecture. CrossTalk.

Fowler, M. (2003, July/August). Who Needs an Architect? IEEE Software, pp. 2-4.

Jansen, A., & Bosch, J. (2005). Software Architecture as a Set of Architectural Design Decisions. Working IEEE/IFIP Conference on Software Architecture.

Malan, R., & Bredemeyer, D. (2002, september/oktober). Less is More with Minimalist Architecture. IT Pro, pp. 46-48.

Poort, E. R., & van Vliet, H. (2012). RCDA: Architecting as a Risk- and Cost Management Discipline. Journal of Systems and Software, 1995-2013.

Poort, E. R. (2014, Sept/Oct). Driving Agile Architecting with Cost and Risk. IEEE Software.

Slot, R. (2010). A method for valuing architecture-based business transformation and measuring the value of solutions architecture. Amsterdam.

25

adapting architecture practices to changing … · adapting architecture practices to changing...

Documents