About So(ware Architecture Ruben Gonzalez Blanco firstname.lastname@example.org @_rubengb Telefonica I+D
How the industry understands So(ware Architecture
SEI The so(ware architecture of a program or compuFng system is a depic(on of the system that aids in the understanding of how the system will behave.
So(ware architecture serves as the blueprint for both the system and the project developing it, deﬁning the work assignments that must be carried out by design and implementaFon teams. The architecture is the primary carrier of system quali(es such as performance, modiﬁability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an arFfact for early analysis to make sure that a design approach wil yield an acceptable system.
SEI SoAware Engineering Ins(tute
MSDN So(ware applicaFon architecture is the process of deﬁning a structured solu(on that meets all of the technical and opera(onal requirements, while op(mizing common quality aCributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the applicaFon.
Len Bass, Paul Clements, and Rick Kazman, So(ware Architecture in PracFce, Second EdiFon The so(ware architecture of a program or compuFng system is the structure or structures of the system, which comprise soAware elements, the externally visible proper(es of those elements, and the rela(onships among them.
“Externally visible” properFes are those assumpFons other elements can make of an element, such as its provided services, performance characterisFcs, fault handling, shared resource usage, and so on.
—Len Bass, Paul Clements, and Rick Kazman, So(ware Architecture in PracFce, Second EdiFon
IEEE The highest level concept of a system in its environment [IEEE]. The architecture of a so(ware system (at a given point in Fme) is its organiza(on or structure of signiﬁcant components interac(ng through interfaces, those components being composed of successively smaller components and interfaces
RUP The organiza(onal structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, rela(onships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems.
Philippe Kruchten, Grady Booch, Kurt BiZner, and Rich Reitman Philippe Kruchten, Grady Booch, Kurt BiZner, and Rich Reitman derived and reﬁned a deﬁniFon of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their deﬁniFon is:
SoAware architecture encompasses the set of signiﬁcant decisions about the organizaFon of a so(ware system including the selecFon of the structural elements and their interfaces by which the system is composed; behavior as speciﬁed in col aboraFon among those elements; composi(on of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organizaFon. So(ware architecture also involves funcFonality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoﬀs and aestheFc concerns
Bass, Clements, and Kazman In So(ware Architecture in PracFce (2nd ediFon), Bass, Clements, and Kazman deﬁne architecture as fol ows:
“The so(ware architecture of a program or compuFng system is the structure or structures of the system, which comprise so(ware elements, the externally visible properFes of those elements, and the rela(onships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementaFon—are not architectural.”
My 3 preferred views about So(ware Architecture
Philippe Krutchen An architecture is the set of signiﬁcant decisions about the organiza(on of a soAware system, the selecFon of structural elements and their interfaces by which the system is composed, together with their behavior as speciﬁed in the collabora(ons among those elements, the composiFon of these elements into progressively larger subsystems, and the architectural style that guides this organizaFon - ‐- ‐ these elements and their interfaces, their col aboraFons, and their composiFon. [Kruchten]4
MarFn Fowler MarFn Fowler outlines some common recurring themes when explaining architecture. He idenFﬁes these themes as:
“The highest- ‐level breakdown of a system into its parts; the decisions that are hard to change; there are mulFple architectures in a system; what is architecturally signiﬁcant can change over a system's lifeFme; and, in the end, architecture boils down to whatever the important stuﬀ is.”
Simon Brown hZp://www.codingthearchitecture.com/
Do we really understand what So(ware Architecture is? Personal understanding……
First : Is it “Architecture” a good name?
Building ConstrucFon Analogy FAIL : So(ware has both Structure (sta(c) and Behavior (dynamic)
So(ware, like Music is “Composed” Computer vs Music Player Programing vs Composing Execu(on along (me
Harmony and Melody The HARMONY provides the base for the MELODY Harmony is transversal to the music Melodies
JAZZWARE So(ware Architecture = So(ware Harmony See the lower case ‘a’ So(ware Programmers = So(ware Melody Composers So(ware Architect = So(ware Harmonist = So(ware Harmony ComposSeee r the lower case ‘a’
So(ware Harmony is about Conceptual Integrity Anywhere you look in your system, you can tel that the design is part of the same overall design style, theme, mood …is about Design and Style Consistency in all dimensions of the system User interface, technologies, coding styles, naming convenBons, directory structures, classes, components, interfaces, internal and external behavior, deployment… Fed Brooks: “It is be0er to have a system...reﬂect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas” The Mythical Man- ‐Month Conceptual Integrity tries to limit the system complexity Conceptual Integrity simpliﬁes col aboraFon when creaFng so(ware
Conceptual Integrity examples • Unix • based on the noFon of a "ﬁle” (e.g. directories, devices, ﬁlesystems, named pipes and sockets are all sort- ‐of ﬁles) • Smalltalk • "everything is an object", and the small set of other accompanying principles • SQL • "all data is in tables", with keys and constraints • Lisp • "everything is a list” h0p://c2.com/cgi/wiki?ConceptualIntegrity
Not having Conceptual Integrity leads to chaoFc systems MulFple minds working in complex system without unity and conceptual integrity
7 Dimensions x 2* of a So(ware Work where Harmony must be created al Logic Logical Implementation Dimension Dimension Solu%on Vision Implementa%on Structure and Classes, Modules, Design Components, Components Interfaces, Interac%ons Frameworks, Libraries So:ware Mechanisms Base Technologies, Programming Languages So:ware Mechanisms Data Environment Dimension External Dimension Dimension Environments Data En%%es Use Cases / User Stories Tools Data Messages UX Guidelines Development Process, Methods and Prac%ces Process Deployment Dimension Dimension Run%me Processes, Threads Infrastructure, Hardware and Protocols, Inter- ‐process Communica%on, Network Topology Integra%ons Ph ysica *STRUCTURE and BEHAVIOUR l
Desired AZributes of a So(ware Work High Cohesion each part/element is narrowed focused in its primary task
Low Coupling each part is self- ‐contained/orthogonal achieved thru separaFon of concerns and encapsulaFon
Conceptual Integrity there is a consistent design* and style across all so(ware dimensions (*) programming is design Source: “The Art in Computer Programming”, By Andrew Hunt and David Thomas
So(ware Architecture = So(ware Harmony A So(ware Architecture (Harmony) is the set of signiﬁcant decisions and their implementa(on in the 7 realizaFon dimensions of the so(ware system considering structure and behaviour dimensions in each one with the purpose of achieving conceptual integrity, low coupling and high cohesion
The So(ware Harmony is Coded So(ware Mechanisms (so(ware soluFons to common problems: persistence, IPC, … System Skeleton (interfaces, base components, deployment mechanisms ) Prototypes, Reference soluFons and Proof of Concepts (soluFons to signiﬁcant user stories or technical problems) Base frameworks and technologies Base Guidelines and Styles …
Good PracFce : The So(ware Harmony is usually Visually Modeled (structure and behavior) But the “architecture” is not the Diagrams • UML • Sketches
The role of a So(ware Harmonist
Achieving Conceptual Integrity FredBrooks: "Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds" Aristocracy vs Democracy?
“TradiFonal” So(ware Architect architect derives from the LaFn architectus, which derives from the Greek arkhitekton (arkhi- ‐, chief + tekton, builder), i.e., chief builder
Bad So(ware Architect ConcepFon
BeZer So(ware Architect ConcepFon SFl can be improved
So(ware Harmonist = Technical Leader es es
ses rvic dules kag Se Mo Pac Clas Code Breadth & Depth 7 Dimensions Logical( Implementation (Dimension Dimension Implementa=on'Structure' Classes,'Modules,'Design' and'Components' Components,'Interfaces Frameworks,'Libraries' Base'Technologies,' Programming'Languages Data Environment Dimension External Dimension Dimension Environments' Data'En==es' Use'Cases'/'User'Stories' Tools' Data'Messages' UX'Guidelines' Development'Process,' Methods'and'Prac=ces' Process Deployment ( Dimension Dimension Run=me'Processes,'Threads'' Infrastructure,'Hardware'and' Protocols,' InterAprocess' Network'Topology' Communica=on'
So(ware Harmonist = Technical Leader or Development Leader • Is able to compose and play So(ware • is hands on
• Guides, Coaches and Leads other So(ware Composers • is a reference
So(ware Harmonist = Technical Leader or Development Leader • Keeps Conceptual Integrity and Unity across the system and teams, while limiFng complexity
• Retains the ﬁnal say in technical disputes or arguments within the team(s) Smal teams with resonant minds could not need an speciﬁc tech leader
ElaboraFng So(ware Harmony
From IntenFonal to Emerging • IntenFonal harmony (architecture) is explicitly idenFﬁed and then implemented
• Accidental harmony (architecture) emerges from the mulFtude of individual design decisions that occur during development, only a(er which can we name that architecture EMERGENT Logical( Implementation (Dimension Dimension Implementa=on'Structure' Classes,'Modules,'Design' and'Components' Components,'Interfaces Frameworks,'Libraries' Base'Technologies,' Programming'Languages Data Environment INTENTIONAL Dimension External Dimension Dimension Environments' Data'En==es' Use'Cases'/'User'Stories' Tools' Data'Messages' UX'Guidelines' Development'Process,' Methods'and'Prac=ces' Process Deployment ( Dimension Dimension Run=me'Processes,'Threads'' Infrastructure,'Hardware'and' Protocols,' InterAprocess' Network'Topology' Communica=on' Agile Project Kickoff I1 I2 I3 Agile Project Kickof I1 I2 I3 I4 I5 time time Management team Management team Feature 1 Team Init Feature2 Team In ial itia te l pr am Architecture team oject GROWING team Inintiala te praom Architecture team ject Prototyping team team Prototyping team Prototyping team Infraestructure Team
So(ware Harmony(architecture) is Elaborated, Built, Used and Executed Architecture=Harmony is created as set of subopFmal design decisions that can be re- ‐factor later on Building the Harmony Using Building Using ….. Sprint0 SP1 SP2 SP3 SP4 SP5 SP6 SP7 SP8 SP9
nFonal ergent nFonal ergent te te In Em In Em
The Dilemma Solu%on : Assuring Conceptual Integrity via Capacity Alloca%on to architecture = Harmony Source: Dean Leﬃnweel , h0p://scaledagileframework.com/guidance/assuring- ‐architectural- ‐integrity- ‐via- ‐capacity- ‐ al ocaBon/