What do soware architects do? March 2013

Philippe Kruchten, Ph.D., P.Eng., CSDP Professor of Soware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering University of Brish Columbia Vancouver, BC Canada [email protected]

Founder and president What do soware architects do? Kruchten Engineering Services Ltd Vancouver, BC Canada Philippe Kruchten [email protected] UBC EECE417 March 19, 2013

General Outline Architecture

• An example Yes, but what flavour? • Defining Soware Architecture • System architecture • Role of the Architect • Enterprise architecture • Architects and other stakeholders • Business architecture • What do soware architects do? • Soware architecture • Service-oriented architecture • Informaon architecture • Soluon architecture

ISO/IEC 42010 Soware Architecture Soware architecture encompasses the set of significant decisions about • the organizaon of a soware system, Architecture: the fundamental concepts or • the selecon of the structural elements and their interfaces by which the system is properes of a system in its environment composed together with their behavior as embodied in its elements, their relaonships, specified in the collaboraon among those and in the principles of its design and elements, evoluon • the composion of these elements into progressively larger subsystems,

Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Biner; Raonal, circa 1995 (derived from Mary Shaw)

Philippe Kruchten 1 What do soware architects do? March 2013

Soware Architecture (cont.) An example: CAATS

… • Canadian Automated Air Traffic System • the architectural style that guides this • Basis for line of product of Automated Air Traffic Services organizaon, these elements and their interfaces, • Inial Deployment in Canada their collaboraons, and their composion. • Esmated 750 KLOC, Ada (2% C++) (1st release) • Soware architecture is not only concerned with • Mulple target plaorms structure and behavior, but also with usage, • Distributed system funconality, performance, resilience, reuse, • $800 Million comprehensibility, economic and technological • 150 soware constraints and tradeoffs, and aesthecs. developer

CAATS Context CAATS Context

1. Size Size 1. Size : 1-2.5 million lines of code Age of Cricality 2. Cricality System 2. Cricality : high (100’s die) 3. Age of system 3. Age of system : 0 (no legacy nor reuse)

4. Rate of change Rate of Business 4. Rate of change : Low Context 5. Business model change model 5. Business model : government contract, ++ 6. Stable architecture 6. Stable architecture : No architecture at D=0 Stable Governance 7. Team distribuon Architecture 7. Team distribuon : 5 sites (3 TZ) then 1 then 3 8. Governance Team 8. Governance : Complex Distribuon

Issues in early 1992 1992: reset

Architecture • 1 main contractor • Move all teams on one site • 4 subcontractors • Adopt an iterave development process • 5 sites • Use an OOAD method a • No architecture… • Create an architecture team b • Waterfall process, c • Restart the requirement gathering driven by DoD 2167a d • Bring the “customer on site” e • Can Govt holds an $80M downpayment • … and convince the government to proceed

Philippe Kruchten 2 What do soware architects do? March 2013

Architectural Effort During the Lifecycle Iteraons and Phases Inception Elaboration Construction Transition

Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration

Inception Elaboration Construction Transition

time Internal Releases with Releases with main focus on architecture focus on features Majority of architectural design activities

An architectural iteration focuses in putting in place major architectural elements, resulting in a baseline architectural prototype at the end of elaboration.

CAATS meline (up to release 1) Team Structure over Time Inception Elaboration Construction and Transition • Elaboraon: – 3 iteraons, 6 months each Management team Management team • Construcon: Architecture team – 4 iteraons, +/- 6 months each Architecture Feature team 1 • Transion: team Initial team – 2+ iteraons Feature team 2 Prototyping team Infrastructure Feature team 3 team A • So another 5 years or so…. Infrastructure team B

integration team

M. Vitruvius Pollio, De Architectura

• [The architect] should be a man of leers, a skilful draughtsman, a mathemacian, familiar with historical studies, a diligent student of philosophy, acquainted with music; not ignorant of medicine, learned in the responses Role of the architect of jurisconsults, familiar with astronomy and astronomical calculaons.

Philippe Kruchten 3 What do soware architects do? March 2013

