Architecture in action !

Krishna  Sankar  @ksankar  May  7,  2007  

u  Architecture  Succeeds  !  • Quietly  !  

Thanks to Chris Wiborg for this observation ….

Architecture - Heuristics

u  Simplify  •  Not  monolithic  systems  but  building  blocks  

u  Design  the  structure  with  “good  bones”  •  Resilient  to  a  wide  range  of  stress  and  usage  patterns  •  Internet  :  Constant  assembly  line  with  no  central  point  of  control  

•  Build  in  and  maintain  options  •  Use  open  architectures  

u  Implementation  matters  

Architecture - Heuristics

u Build  Evolutionary  systems  •  A  system  will  develop  and  evolve  much  more  rapidly  if  there  are  stable  intermediate  forms  than  if  there  are  not  

•  Old  information  need  not  change  to  have  new  models  

•  Resolve  ambiguity  &  clarify  /  trap  inconsistencies  at  the  message  layer  

Architecture - Heuristics

u Use  Pattern  oriented  architectures  •  EJB  •  General  patterns  •  Real  time  patterns  

u  Software  reflects  the  creators  u Architecture  is  a  “network  good”  

•  i.e.  adds  value  as  the  users  increase  (like  a  network  of  computers  or  telephones)  

Architecture - Heuristics

u Minimalist  design  u Build  larger  things  out  of  small  things  

•  Bigger  programs,  larger  number  of  bugs  •  Opportunities  for  wide  open  channels  • Model  after  cells  and  bricks  !  

u Generic  appliances  which  can  dynamically  take  different  roles  depending  on  the  state  of  the  network  •  E.g.:  Denial  of  attack  :  Lots  of  packet  filtering  functions  

Architecture - Heuristics

u Web  of  trust  rather  than  single  point  trust  u All  information  is  processed  under  multiple  trust  contexts  

u Application/Domain  Level  Security  :  Not  point  to  point  

u Defense  in  Depth  principles  •  Not  rely  on  one  layer  or  one  device  for  protection  and  information  accuracy  

• Multi-­‐level  Security  

Architecture - Heuristics

u Pervasive  Security  Architecture  • Means  making  security  part  of  everything  and  not  making  it  its  own  thing.    

•  It  means  security  isn’t  added  to  the  enterprise,  it’s  woven  into  the  fabric  of  the  architecture    

Courtsey : http://www.cio.com/research/security/edit/a072601_firewall.html

Architecture Methodologies

u  Normative/solution  based  •  Prescribes  the  “should-­‐be”  in  terms  of  standards,  codes  

u  Rational/method-­‐based  •  Methods  and  processes  to  arrive  at  a  solution.  i.e.  check  lists,  ways  to  review,  SDLC,  …  

u  Participative  •  Brainstorming/concurrent  engg  

u  Heuristics  •  Patterns,  Thumb  rules,  old  tales,  fables,  …  

Architecture is ….

u Politics  •  EEF,  Mitch  Kapoor  

u  Disciplined  avoidance  of  value  judgments  •  Client  –  desirability,  Architect  –  feasibility  •  Pyramids  –  architected  not  for  burial,  but  show  of  political  &  religious  

power  u  Clear  avoidance  of  conflict  of  interest  

•  Who  benefits  ?  Who  pays  ?  Who  provides  ?  Who  loses  ?  u  Arms-­‐length  relationship  with  project  management  

•  But  be  very  aware  of  project  responsibilities  •  Need  to  architect  so  that  systems  can  be  built  within  the  project  

constraints  

Architecture is ….

u Policy  • What  you  can  do  is  strongly  correlated  to  how  you  are  connected    

•  If  we  make  wise  choices  in  architecting  our  systems,  long  before  they  have  millions  of  users,  their  architectures  become  the  firm  foundations  on  which  subsequent  systems  are  built  u Paraphrasing  John  Gilmore  

Architecture is ….

u Freedom  •  From  mundane  things  so  that  the  programmer  can  concentrate  on  the  problem  at  hand  !  

u  Flip  side  •  Enabling  Vs  restriction  

u Framework  can  be  very  intelligent  or  very  dumb/pass-­‐thru  

