About  So(ware  Architecture   Ruben  Gonzalez  Blanco   [email protected]   @_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,  defining  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,  modifiability,  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  will  yield  an  acceptable  system.     SEI  SoAware  Engineering  Ins(tute   

MSDN   So(ware  applicaFon  architecture  is  the  process  of  defining  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.     MSDN   

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  significant   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  refined  a   definiFon  of  architecture  based  on  work  by  Mary  Shaw  and  David  Garlan  (Shaw  and   Garlan  1996).  Their  definiFon  is:     SoAware  architecture  encompasses  the  set  of  significant  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  specified  in  collaboraFon   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,  tradeoffs  and  aestheFc   concerns   

Bass,  Clements,  and  Kazman     In  So(ware  Architecture  in  PracFce  (2nd  ediFon),  Bass,  Clements,  and  Kazman   define  architecture  as  follows:     “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.”   

Architecture  DefiniFon   

My  3  preferred  views  about  So(ware  Architecture   

Philippe  Krutchen   An  architecture  is  the  set  of  significant  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  specified  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  collaboraFons,  and   their  composiFon.  [Kruchten]4   

MarFn  Fowler   MarFn  Fowler  outlines  some  common  recurring  themes  when  explaining  architecture.   He  idenFfies  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  significant   can  change  over  a  system's  lifeFme;  and,  in  the  end,  architecture  boils  down  to   whatever  the  important  stuff  is.”     

hZp://www.codingthearchitecture.com/   Simon  Brown   

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  Systems  Emerge   (Big  Up  Front  Designs)     Both  SpecificaFons  and  Architecture  Emerge  and  Grow  along  the  process  of  so(ware       System  “Specs”   Architecture   SoAware  System   Idea   Need   Problem   IntenFonal   Emergent   Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' 

A  beZer  “Analogy”?   

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   

So(ware  Architect    =  So(ware  Harmonist    =  So(ware  Harmony  Composer     See  the  lower  case  ‘a’   So(ware  Programmers  =     So(ware  Melody  Composers   JAZZWARE   So(ware  Architecture  =  So(ware  Harmony   See  the  lower  case  ‘a’   

So(ware  Harmony  is  about   Conceptual  Integrity   Anywhere  you  look  in  your  system,  you  can  tell  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   Fed  Brooks:    “It  is  be0er  to  have  a  system...reflect  one  set  of  design  ideas,  than  to  have  one   that  contains  many  good  but  independent  and  uncoordinated  ideas”     User  interface,  technologies,  coding  styles,  naming  convenBons,  directory  structures,   classes,  components,  interfaces,  internal  and  external  behavior,  deployment…   Conceptual  Integrity  tries  to  limit  the  system  complexity   Conceptual  Integrity  simplifies  collaboraFon  when  creaFng  so(ware   The  Mythical  Man-­‐Month   

Conceptual  Integrity  examples   •  Unix     •  based  on  the  noFon  of  a  "file”  (e.g.  directories,  devices,   filesystems,  named  pipes  and  sockets  are  all  sort-­‐of  files)   •  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   Process Dimension Deployment   Dimension Logical    Dimension External Dimension Implementation Dimension Solu%on  Vision   Classes,  Modules,  Design    Components,   Interfaces,  Interac%ons   So:ware  Mechanisms   Use  Cases  /  User  Stories   UX  Guidelines   Run%me  Processes,  Threads     Protocols,    Inter-­‐process  Communica%on,   Integra%ons   Implementa%on  Structure  and   Components   Frameworks,  Libraries   Base  Technologies,  Programming   Languages   So:ware  Mechanisms   Infrastructure,  Hardware  and   Network  Topology   Data Dimension Environment Dimension Environments   Tools   Development  Process,   Methods  and  Prac%ces   Data  En%%es   Data  Messages   Logical   Physical   *STRUCTURE  and  BEHAVIOUR   

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  significant  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  significant  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)   •  UML   •  Sketches   But  the  “architecture”  is  not  the  Diagrams   

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   SFll  can  be  improved   

So(ware  Harmonist  =  Technical  Leader   Services   Modules   Packages   Classes   Code   Breadth  &  Depth   Process Dimension Deployment ( Dimension Logical( (Dimension External Dimension Implementation Dimension Classes,'Modules,'Design'' Components,'Interfaces Use'Cases'/'User'Stories' UX'Guidelines' Run=me'Processes,'Threads'' Protocols,''InterAprocess' Communica=on' Implementa=on'Structure' and'Components' Frameworks,'Libraries' Base'Technologies,' Programming'Languages Infrastructure,'Hardware'and' Network'Topology' Data Dimension Environment Dimension Environments' Tools' Development'Process,' Methods'and'Prac=ces' Data'En==es' Data'Messages' 7  Dimensions 

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  final  say  in  technical  disputes  or  arguments  within   the  team(s)   Small  teams  with  resonant  minds  could  not  need  an   specific  tech  leader   

ElaboraFng  So(ware  Harmony   

From  IntenFonal  to  Emerging   Initial team Agile Project Kickoff Management team Architecture team time Initial project team Prototyping team I1 I2 I3 Initial team Agile Project Kickoff Management team Architecture team time Initial project team Prototyping team I1 I2 I3 Feature 1 Team Feature2 Team Infraestructure Team I4 I5 Prototyping team •  IntenFonal  harmony  (architecture)    is  explicitly  idenFfied  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   Process Dimension Deployment ( Dimension Logical( (Dimension External Dimension Implementation Dimension Classes,'Modules,'Design'' Components,'Interfaces Use'Cases'/'User'Stories' UX'Guidelines' Run=me'Processes,'Threads'' Protocols,''InterAprocess' Communica=on' Implementa=on'Structure' and'Components' Frameworks,'Libraries' Base'Technologies,' Programming'Languages Infrastructure,'Hardware'and' Network'Topology' Data Dimension Environment Dimension Environments' Tools' Development'Process,' Methods'and'Prac=ces' Data'En==es' Data'Messages' INTENTIONAL   EMERGENT   GROWING   

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   SP1 SP2 SP3 SP4 SP5 SP6 SP7 SP8 Sprint0 SP9 Building  the  Harmony   Using   Building   ….. Using   IntenFonal   Emergent   IntenFonal   Emergent   

The  Dilemma   Solu%on  :  Assuring  Conceptual  Integrity    via  Capacity  Alloca%on  to  architecture  =  Harmony   Source:    Dean  Leffinweel  ,  h0p://scaledagileframework.com/guidance/assuring-­‐architectural-­‐integrity-­‐via-­‐capacity-­‐ allocaBon/   

THE END