Role versus Person Mapping Roles to Persons

• Role defined by: • How many hats do you wear today? – Acvies – Responsibilies • Small teams: many roles – Competencies per person • Persons (individuals) have: • Larger team: greater – Competencies specializaon – Availability • – All needed roles Cost, locaon (acvies) have to be – Taste, interest ? covered.

Roles of the Architect Charter of the Architecture Team

• Visionary – Shaper • Defining the architecture of the system • Designer – making choices • Maintaining the architectural integrity of the system • Assessing technical risks • Communicator – between mulple pares • Working out risk migaon strategies/approaches • Troubleshooter • Parcipaon in project planning • Herald – window of the project • Proposing order and content of development iteraons • Consulng with design, implementaon, and integraon teams • Janitor – cleaning up behind the PM and the • Assisng product markeng and future product definions developers

Kruchten 1992

Two styles of soware/system Funcons of the soware architect architects

Definion of the architecture Delivery of the architecture • Maker and Keeper of Big • Mentor, Troubleshooter, • Architecture definion • Ownership of the big picture decisions and Prototyper • • Technology selecon Leadership – Bring in technological – Implements and try • Architectural evaluaon • Coaching and mentoring changes architecture • Design, development and – External collaboraon – Intense internal collaboraon • Management of non Tesng – More requirements-facing – More code-facing funconal requirements – Gatekeeper • • Architecture collaboraon Quality assurance – Fowler: Architectus reloadus – Fowler: Architectus Aryzus

Brown 2010 Fowler 2004 Only big new projects need both or separate people

Philippe Kruchten 4 What do soware architects do? March 2013

Team Structure A. Reloadus and A. Oryzus ecological niches Inception Elaboration Construction and Transition Inception Elaboration Construction and Transition

Management team Management team Management team Management team

Architecture team A. Reloadus Architecture team

Architecture Feature team 1 Architecture Feature team 1 team team Initial team Initial team Feature team 2 Feature team 2

Prototyping team Infrastructure Feature team 3 Prototyping team Infrastructure Feature team 3 team A team A Infrastructure Infrastructure team B team B

integration team A. Aryzus integration team

A. Reloadus and A. Oryzus ecological niches Architect internal focus

Inception Elaboration Construction and Transition A. Reloadus Management team Management team

Architecture team

Architecture Feature team 1 team Initial team Feature team 2

Prototyping team Infrastructure Feature team 3 team A Infrastructure team B A. Aryzus Brown 2010 integration team

Architect external focus Skills of an Architect

• Architect must be capable of abstract thinking – Not at the expense of understanding the details – Able to move effortlessly between levels of abstracon – “Big picture” person • Architect must be an excellent communicator – Writer – Presenter – Moderator – Listener – Negoator (continued) Brown 2010 “The Software Architect”; Philippe Kruchten, TC2 First Working IFIP Conference on Software Architectures, KLUWER ACADEMIC PUBLISHERS

Philippe Kruchten 5 What do soware architects do? March 2013

Skills of an Architect (2) Skills of an Architect (3)

• Architect must be capable of coping with • Architect must be able to admit making sub- ambiguies and contradicons opmal decisions – Engineers are trained to eliminate ambiguies while an architect must move forward accepng – Other stakeholders will probably classify these ambiguies decisions as mistakes • Architect must be capable of managing and • Architect must have a strong convicon/vision handling mulple, concurrent issues – Must believe in what they are doing – This skill is not a part of standard engineering training (continued) • Architect must be able to rearrange priories as situaon changes (continued)

Skills of an Architect (4) Charter of the Architecture Team

• Architect must understand technology very well • Defining the architecture of the system – Not at the same level as engineers • Maintaining the architectural integrity of the system – Must be able to review and understand technical • Assessing technical risks work • Working out risk migaon strategies/approaches • Architect must understand soware • Parcipaon in project planning development processes • Proposing order and content of development iteraons • Architect must understand the domain • Consulng with design, implementaon, and integraon teams – Does not have to be a domain expert • Assisng product markeng and future product definions • Architect must have a balance of development, technology, and domain knowledge

