Enterprise reference architecture v1.1.ppt


Published on

The purpose of this presentation is to share my experiences in the use of Reference Architecture for addressing some key EA challenges.

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Enterprise reference architecture v1.1.ppt

  1. 1.  Addressing  key  challenges  facing  EA  and  enterprise-­‐wide  adop7on  of  SOA   Ahmed  Fa<ah   Execu7ve  IT  Architect,  IBM  Global  Services,  Australia   afa<ah@au1.ibm.com   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   1  
  2. 2. Content   •  Overview   •  Take  away  points   •  Enterprise  Architecture  (EA),  its  importance  and  challenges   •  Reference  Architecture  (RA)   –  RA  classifica7on  scheme   •  Enterprise  Reference  Architecture  (ERA)   •  What  is  it  and  how  can  it  help  enhance  EA?   •  Program-­‐level  architecture   •  Why  is  ERA  a  natural  fit  with  SOA?   •  ERA  lifecycle   •  Case  studies   •  Case  study  1   •  Case  study  2   •  Summary,  conclusions  and  call  for  ac7on   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   2  
  3. 3. Overview The  purpose  of  this  presenta2on  is  to  share  my  experiences  in  the  use  of  Reference   Architecture  for  addressing  some  key  EA  challenges.   •  Problem   –  The  importance  of  EA  has  been  accepted  by  many  organisa7ons,  but  …   –  Huge  challenges  face  many  in  realising  the  promised  benefits  of  EA  on  regular  basis.   •  Diagnosis   –  Based  on  my  experience,  I  observed  that  a  root  cause  is  the  gap/disconnect  between  EA  and  project-­‐ level  architecture.   –  This  gap/disconnect  burdens  project  architects  with  the  interpreta7on  of  EA  principles,  policies,   standards  and  guidelines  to  develop  their  project  architecture.    This  is  o?en  difficult,  Bme  consuming   and  error  prone.   –  Similar  burden  is  placed  on  the  Enterprise  Architect  to  police  project-­‐level  architecture  for  conformance.   •  Solu7on   –  The  presenta7on  relates  my  experience  in  developing  and  applying  an  approach  that  successfully  uses   Reference  Architecture  (RA)  to  bridge  this  gap.   –  This  form  of  RA  takes  the  form  of  an  Enterprise  Reference  Architecture  (ERA)  which  is  a  blueprint  for   the  SoluBon  Architecture  of  a  number  of  potenBal  projects  within  an  organisaBon  that  embodies  the   EA’s  principles,  policies,  standards  and  guidelines.         April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   3  
  4. 4. Take away points ERA  can  be  a  very  effec2ve  tool  for  enhancing  the  effec2veness  of  EA.   Key  take  away  points  of  the  presenta7on:     •  ERA  can  help  in…   –  bridging  the  gap  between  EA  and  project-­‐level  architecture   –  demonstra2ng  the  value  of  EA  to  the  business   –  facilita2ng  the  enterprise-­‐wide  adop2on  of  SOA   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   4  
  5. 5. EA, its importance and challenges The  need  for  and  importance  of  EA  have  been  accepted  by  many  organisa2ons.  However,   realising  the  full  poten2al  of  EA  in  many  organisa2ons  on  regular  basis  is  s2ll  very   challenging.     Other factors • Large numbers of projects • Inherent gap between EA and project-level Architecture A- Failure of business IT solutions to achieve their business objectives E- Inability of EA to influence and shape business solutions B- Inability to demonstrate the value of EA -Dissatisfaction with IT - Misalignment between business and IT D- Weak EA capabilities C- Inadequate funding of EA - Lack of coverage of Business Architecture - Inadequate communication of EA Other factors • Inadequate EA methodology or process • Lack of skills April  2009,  v0.2   Key challenges that face EA create a vicious cycle Enterprise  Reference  Architecture  -­‐  ©  2009   5  
  6. 6. The gap between EA and Project-level Architecture A  root  cause  behind  the  challenges  facing  EA  is  the  wide  gap/disconnect  between   EA  and  Project-­‐level  Architecture.     •  This  gap/disconnect  burdens  the  project  architects  to  interpret  EA  principles,  policies,   standards  and  guidelines  to  develop  their  project  architecture.  This  is  o?en  difficult,  Bme   consuming  and  error  prone.     •  Similar  burden  is  placed  on  the  Enterprise  Architect  to  police  project-­‐level  architecture  for   conformance  which  is  also  difficult,  Bme  consuming  and  always  controversial.     •  This  leads  projects  to  resist  or  ignore  EA  par7ally  or  completely  and  to  a  sense  of  hos7lity   between  Enterprise  Architects  and  projects.   •  One  reason  for  the  wide  gap  between  EA  and  Project-­‐level  Architecture  is  that  although   they  share  the  term  architecture,  they  are  prac7ced  and  documented  very  differently.   •  This  is  not  surprising  since  the  two  architectures  serve  different  purposes.   –  EA  primarily  takes  the  form  of  principles,  policies,  standards  and  guidelines.   –  Project-­‐level  Architecture  takes  the  form  of  Architectural  Decisions,  components,  interfaces  and   their  rela7onships.   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   6  
  7. 7. Reference Architecture The  term  Reference  Architecture  (RA)  is  used  in  the  industry  to  refer  to  a  wide  variety  of   constructs  from  high  level  abstract  conceptual  models  to  a  specialised  technical  architecture.   •  There  are  many  defini7ons  of  Reference  Architecture  that  although  slightly  different,  have   many  common  elements.     •  For  our  purpose  here,  the  Wikipedia’s  defini7on  is  adequate:   –  “A  Reference  Architecture  provides  a  proven  template  solu2on  for  an  architecture  for  a   par2cular  domain.  It  also  provides  a  common  vocabulary  with  which  to  discuss   implementa2ons,  oSen  with  the  aim  to  stress  commonality”.   •  Examples  of  RA  cover  a  very  wide  range:   –  Unisys  3D  Blueprint  [5]  which  covers  strategy,  business  processes,  applica7ons  and   infrastructure.   –  Specialised  technical  architecture  such  as  IBM  WebSphere  Integra7on  Reference  Architecture   [3].   •  The  terms  Reference  Architecture  and  Reference  Model  are  some7mes  used   interchangeably.     April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   7  
  8. 8. RA Classification Scheme Although  I  have  used  Reference  Architectures  for  a  long  2me,  I  was  surprised  when  I   reviewed  the  staggering    range  of  usage  of  the  term  recently.     •  Google  search  for  the  term  “Reference  Architecture”  has  over  300,000  hits     •  I  first  assumed  that  some  of  these  usages  must  be  erroneous.  However,  I  realised  that  this   was  not  the  case,  at  least  for  the  many  instances  I  have  surveyed…   •  But  that  the  culprit  is  the  malleability  of  the  term  architecture  itself.     •  This  means  that  anything  you  can  think  of  can  have  an  architecture  and  by  extension  a  RA.   •  My  thesis  is  based  on  the  belief  that  Reference  Architectures  can  be  dis7nguished  along   two  dimensions:   –  Coverage     –  Level  of  abstrac8on     April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   8  
  9. 9. RA Classification Scheme: Coverage Coverage  or  applicability  indicates  the  area  where  a  RA  can  be  useful.     Some  RAs  cover  only  presenta2on,  integra2on  or  security  aspects  of  solu2ons,     others  cover  an  end-­‐to-­‐end  enterprise  solu2on.     Architecture Pattern (MVC, f or example) Partial Ref erence Architecture covering specif ic subsystem such as presentation, integration or security April  2009,  v0.2   End-to-end Ref erence Architecture covering business and IT aspect of a solution End-to-end coverage Narrow coverage Patterns End-to-end Technical Ref erence Architecture covering only IT aspects of a solution Partial  Reference  Architecture Enterprise  Reference  Architecture  -­‐  ©  2009   End-­‐to-­‐end   Reference   Architecture 9  
  10. 10. RA Classification Scheme: Level of abstraction Level  of  Abstrac2on  reflects  how  concrete  or  specific  a  given  RA  is.  It  indicates   ul2mately  the  gap  between  the  RA  and  a  Solu2on  Architecture  based  on  it.   Reference Architecture can be defined at varying levels of abstraction from the conceptual and generic to the concrete and specific (in TOGAF terms it spans the Enterprise Continuum). Abstract, conceptual generic Few Architectural Decision have been made Conceptual Generic Another useful way to think about this dimension is in terms of Architectural Decisions. Industry On the concrete/specific end, 'all' the Architectural Decisions have been made. On the other end, very few Architectural Decisions are likely to have been made. Enterprise More Architectural Decision have been made Concrete, specif ic Solution A fully instantiated Solution Architecture April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   10  
  11. 11. RA Classification Scheme The  classifica2on  scheme  is  useful  in  sor2ng  out  the  myriad  of  RAs  that  are  available  to   determine  which  are  useful  in  a  given  situa2on  and  how  different  RA  are  related  to  each   other.   Abstract/ generic/ conceptual Oasis SOA Reference Model MVC pattern IBM SOA Solution Stack Reference Model IBM SOAI RA ESB pattern Conceptual Generic IBM SOA Foundation RA IBM Insurance RA Narrow Architecture pattern Industry Enterprise Enterprise Reference Reference Architecture Architecture (ERA) Enterprise ESB pattern implemented using IBM WebSphere stack Comprehen sive Full enterprise solution architecture (ERA) Patterns Partial End-­‐to-­‐end End-­‐to-­‐end Realised Enterprise e2e Solution Architecture Concrete/ Specific/ physical April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   11  
  12. 12. Enterprise Reference Architecture (ERA) An  ERA  is  a  blueprint  for  the  Solu2on  Architecture  of  a  number  of  poten2al  projects  within   an  organisa2on  that  embodies  the  EA  principles,  policies,  standards  and  guidelines.     •  An  ERA  is  a  Solu7on  Architecture  with  some  of  the  Architectural  Decisions  being  made  and   others  leg  open.   •  ERAs  resemble  actual  Solu7on  Architectures.  This  means  that  the  effort  to  apply  them  by   project-­‐level  architects  is  rela7vely  low.     •  They  are  applicable  to  a  number  of  poten7al  business  solu7ons  within  the  organisa7on.     •  Ideally,  the  development  of  ERA  should  be  funded  directly  by  the  business  to  address   specific  business  objec7ves.     •  One  key  source  of  knowledge,  experience  and  reusable  components  for  the  development   and  construc7on  of  ERAs  must  come  from  exis7ng  projects  by  way  of  harves7ng  suitable   proven  components  and  pa<erns.   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   12  
  13. 13. Program-level Architecture Funding  the  development  of  an  ERA  directly  by  the  business  for  a  specific  business  ini2a2ve   (a  program  of  projects)  can  profoundly  transform  the  way  architecture  is  prac2ced  in  the   organisa2on.  I  refer  to  this  as  Program-­‐level  Architecture.   Enterprise Architecture Interpretation and conformance policing is difficult, time consuming and error prone. Enterprise wide policies, standards, principles and guidelines. Enterprise Architecture Enterprise Reference Architecture In (Program-level Architecture) The missing link between EA and project-level Architecture. One Programlevel Architecture covers a number of project-level Architecture Project-level Architecture Business Solution Architecture April  2009,  v0.2   Each solution project must deliver a distinctive business value while advancing the enterprise capabilities whenever possible. Project-level Architecture Business Solution Architecture Enterprise  Reference  Architecture  -­‐  ©  2009   13  
  14. 14. ERA and SOA Although  the  ERA  approach  proposed  in  this  paper  applies  to  all  architecture  styles,  it's  more   compelling  and  easier  to  apply  for  SOA  because  of  SOA’s  emphasis  on  standardisa2on  and   reuse.     Subsystem Reference Architecture Conceptual  SOA  Reference  Architectures Generic  SOA  Reference  Architectures Industry  SOA  Reference  Architectures Conceptual Generic Industry SOA  Enterprise  Reference  Architecture  (ERA) Enterprise Solution SOA  Solution  Architecture Portal Reference Architecture April  2009,  v0.2   Integration Reference Architecture Security Reference Architecture The hierarchy of the SOA RAs that can be adopted and applied within an organisation culminating in a small number of ERAs that can be used to guide projects in creating SOA business solutions. Other partial Reference Architecture Enterprise  Reference  Architecture  -­‐  ©  2009   14  
  15. 15. IBM SOA Solution Stack Reference Architecture IBM  SOA  Solu2on  Stack  (S3)  Reference  Architecture  is  invaluable  for  crea2ng  an   ERA  for  most  of  the  opera2onal  business  solu2ons  for  an  enterprise.   B2B Services atomic and composite Conceptual  SOA  Reference  Architectures Generic  SOA  Reference  Architectures Industry  SOA  Reference  Architectures Conceptual Service Provider Subsystem Reference Architecture Service Components Packaged Existing Application Assets Application Custom Application Governance Composition; choreography; business state machines Data Architecture (meta-data) & Business Intelligence Business Process QoS Layer (Security, Management & Monitoring Infrastructure Services) Integration (Enterprise Service Bus) Service Consumer Channel Consumers OO Application Generic Industry Atomic Service Composite Service Registry SOA  Enterprise  Reference  Architecture  (ERA) Enterprise Solution SOA  Solution  Architecture Portal Reference Architecture   Integration Reference Architecture April  2009,  v0.2   Security Reference Architecture Other partial Reference Architecture Enterprise  Reference  Architecture  -­‐  ©  2009   15  
  16. 16. An ERA based on IBM Solution Stack Reference Architecture Developing  an  SOA  ERA  based  on  the  IBM  S3  RA  can  be  done  systema2cally  by   mapping  each  layer  to  technical  and  func2onal  components.   B2B atomic and composite Governance Services Data Architecture (meta-data) & Business Intelligence Integration (Enterprise Service Bus) Business Process Composition; choreography; business state machines QoS Layer (Security, Management & Monitoring Infrastructure Services) Service Consumer Channel Consumers Service Provider Service Components Existing Application Assets Atomic Service Packaged Application Custom Application Composite Service OO Application Registry Architecture Overview Diagram of an SOA ERA for a large government agency. April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   16  
  17. 17. ERA lifecycle The  process  for  developing  and  using  ERA  overlaps  with  the  lifecycle  of  EA  and  projects  and   should  be  compa2ble  with  most  typical  EA  and  soSware  development  lifecycle  methods  and   processes.   Enterprise   Architecture   Lifecycle Principles, policies, standards and guidelines Business Architecture Technology scans Plan,   develop/update   ERA Identify  need  for     new  or  modified   ERA Program/ Reference Architecture Lifecycle Implement  or   upgrade  common   infrastructure   needed  for  ERA Use  ERA  to  develop   Business  Solution   Architecture Specif ic business needs Project  Architecture   Lifecycle April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   17  
  18. 18. Case study 1 Case  study  1  used  the  ERA  approach  to  address  the  problem  of  the  lack  of  standardisa2on  of   applica2on  plaborms,  databases,  middleware,  development  tools  etc  in  a  large  organisa2on.   •  The  EA  group  was  well  funded  compared  with  many  other  organisa7ons,  the  group’s  resources   were  stretched  in  maintaining  the  EA  guidance  artefacts  and  ‘policing’  the  conformance  of   solu7ons.     •  EA  guidance  was  contained  in  very  large  volumes  that  covered  mainly  two  categories:     –  SOE  (Standard  Opera7ng  Environment)  which  covers  standards  concerning  what  development   plaiorms,  middleware,  etc  are  allowed  to  be  used;  and   –  Architectural  guiding  principles  that  should  be  followed  by  the  projects  when  developing  their   architecture.   •  We  found  that  this  material  was  well  wri<en  and  maintained  but  also  found  some  problems   with  the  way  the  EA  guidance  was  provided  especially  from  projects’  point  of  view:   –  One  of  the  problems  that  projects  were  faced  with  in  interpre7ng  the  SOE  was  the  compa7bility   between  choices  of  various  solu7on  components.     –  Interpre7ng  the  architectural  guiding  principles  was  a  problem  because  many  of  these  principles  (and   there  were  many)  conflict  and  the  degree  of  required  conformity  varied  from  must  conform  to  nice  to   have.     –  The  EA  group  got  many  requests  for  clarifica7on  and  exemp7on  from  adhering  to  the  SOE  or  the   guiding  principles.   –  Projects  did  not  view  the  EA  group  as  a  help  but  an  obstacle  that  they  have  to  go  around.   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   18  
  19. 19. Case study 1 A  number  of  ERAs  were  developed  and  adapted  in  many  projects  and  the  approach   in  general  helped  greatly  in  revitalising  the  EA  of  the  enterprise.       Candidate Implementation Architecture (CIA) Reference Technical Architecture (RTA) Populate with tools Reference Implementation Architecture (RIA) Evaluate and select An RIA represents the preferred way for building a class of applications. It may contains additional information beyond an CIA such as: guidelines using the tools, frameworks, skeletons, templates that can assist developers in applying the architecture. A CIA represents a consistent workable sets of products that can meet the “non-functional” requirements of an RTA. The CIA includes “proofs” that demonstrate the maturity of the product set used in the architecture. An RTA describes the technical architecture of a “class” of applications in productindependent terms. It describes the runtime, development and testing aspects of the application. Contains reusable components in multiple architecture Contains reusable “patterns” of component sets. Component Catalogue Tools Process Terms and Concepts (including template for all work products above) April  2009,  v0.2   Architecture Template Catalogue This document explains terms, notations and concepts. It also includes templates (skeleton) for all work products above. Enterprise  Reference  Architecture  -­‐  ©  2009   19  
  20. 20. Case study 1 One  of  the  lessons  learned  was  that  even  in  very  large  organisa2ons,  the  most  common   types  of  business  solu2ons  can  be  covered  with  very  few  types  of  Reference  Architecture   especially  the  plaborm-­‐independent  type  (RTA).     •  Other  lessons  learned  include:   –  Funding  the  development  of  ERAs  can  be  difficult  to  obtain  without  tying  them  to  specific   business  ini7a7ves.  Ager  the  ini7al  development  of  a  number  of  ERAs  the  momentum  slowed   down  because  of  a  lack  of  funding.     –  Another  lessons  that  is  also  related  to  the  funding  of  the  ERAs  is  the  problem  of  the  prolifera7on   of  types  of  ERAs  which  makes  iden7fying  suitable  ERAs  for  a  given  business  situa7on  difficult.     •  Other  details  of  the  case  study  are  available  on  request   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   20  
  21. 21. Case study 2 In  this  case  study  we  developed  and  applied  most  of  the  concepts  behind  the  ERA   approach  including  the  funding  of  the  development  of  ERA.     •  The  context  of  this  case  study  was  a  large  government  department  that  embarked  on  a   massive  transforma7on  program.   •  The  advice  to  the  CIO  was  to  ensure  that  this  new  plaiorm  is  used  in  an  enterprise-­‐wide   manner  and  not  on  a  project  by  project  basis.  The  CIO  approached  us  and  asked  “but  how   can  I  do  this  while  I  have  many  lines  of  business  requesBng  to  start  developing  a  number   of  individual  business  soluBons  immediately  using  the  new  plaNorm?”   •  The  answer  was  to  defer  the  start  of  these  projects  un7l  an  ERA  was  developed  to  guide   how  these  projects  were  developed  and  maximise  the  poten7al  level  of  reuse  between   these  projects.     •  So  the  development  of  this  ERA  was  funded  explicitly  with  the  aim  to  lower  the  overall   cost  of  the  new  business  solu7ons.   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   21  
  22. 22. Case study 2 One  imprtant  aspect  of  this  case  study  that  was  crucial  but  difficult  to  achieve  was   the  inclusion  of  the  Business  Architecture  in  the  development  of  the  ERA.   Architecture Framework General documents Program/ Reference architecture views Overview and overall views Reference Architecture Requirements Reference Architecture Overview Reference Architecture Business Architecture views Architecture Risk Management Plan Information Architecture Business Process and Service Architecture Organisation Architecture Technical Architecture views Business Solution Service Architecture Solution Architecture Requirements (split between Business Process and Application Component Architecture) Integration Architecture Security Architecture Solution Architecture Overview Application Component and Service Architecture Infrastructure Architecture Solution Architecture April  2009,  v0.2   Data Architecture Legacy Rationalisation Architecture System Management Architecture Operation Architecture Enterprise  Reference  Architecture  -­‐  ©  2009   22  
  23. 23. Case study 2 One  of  the  key  lessons  learned  was  that  the  development  of  ERA  can  significantly   reduce  the  effort  and  risk  associated  with  development  of  individual  projects.     •  Other  lessons  learned  were:   –  The  Solu7on  Architects  who  work  on  the  development  of  the  ERA  can  contribute  enormously  to   the  projects  in  their  begining.       –  It  is  not  enough  to  just  ini7ally  develop  the  ERA.  The  architecture  should  be  maintained  and   enhanced  by  lesson  learned  from  individual  projects.  This  means  that  some  architectural   resources  must  be  allocated  to  maintaining  the  ERA.  Ideally  these  resources  are  assigned  on   rota7on  basis  to  the  development  projects  and  the  EA  group.   –  Developing  ERAs  is  not  a  subs7tute  for  typical  EA  ac7vi7es.  Although  knowledge  and   informa7on  from  the  ERAs  can  feed  back  to  other  EA  ac7vi7es,  there  is  a  need  to  address  other   needs  within  the  organisa7on  that  ERAs  do  not  cover.   •  Other  details  of  the  case  study  are  available  on  request   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   23  
  24. 24. Summary, conclusions and call for action The  presenta2on  discussed  an  approach  for  enhancing  the  effec2veness  of  EA   prac2ces  with  the  use  of  Enterprise  Reference  Architecture  (ERA).     •  ERAs  are  Reference  Architectures  that  embody  the  principles,  policies,  standards  and   guidelines  of  the  enterprise  in  a  form  that  is  easily  applicable  to  a  set  of  business   solu7ons.  ERAs  are  ideally  developed  for  large  business  ini7a7ves.   •  The  approach  described  here  was  developed  and  has  been  applied  successfully  in  a   number  of  prac7cal  situa7ons.     •  I  hope  that  some  of  the  audience  find  the  whole  approach  or  some  aspects  of  it  useful  for   their  organisa7ons  or  clients.     •  I  welcome  all  feedback  regarding  the  structure,  contents  or  experiences  related  to   applying  the  concepts  discussed  in  the  presenta7on.   •  I  aim  to  enhance  the  approach  and  the  concept  of  ERA  based  on  feedback  and  from  a   number  of  customer  situa7ons  that  I  am  currently  involved  in.     April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   24  
  25. 25. Hindi Thai Traditional Chinese Gracias Spanish Russian Thank YouMerci English French Obrigado Brazilian Portuguese Arabic Grazie Danke Italian German Simplified Chinese Tamil April  2009,  v0.2   Korean Japanese Enterprise  Reference  Architecture  -­‐  ©  2009   25  
  26. 26. End  of  presenta7on   April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   26