•  Architecture  and  it’s  artifacts  are  choke  points  –  deliberate  or  not  

Architecture is ….

u Handling  Complexities  • Abstract  Essential  Complexity  

u Cannot  avoid  domain  complexity  

• Avoid  Accidental  Complexity  

Architecture is …..

u Not  an  isolated  event    •  But  a  product  line  

u Act  like  a  software  company  •  Road  map  •  Articulated  feature  set  •  Deliverables  •  User  feedback  and  influence  

u Need  to  reflect  this  in  the  process,  representation  and  the  artifacts  

Architecture has

u Deliverables  •  Have  a  clear  vision  of  whom  the  results  are  for  • Managers  –  fluffy  slides  

u “If  you  can't  explain  it  in  5  min,  either  you  don’t  understand  it  or  it  doesn’t  work”  

•  Architects  u Play-­‐book,  Framework,  Principles  

•  Developers  u API  Docs,  Examples  

Architecture has

u  Timeframes  

5 years Vision 2 years Strategy 1 year Tactical Plan

6-9 months Operational

Thanks to Greg Giles for this observation ….

Roles & Responsibilities

u Architect  Vs  Engineer  Vs  Builder    u Different  View  points  u  Important  to  realize  which  hat  you  are  wearing  

An Architecture is not optional

Some are designed

and some just happen

But it’s there and it affects the efficiency of the product

Every product already has an Architecture

u  Byzantine  failure  •  Assume  the  component  fails  &  •  Does  the  worst  possible  thing    •  To  the  system  

u  Ariane 5 disaster (1996) u  Dual redundant system

•  Main system failed •  Switched to the backup system (which already had failed

due to the same cause) •  Cause – Conversion 64 bit to 16 bit integer

u  Code left over from Ariane 4 which was never reqd in 5 but reqd in 4, but only till lift off - 9 seconds. But they continued the calculations lift off+50 seconds :o(

http://www.around.com/ariane.html

http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

Challenges

u Not  just  new  technology,  but  performance  measurements  &  reward  system  

u  Incompatible  applications  would  not  magically  become  compatible  with  the  web  services  fabric  (Mark  Day,Cisco  Systems)  

u  Technical  standards  need  not  translate  to  successful  business  models/enablers  

Challenges

u  Do  we  have  a  long  term  shared  vision  of  the  IT  &  Business  Architecture  ?  

u  Can  we  balance  new  architecture  &  business  impact  ?  u  Are  we  moving  fast  enough  to  build  expertise  &  exploit  

inter-­‐company  processes  ?  u  Do  we  have  a  clear  understanding  of  organizational  

inertia  and  have  a  plan  ?  u  Are  we  providing  sufficient  leadership  to  vendors  and  

standards  ?  

Courtsey : HBR 10/01

Reuse ?

u  Is  there  an  incentive  for  developers  to  build  components  for  reuse,  even  though  it  may  take  longer  and  be  more  expensive?  Remember  that  the  value  of  this  approach  is  being  able  to  reuse  the  components  the  second  and  third  time,  not  the  first  time.    

u  Are  project  managers  &  functional  managers  compensated  based  on  how  much  reuse  they  are  able  to  employ  in  their  solutions?    

Reuse ?

u Are  developers  rewarded  for  reusing  components  in  their  solution?    

u Has  a  central  body  taken  ownership  of  reusable  components  so  that  they  can  be  available  and  leveraged  by  other  groups?  

Architecture needs support …

u  To  gain  and  retain  skills,  we  need  three  things  :    

1.  Acquire  the  skill,    2.  Be  exposed  to  the  skill  being  practiced    3.  Opportunities/motivation  to  practice  the  skill.  

u  The  Arch  forum  should  provide  1)  and  2).    u  3)  should  come  from  Sr.Staff  and  the  rest  of  

the  management  team.  

Break !

PROPRIETARY MATERIAL - DELETED

References

u  [1]  The  Art  of  Systems  Architecture  :  Mark  W.  Mainer  et  al  

u  [2]  Design  &  Use  of  Software  Architectures  :  Jan  Bosch  

u  [3]  The  Future  of  Ideas  :  Lawrence  Lessig    

Questions ?

Questions ?