What do architects actually do: What do architects actually do? [70,15,15] Architecting: Getting input: -design -user, requirement -validation -other architecture -prototyping -technology -documenting 50% 70% -etc…. 25% 15%

15% 25%

Providing Information -communicating architecture Kruchten 2008 -assisting other stakeholders

Philippe Kruchten 6 What do soware architects do? March 2013

What do architects actually do: What do architects actually do: [30,40,30] [60,30,10]

40% 30% 30% 60% 30% 10%

Kruchten 2008 Kruchten 2008

What do architects actually do: [25,25,50]

25% Architects and the other roles

25%

50% Interacons and responsibilies of the other stakeholders vis-à-vis the architect

Kruchten 2008

Architecng Is About Tradeoffs The Architect’s Balancing Act Between Forces End-user Ease of integration Functionality

Functionality Ease of use Sales and field Customer support Process Technology Ease of customization

Reliability

Price Development manager Development costs, skills

Qualities Complexity On time delivery

Maintainer Developer Performance and throughput

Stability and maintainability Architect Ease of diagnosing problems System Ease of introducing modifications Skills Organization and Culture administrator Testability and tractability

Booch 1998 Business Concerns Structure and dependencies between parts

Ease of installation

Philippe Kruchten 7 What do soware architects do? March 2013

Three key relaonships Business Analysis

• Architect – Business analyst • Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the • Architect – Project manager structure, policies and operaons of an organizaon, and recommend soluons that enable the organizaon to achieve its goals.

• Architect - Developer BABOK v2 2009

Soware Architect & Project Manager Three Main Constuencies • Director • Producer – Story – Plans Analysts – Script – Budget – Set design – Resources – Costumes – Staff – Actors – Communicaons Architect – Direcng – External affairs

Project – Eding – Logiscs Developers manager The Hollywood Metaphor

Three main boundaries Note

• Not an organizaon chart B. A. • There are other communicaon or reporng channels

B. A. Architect

Project Architect Developers manager Project manager Developers

Philippe Kruchten 8 What do soware architects do? March 2013

3 main boundaries Three main constuencies Customers Domain experts Requirements eng. Product & markeng managers B. A. Legislators

Analysts

Architect Architect

Project Developers manager Project Developers manager Top management Subcontractors Subcontractors management Technology vendors Airlines, unions, etc.

Main boundaries (1) Main boundaries (2)

B. A. Analysts

Resources Needs “Time-box” Requirements Opportunies Release plan NFR Priories Architect Cost Project manager Developers Project Risks Developers manager Architect technical programmac Work paroning Dev costs

Main boundaries (3) Translaon

B. A. B. A. Terminology Abstracon level Volume “The Seam” Emphasis Constraints Decisions Architect Interfaces Stuff to use Architect

Prototypes Project Project Evaluaon Developers Developers manager Costs manager “push back”

Philippe Kruchten 9 What do soware architects do? March 2013

Translaon - Coordinaon Proximity - Formalism

Developers B. A. 1

B. A.

B. A. Architect Architect Developers Architect Project Project Developers Developers manager manager 2

Project Developers Aloof management manager 3 The small cohesive team

Proximity - Formalism Proximity - Formalism

B. A. B. A. B. A.

Architect Developers 1 Developers Architect Architect Project Project Developers manager manager Developers 2 Project manager

Architects too remote from developers A favourite development team

FBS in Soware Engineering FBS and Soware Architecture

Coding Refactoring S Synthesis Arch. Constrains F a Design Architectural S S Synthesis Requirement Review Release Architectural Elicitaon Test Analysis Analysis Architectural Evaluaon D Evaluaon Be Bs Bae Bas Arch. Formulaon Funconal Reseng Evaluaon Reformulaon Expectaons Be Bs Source: Hofmeister, Kruchten, et al., 2005, 2007 Source: Kruchten, 2005

Philippe Kruchten 10 What do soware architects do? March 2013

Architectural Design Architecng is making decisions

