3;tures:*architecture,*structure,* infrastructure* file• Design,*developmentand* Tesng* •...
Transcript of 3;tures:*architecture,*structure,* infrastructure* file• Design,*developmentand* Tesng* •...
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 1
3-‐tures: architecture, structure, infrastructure Philippe Kruchten
Agile Vancouver October 26, 2014
Philippe Kruchten, Ph.D., P.Eng., CSDP
Professor of So)ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering
University of BriKsh Columbia Vancouver, BC Canada [email protected]
Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected]
2Copyright © 2014 Philippe Kruchten
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 2
Outline • Architecture • Architects • Agile and architecture (!?) • Scaling agile • Socio-‐technical congruence • ConKnuous delivery • The advent of DevOps • Reducing fricKon
3
Architecture Yes, but what flavour?
• System architecture • Enterprise architecture • Business architecture • SoYware architecture • Service-‐oriented architecture • InformaKon architecture • SoluKon architecture
4
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 3
Business Architecture
• A subset of the enterprise architecture that defines an organizaKon’s current and future state, including its strategy, its goals and objecKves, the internal environment through a process or funcKonal view, the external environment in which the business operates, and the stakeholders affected by the organizaKon’s acKviKes.
BABOK v2 2009
5
Enterprise Architecture
• Enterprise architecture is a descripKon of an organizaKon’s business processes, IT soYware and hardware, people, operaKons and projects, and the relaKonships between them.
Source BABOK v2 2009
6
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 4
SoluKon architecture
• System architecture
• SoYware architecture
7
Two Main Cultures Solu1on Architect • Authority • Technical Decision Maker • Requirements è Architecture • Single “problem” • “Building Design”
• References: – SEI: ATAM, CBAM, QAW – RUP: 4+1 Views – Fowler: Architectus Oryzus – IEEE 1471
Enterprise Architect • Advisor / Consultant • Building Bridges • Business / IT Alignment • Governance over mulKple
“problems” • “City Planning”
• References: – Zachman – TOGAF, DODAF – DYA, IAF, GEM, BASIC,… – IEEE 1471
Source Eltjo Poort
8
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 5
SoYware Architecture
Enterprise Architecture
System Architecture
Source Eltjo Poort
9
Architectural Styles, Genres, Paqerns, Mechanisms,…
• Layered architecture • Client-‐server architecture • Service-‐oriented architecture
10
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 6
SoYware Architecture: A DefiniKon
“It’s the hard stuff.”
M.Fowler, cited by J. Highsmith 11
SoYware Architecture: A DefiniKon
“It’s the hard stuff.”“It’s the stuff that will be hard to change”
M.Fowler, cited by J. Highsmith 12
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 7
ISO/IEC 42010
Architecture: the fundamental concepts or properKes of a system in its environment embodied in its elements, their relaKonships, and in the principles of its design and evoluKon
13
SoYware Architecture SoYware architecture encompasses the set of significant decisions about
• the organizaKon of a soYware system, • the selecKon of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboraKon among those elements,
• the composiKon of these elements into progressively larger subsystems,
Grady Booch, Philippe Kruchten, Rich Reitman, Kurt BiCner; RaKonal, circa 1995 (derived from Mary Shaw)
14
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 8
SoYware Architecture (cont.) … • the architectural style that guides this organizaKon, these elements and their interfaces, their collaboraKons, and their composiKon.
• SoYware architecture is not only concerned with structure and behavior, but also with usage, funcKonality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aestheKcs.
15
FuncKons of the soYware architect
Defini1on of the architecture • Architecture definiKon • Technology selecKon • Architectural evaluaKon
• Management of non funcKonal requirements
• Architecture collaboraKon
Delivery of the architecture • Ownership of the big picture • Leadership • Coaching and mentoring • Design, development and
TesKng
• Quality assurance
Brown 2010
16
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 9
FuncKons of the soYware architect
Defini1on of the architecture • Architecture definiKon • Technology selecKon • Architectural evaluaKon
• Management of non funcKonal requirements
• Architecture collaboraKon
Delivery of the architecture • Ownership of the big picture • Leadership • Coaching and mentoring • Design, development and
TesKng
• Quality assurance
Brown 2010
17
3 main boundaries
Architect
B. A.
Developers Project manager
18
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 10
Three main consKtuencies
Architect
Analysts
Developers Project manager
Top management Subcontractors management Airlines, unions, etc.
Subcontractors Technology vendors
Requirements eng. Product & markeKng managers
Customers
Legislators
Domain experts
19
Perceived Tensions Agility-‐ Architecture
AdaptaKon versus AnKcipaKon
Highsmith 2000
20
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 11
Scaling agile
Scope, team size, duraKon • Larger system • Larger teams • Distributed teams • More frequent releases • Over longer Kmeframes
21
Wrong Problem
• Can we scale up agile pracKces?
22
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 12
Wrong Problem
• Can we scale up agile pracKces?
23
Problems
• Can the architecture of the product support mulKple waves of enhancements, to accommodate a constant flow of new needs?
• Can the architecture evolve conKnuously to support enhancements?
• Does the architecture allow teams to organize the work so that they feel as if they were in the “agile sweet spot” and allow them to take advantage of agile pracKces?
• Can the organizaKon avoid the extra work generated by repeKKve handover from a development team to an operaKons group?
24
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 13
Problem (in other words)
1. Agile architecture – Flexible, evolvable architecture, over Kme
2. Agile architecKng – Can we “be agile” while creaKng, evolving an
architecture
Note that (1) does not imply (2), nor vice versa
25
Scale needs architecture
• Work parKKon – decoupling
• Conceptual integrity – Common vocabulary, etc…
• Guide for release planning, configuraKon management
• Address major “iliKes” • Reuse, product line, porLolio, etc.
26
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 14
Architecture benefits from agility
• IteraKve development
• Small increments • Pace decisions • Validate early arch decisions with running testable code, and by building features on it
• Some arch elements may be stubbed
27
Architecture to the rescue
• Common vocabulary • Common culture
The original metaphor as architecture from XP
• Control dependencies: code, data, Kming, requirements
• Keep technical debt in check • Guide release planning and configuraKon
management
28
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 15
Early or late binding decisions?
• Upfront vs. emergent?
• Key quesKons: – How early is “upfront” – How much can you defer?
• Is architecture part of development? – Architecture conjecture (or architecture planning) /= architectural development
29
Early or late binding decisions? and the specter of technical debt
Source: Kruchten, Ozkaya, Nord., 2012
30
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 16
Zipper Model
• From requirements derive: – Architectural requirements – FuncKonal requirements
• Establish – Dependencies – Cost
• Plan interleaving: – FuncKonal increments – Architectural increments
31
Weaving funcKonal and architectural chunks
32
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 17
Benefits
• Gradual emergence of architecture – Deliberate, not accidental (“architecture owner”)
• ValidaKon of architecture with actual funcKonality (not mere hypotheses)
• Early enough to support development – Time pacing
• Not just BUFD • No YAGNI effect
33
Weaving funcKonal and architectural chunks
34
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 18
A more complex story
Architecture of the System
Structure of the Development Organiza1on
Produc1on Infrastructure
36
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 19
3 tures • The Architecture (A) of the system under design, development, or refinement, what we have called the tradiKonal system or soYware architecture
• The Structure (S) of the organizaKon: teams, partners, subcontractors, and others
• The ProducKon infrastructure (P) used to develop and deploy the system, the last acKvity being especially important in contexts where the development and operaKons are combined and the system is deployed more or less conKnuously
37
Architecture of the System
Structure of the Development Organiza1on
Produc1on Infrastructure
Three evolving structures
38
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 20
Architecture of the System
Structure of the Development Organiza1on
Produc1on Infrastructure
Socio-‐technical congruence
Socio-‐technical congruence
39
Socio-‐technical congruence
• A measure of the alignment between technical relaKonships (in the product) and the social relaKonships (in the development organizaKon)
• Conway’s law (1968): “...organizaKons which design systems ... are constrained to produce designs which are copies of the communicaKon structures of these organizaKons.”
40
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 21
Architecture ßà Structure • If architecture (of the system) and the structure (of the organizaKon) are at odds, the structure of the organizaKon wins
• Architecture and structure must co-‐evolve • if they don't, Conway's Law warns us that the organizaKon form will trump intended designs that go "cross-‐grain" to the organizaKon warp.
• System architects (the “architects”) and business/organizaKon architects (the “managers”) should not work as if one has no impact on the other.
41
Architecture of the System
Structure of the Development Organiza1on
Produc1on Infrastructure
Three evolving structures
Socio-‐technical congruence
DevOps
42
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 22
DevOps
43
DevOps
• DevOps is the pracKce of operaKons and development engineers parKcipaKng together in the enKre service lifecycle, from design through the development process to producKon support.
• Kill the silos
hqp://theagileadmin.com/what-‐is-‐devops/
Patrick Debois hqp://www.jedi.be/blog/2010/02/12/what-‐is-‐this-‐devops-‐thing-‐anyway/
44
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 23
DevOps
• Test environment on development not representaKve of the deployment environment
• Data conversion and transfer • ConKnuity of operaKons • RetenKon of personnel, of knowledge • ConKnuous release
45
DevOps and Architecture
• OperaKonal concerns considered early • Break down system in small independent services – Micro-‐service oriented architecture (?)
46
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 24
ConKnuous architecture to emable conKnuous delivery
1. Architect Products – not Projects 2. Focus on Quality Aqributes – not on FuncKonal
Requirements 3. Delay design decisions unKl they are absolutely
necessary 4. Architect for Change – Leverage “The Power of
Small” 5. Architect for Build, Test and Deploy 6. Model the organizaKon of your teams aYer the
design of the system you are working on Source: Pureur & Erder hqp://pgppgp.wordpress.com/
47
TacKcs
• An architectural tacKc is a design opKon for the architect
• Each tacKc is an hypothesis – To be validated by implementaKon, prototyping, tesKng
• Paqerns and frameworks package tacKcs
48
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 25
Example
• Need high availability • Possible tacKc: acKve redundancy • Does acKve redundancy give me the adequate level of availability?
• A paqern that supports availability will ikly use some form of redundancy
49
TacKcs Catalog
• Availability • Interoperability • Modifiability • Performance • Security • Testability • Usability
50
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 26
Deployability tacKcs
• ParameterizaKon • Self-‐monitoring • Self-‐iniKated version update
51
52
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 27
FricKon
“There is sKll much fricKon in the process of craYing complex soYware; the goal of creaKng quality soYware in a repeatable and sustainable manner remains elusive to many organizaKons, especially those who are driven to develop in Internet Kme.”
53
FricKon
“FricKon: the resistance that one surface or object encounters when moving over another.” In soYware development, fricKon is the set of phenomena that limits or constraints our progress, therefore reduces our velocity (or producKvity). Technical debt causes fricKon.
54
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 28
FricKon and Debt
Technical Debt
Social Debt
Fric1on Reduced velocity Defects Delays …
55
Social debt
• Social debt is a state of a development project which is the result of the accumulaKon over Kme of decisions about the way the development team (or community) communicates, collaborates and coordinates.
Tamburri et al. 2013
56
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 29
Social debt
• In other words, decisions about : – the organizaKonal structure, – the process, – the governance, – the social interacKons,
• or some elements inherited through the people: – their knowledge, personality, working style, etc.
Tamburri et al. 2013 57
Parallel Technical & Social Debt
New features Added func1onality
Architectural, Structural features
Defects Technical Debt
Visible Invisible
PosiKve Value
NegaKve Value
58
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 30
Social debt
Community Features
Community Structure
Community Defects
Social Debt
Visible Invisible
PosiKve Value
NegaKve Value
Tamburri et al. 2013
59
To agilely architect an agile architecture • Architecture /= Big Design Up Front – Architecture is development
• Design architecture incrementally … but not in isolaKon from the rest of the system
• Re-‐pay architectural technical debt – As you go, or as needed to not hinder future evoluKon
• Align the organizaKon to match the architecture – Not the opposite
• And use all the agile pracOces you see fit
60
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 31
Architecture of the System
Structure of the Development Organiza1on
Produc1on Infrastructure
Reduce fricKon -‐ Keep them aligned
61
62
Architecture, structure, infrastructure October 24, 2014
Philippe Kruchten 32
References • S. Bellomo, P. Kruchten, R.L. Nord, and I. Ozkaya, "How to agilely
architect an agile architecture?," CuCer IT Journal, vol. 27, no. 2, 2014, pp. 12-‐17
• P. Kruchten, R. Nord, and I. Ozkaya, "Technical debt: from metaphor to theory and pracKce," IEEE So)ware, vol. 29, no. 6, 2012, pp. 18-‐21.
• R. Kazman and P. Kruchten, Design approaches for taming complexity, in IEEE InternaOonal Systems Conference, Alain Beaulieu and George Foster (eds). 2012, IEEE, pp. 519-‐524.
• P. Kruchten, "What do soYware architects really do?," Journal of Systems & So)ware, vol. 81, no. 12, 2008, pp. 2413-‐2416.
• C. Hofmeister, P. Kruchten, R. Nord, H. Obbink, A. Ran, and P. America, "A general model of soYware architecture design derived from five industrial approaches," Journal of Systems & So)ware, vol. 80, 2007, pp. 106-‐126. DOI:10.1016/j.jss.2006.05.024
63
References (cont.) • D. Tamburri, P. Lago, P. Kruchten, and H. van vliet, "What is social debt in
soYware engineering?," presented at CHASE Workshop (part of ICSE), San Francisco, 2013, IEEE Computer Society, pp.93-‐96DOI 10.1109/CHASE.2013.6614739
• Ruth Malan, A trace in the sand, Blog at hqp://www.ruthmalan.com/journal/journalcurrent.htm
• Patrick Debois, DevOps blog at, hqp://www.jedi.be/blog/ • Pierre Pureur, Murat Erder, ConOnuous architecture Blog at hqp://
pgppgp.wordpress.com/ • M. E. Conway, "How do commiqees invent?," DatamaOon, vol. 14(4), pp.
28-‐31, 1968.
64