Architecture, structure, infrastructure October 24, 2014 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] Copyright © 2014 Philippe Kruchten 2 Philippe Kruchten 1 Architecture, structure, infrastructure October 24, 2014 Outline • Architecture • Architects • Agile and architecture (!?) • Scaling agile • Socio-technical congruence • Connuous delivery • The advent of DevOps • Reducing fricKon 3 Architecture Yes, but What flavour? • System architecture • Enterprise architecture • Business architecture • SoYWare architecture • Service-oriented architecture • Informaon architecture • SoluKon architecture 4 Philippe Kruchten 2 Architecture, structure, infrastructure October 24, 2014 Business Architecture • A subset of the enterprise architecture that defines an organizaon’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 organizaon’s acKviKes. BABOK v2 2009 5 Enterprise Architecture • Enterprise architecture is a descripKon of an organizaon’s business processes, IT soYWare and hardWare, people, operaons and projects, and the relaonships between them. Source BABOK v2 2009 6 Philippe Kruchten 3 Architecture, structure, infrastructure October 24, 2014 SoluKon architecture • System architecture • SoYWare architecture 7 TWo Main Cultures Solu1on Architect Enterprise Architect • Authority • Advisor / Consultant • Technical Decision Maker • Building Bridges • Requirements è Architecture • Business / IT Alignment • Single “problem” • Governance over mulKple • “Building Design” “problems” • “City Planning” • References: – SEI: ATAM, CBAM, QAW • References: – RUP: 4+1 VieWs – Zachman – Fowler: Architectus Oryzus – TOGAF, DODAF – IEEE 1471 – DYA, IAF, GEM, BASIC,… – IEEE 1471 Source Eltjo Poort 8 Philippe Kruchten 4 Architecture, structure, infrastructure October 24, 2014 SoYWare Architecture System Enterprise Architecture Architecture Source Eltjo Poort 9 Architectural Styles, Genres, Paerns, Mechanisms,… • Layered architecture • Client-server architecture • Service-oriented architecture 10 Philippe Kruchten 5 Architecture, structure, infrastructure October 24, 2014 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 Philippe Kruchten 6 Architecture, structure, infrastructure October 24, 2014 ISO/IEC 42010 Architecture: the fundamental concepts or properKes of a system in its environment embodied in its elements, their relaonships, and in the principles of its design and evoluKon 13 SoYWare Architecture SoYWare architecture encompasses the set of significant decisions about • the organizaon 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 collaboraon among those elements, • the composion of these elements into progressively larger subsystems, Grady Booch, Philippe Kruchten, Rich Reitman, Kurt BiCner; Raonal, circa 1995 (derived from Mary Shaw) 14 Philippe Kruchten 7 Architecture, structure, infrastructure October 24, 2014 SoYWare Architecture (cont.) … • the architectural style that guides this organizaon, these elements and their interfaces, their collaboraons, 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 Definion of the architecture Delivery of the architecture • Architecture definiKon • Ownership of the big picture • Technology selecon • Leadership • Architectural evaluaon • Coaching and mentoring • Design, development and • Management of non Tesng funcKonal requirements • Architecture collaboraon • Quality assurance Brown 2010 16 Philippe Kruchten 8 Architecture, structure, infrastructure October 24, 2014 FuncKons of the soYWare architect Definion of the architecture Delivery of the architecture • Architecture definiKon • Ownership of the big picture • Technology selecon • Leadership • Architectural evaluaon • Coaching and mentoring • Design, development and • Management of non Tesng funcKonal requirements • Architecture collaboraon • Quality assurance Brown 2010 17 3 main boundaries B. A. Architect Project Developers manager 18 Philippe Kruchten 9 Architecture, structure, infrastructure October 24, 2014 Three main consKtuencies Customers Domain experts Requirements eng. Product & markeKng managers Legislators Analysts Architect Project Developers manager Top management Subcontractors Subcontractors management Technology vendors Airlines, unions, etc. 19 Perceived Tensions Agility- Architecture Adaptaon versus AnKcipaon Highsmith 2000 20 Philippe Kruchten 10 Architecture, structure, infrastructure October 24, 2014 Scaling agile Scope, team size, duraon • Larger system • Larger teams • Distributed teams • More frequent releases • Over longer Kmeframes 21 Wrong Problem • Can We scale up agile pracKces? 22 Philippe Kruchten 11 Architecture, structure, infrastructure October 24, 2014 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 organizaon avoid the extra Work generated by repeKKve handover from a development team to an operaons group? 24 Philippe Kruchten 12 Architecture, structure, infrastructure October 24, 2014 Problem (in other Words) 1. Agile architecture – Flexible, evolvable architecture, over Kme 2. Agile architecKng – Can We “be agile” While creang, 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, configuraon management • Address major “ilies” • Reuse, product line, porLolio, etc. 26 Philippe Kruchten 13 Architecture, structure, infrastructure October 24, 2014 Architecture benefits from agility • Iterave 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 configuraon management 28 Philippe Kruchten 14 Architecture, structure, infrastructure October 24, 2014 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 Philippe Kruchten 15 Architecture, structure, infrastructure October 24, 2014 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 Philippe Kruchten 16 Architecture, structure, infrastructure October 24, 2014 Benefits • Gradual emergence of architecture – Deliberate, not accidental (“architecture oWner”) • Validaon 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 Philippe Kruchten 17 Architecture, structure, infrastructure October 24, 2014 A more complex story Architecture of the System Structure of the Producon Development Organizaon Infrastructure 36 Philippe Kruchten 18 Architecture, structure, infrastructure October 24, 2014 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 organizaon: teams, partners, subcontractors, and others • The Producon infrastructure (P) used to develop and deploy the system, the last acKvity being especially important in contexts Where the development and operaons are combined and the system is deployed more or less conKnuously 37 Three evolving structures Architecture of the System Structure of the Producon Development Organizaon Infrastructure 38 Philippe Kruchten 19 Architecture, structure, infrastructure October 24, 2014 Socio-technical congruence Architecture of the System Socio-technical congruence Structure of the Producon Development Organizaon Infrastructure 39 Socio-technical congruence • A