Architectural Assets ArchitectureArchitecture

IdeasIdeas Architectural Synthesis The life of a soware architect is a long (and Backlog somemes painful) succession of subopmal Context, Constraints decisions made partly in the dark.

Architectural Architectural Analysis Evaluaon

Architecturally Evaluaon results Significant Requirements Source: Hofmeister, Kruchten, et al., 2005, 2007

CAATS: Elaboraon Iteraon 1 CAATS: Elaboraon Iteraon 2 • 4 crical use cases – Entry of a flight plan • 20 crical and important use cases (selected – Entry of a clearance scenarios) – Entry of a posion report by a controller – More coverage – Recepon of a radar posion report • Selecon of COTS products (mechanisms) • Main mechanisms put in place – Middleware (UNAS) and GUI – Error handling • Steep learning curve – Distributed objects – Team building – Persistency – Air Traffic Control domain – Language and development environment – Time management – Design methods • 50 KSLOC developed • 10 KSLOC developed

CAATS: Elaboraon Iteraon 3 CAATS: Following Iteraons • 71+ use cases (selected scenarios) • 55+ use cases (selected scenarios) • Architecture tune-up based on experimentaon and measurement of performance • Requirements ‘finalized’ – Subsystems merged or split • More mechanisms put in place – Processes merged – Database access – Finer granularity of object specificaon – Fault-tolerance mechanism • Addional mechanisms for – Persistency • Complete architectural coverage – Logical names – Simulaon – Parameterizaon • Interfaces stabilized

Philippe Kruchten 11 What do soware architects do? March 2013

Architecture Arfacts The 4+1 view model of architecture

End-user, designers Programmers Funconality Soware management

Implementaon Analysis Model Design Model Deployment Model Logical View View Implementation Model Users/Analysts/Testers Use Case Behavior View Process Deployment Software Architecture View View Document Architects * Architecture Notes System Integrators System Engineering Performance System topology Scalability Delivery, installaon * Architectural * Architecture Throughput Communicaon Design Guidelines Prototype Presentation Kruchten 1995 Programming Guidelines

Architectural Modeling Process 10 UML Diagrams Activity Diagram Business Business Use Cases - Activities constraints… Sequence Diagram

High Level Use Case Diagram Interaction Diagram (Scenarios) Collaboration Diagram Use Cases Scenarios

Classes Objects Class Diagram (static part of class) Object Diagram System Abstraction Instance State-Transition Diagram (behavioral part of class) Sources Processes

Patterns Component Diagram (Sources & Processes) Reusable assets Processors

Low Level Deployment Diagram (Processors)

The Soware Architect… References § Bass, L., Clements, P., & Kazman, R. (2003). Soware Architecture in Pracce (2nd ed.). Reading, MA: Addison-Wesley. • A role, more than a person: § Brown, S. (Feb. 9, 2010) Are you an architect?, InfoQ – Competence, responsibility, acvity hp://www.infoq.com/arcles/brown-are-you-a-soware-architect. § Fowler, M. (2003). Who needs an architect? IEEE Soware, 20(4), 2-4. • Importance varies greatly across the spectrum § Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE of soware development projects: Soware, 12(6), 45-50. § Kruchten, P. (1999). The Soware Architect, and the Soware – Size, novelty, cricality, volality, … Architecture Team. In P. Donohoe (Ed.), Soware Architecture (pp. 565-583). Boston: Kluwer Academic Publishers. • Intersecon between 3 main funcons or § Kruchten, P. (2008). What do soware architects really do? Journal of roles in a development organizaon Systems & Soware, 81(12), 2413-2416. § Rozanski, N., & Woods, E. (2005). Soware Systems Architecture: – Management, Definion, Development Working With Stakeholders Using Viewpoints and Perspecves. Boston: Addison-Wesley. • “Architecture owner” § Vitruvius Pollio, M. (25 B.C.). De Architectura. § Wachowski, A., & Wachowski, L. (Writer) (2003). The Matrix Reloaded. Warner Bros.

Philippe Kruchten 12