26

Click here to load reader

Enterprise reference architecture v1.1.ppt

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Enterprise reference architecture   v1.1.ppt

 Addressing  key  challenges  facing  EA  and  enterprise-­‐wide  adop7on  of  SOA  

Ahmed  Fa<ah  Execu7ve  IT  Architect,  IBM  Global  Services,  Australia  

afa<[email protected]  

April  2009,  v0.2   1  Enterprise  Reference  Architecture  -­‐  ©  2009  

Page 2: Enterprise reference architecture   v1.1.ppt

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  

Page 3: Enterprise reference architecture   v1.1.ppt

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  

Overview

Page 4: Enterprise reference architecture   v1.1.ppt

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  

Take away points

Page 5: Enterprise reference architecture   v1.1.ppt

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.    

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   5  

C- Inadequate funding of EAD- Weak EA capabilities- Lack of coverage of Business Architecture

- Inadequate communication of EA

A- Failure of business IT solutions to achieve their

business objectives

B- Inability to demonstrate the value of EA

-Dissatisfaction with IT- Misalignment between business and IT

Other factors• Inadequate EA methodology or process• Lack of skills

Other factors• Large numbers of projects• Inherent gap between EA and project-level Architecture

E- Inability of EA to influence and shape business solutions

EA, its importance and challenges

Key challenges that face EA create a vicious cycle

Page 6: Enterprise reference architecture   v1.1.ppt

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  

The gap between EA and Project-level Architecture

Page 7: Enterprise reference architecture   v1.1.ppt

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  

Reference Architecture

Page 8: Enterprise reference architecture   v1.1.ppt

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  

RA Classification Scheme

Page 9: Enterprise reference architecture   v1.1.ppt

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.    

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   9  

RA Classification Scheme: Coverage

Architecture Pattern(MVC, for example)

Narrow coverage

End-to-endcoverage

Partial Reference Architecture covering specif ic subsystem such as presentation, integration or security

End-to-end Technical Reference Architecture covering only IT aspects of a solution

End-to-end Reference Architecture covering business and IT aspect of a solution

Patterns Partial  Reference  Architecture End-­‐to-­‐end  Reference  Architecture

Page 10: Enterprise reference architecture   v1.1.ppt

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.  

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   10  

RA Classification Scheme: Level of abstraction

Another useful way to think about this dimension is in terms of Architectural Decisions. 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.

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, conceptualgeneric

Concrete, specif ic

More Architectural Decision have been made

Few Architectural Decision have been made

A fully instantiated Solution Architecture

Generic

Industry

Conceptual

Enterprise

Solution

Page 11: Enterprise reference architecture   v1.1.ppt

End-­‐to-­‐end

EnterpriseReference Architecture (ERA)

Abstract/ generic/ conceptual

Concrete/ Specific/ physical

NarrowArchitecture pattern

ComprehensiveFull enterprise solution architecture

Generic

Industry

Conceptual

Enterprise

PartialPatterns

MVC pattern

ESB pattern implemented using IBM WebSphere stack

ESB pattern

Realised Enterprise e2e Solution Architecture

Oasis SOA Reference Model

IBM SOA Solution Stack Reference Model

IBM SOA Foundation RA

IBM Insurance RA

EnterpriseReferenceArchitecture(ERA)

IBM SOAI -RA

End-­‐to-­‐end

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.  

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   11  

RA Classification Scheme

Page 12: Enterprise reference architecture   v1.1.ppt

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  

Enterprise Reference Architecture (ERA)

Page 13: Enterprise reference architecture   v1.1.ppt

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.  

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   13  

Program-level Architecture

Enterprise Architecture

Project-level

ArchitectureBusiness Solution Architecture

In

Enterprise wide policies, standards, principles and guidelines.

Enterprise Architecture

Project-level

ArchitectureBusiness Solution Architecture

Each solution project must deliver a distinctive business value while advancing the enterprise capabilities whenever possible.

The missing link between EA and project-level Architecture.

Enterprise Reference Architecture

(Program-level Architecture)

Interpretation and conformance policing is difficult, time consuming and error prone.

One Program-level Architecture covers a number of project-level Architecture

Page 14: Enterprise reference architecture   v1.1.ppt

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.    

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   14  

ERA and SOA

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.

Enterprise

Other partial

Reference Architecture

Integration Reference Architecture

Security Reference Architecture

Portal Reference Architecture

SOA  Solution  Architecture

Generic

Industry

Solution

Conceptual

Industry  SOA  Reference  Architectures

Generic  SOA  Reference  Architectures

SOA  Enterprise  Reference  Architecture  (ERA)

Conceptual  SOA  Reference  Architectures

Subsystem Reference Architecture

Page 15: Enterprise reference architecture   v1.1.ppt

 

Enterprise

Other partial

Reference Architecture

Integration Reference Architecture

Security Reference Architecture

Portal Reference Architecture

SOA  Solution  Architecture

Generic

Industry

Solution

Conceptual

Industry  SOA  Reference  Architectures

Generic  SOA  Reference  Architectures

SOA  Enterprise  Reference  Architecture  (ERA)

Conceptual  SOA  Reference  Architectures

Subsystem 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.  

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   15  

Services atomic and composite

Existing Application Assets

Service Components

Consumers

Business Process Composition; choreography; business state machines

Service Provider Service C

onsumer

Integration (Enterprise Service Bus)

QoS Layer (Security, M

anagement &

M

onitoring Infrastructure Services)

Data A

rchitecture (meta-data) &

B

usiness Intelligence

Governance

Channel B2B

Packaged Application

Custom Application

OO Application

Atomic Service Composite Service Registry

IBM SOA Solution Stack Reference Architecture

Page 16: Enterprise reference architecture   v1.1.ppt

Developing  an  SOA  ERA  based  on  the  IBM  S3  RA  can  be  done  systema2cally  by  mapping  each  layer  to  technical  and  func2onal  components.  

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   16  

An ERA based on IBM Solution Stack Reference Architecture

Services atomic and composite

Existing Application Assets

Service Components

Consumers

Business Process Composition; choreography; business state machines

Service Provider Service C

onsumer

Integration (Enterprise Service Bus)

QoS Layer (Security, M

anagement &

M

onitoring Infrastructure Services)

Data A

rchitecture (meta-data) &

B

usiness Intelligence

Governance

Channel B2B

Packaged Application

Custom Application

OO Application

Atomic Service Composite Service Registry

Architecture Overview Diagram of an SOA ERA for a large government agency.

Page 17: Enterprise reference architecture   v1.1.ppt

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.  

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   17  

Project  Architecture  Lifecycle

Enterprise  Architecture  Lifecycle

Identify  need  for    new  or  modified  

ERA

Program/ Reference

Architecture Lifecycle

Plan,  develop/update  

ERA

Implement  or  upgrade  common  infrastructure  needed  for  ERA

Use  ERA  to  develop  Business  Solution  Architecture

Principles, policies, standards and guidelines

Technologyscans

Business Architecture

Specif ic business needs

ERA lifecycle

Page 18: Enterprise reference architecture   v1.1.ppt

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  

Case study 1

Page 19: Enterprise reference architecture   v1.1.ppt

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.    

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   19  

 

Reference TechnicalArchitecture (RTA)

CandidateImplementation

Architecture (CIA)

ReferenceImplementation

Architecture (RIA)

Component Catalogue Architecture TemplateCatalogue

An RTA describes the technicalarchitecture of a “class” ofapplications in product-independent terms. It describes theruntime, development and testingaspects of the application.

Populate with tools Evaluate and select

Contains reusable componentsin multiple architecture

Contains reusable “patterns” ofcomponent sets.

A CIA represents a consistentworkable sets of products that canmeet the “non-functional”requirements of an RTA. The CIAincludes “proofs” that demonstratethe maturity of the product setused in the architecture.

An RIA represents the preferredway for building a class ofapplications. It may containsadditional information beyond anCIA such as: guidelines using thetools, frameworks, skeletons,templates that can assistdevelopers in applying thearchitecture.

Tools Process Terms andConcepts

(including template forall work products above)

This document explains terms,notations and concepts. It alsoincludes templates (skeleton) forall work products above.

Case study 1

Page 20: Enterprise reference architecture   v1.1.ppt

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  

Case study 1

Page 21: Enterprise reference architecture   v1.1.ppt

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  

Case study 2

Page 22: Enterprise reference architecture   v1.1.ppt

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.  

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   22  

Business Solution

Program/ Reference architecture viewsGeneral documents

Architecture Framework

Reference Architecture Requirements

Integration Architecture

Architecture Risk Management Plan

Data Architecture

Security Architecture

Infrastructure Architecture

Application Component and Service Architecture

Legacy Rationalisation Architecture

Reference Architecture

System Management Architecture Operation Architecture

Reference Architecture Overview

Information Architecture Business Process and Service Architecture

Organisation Architecture

Solution Architecture Requirements

Solution Architecture Overview

Solution Architecture

Service Architecture(split between Business Process and Application Component Architecture)

Business Architecture views

Technical Architecture views

Overview and overall views

Case study 2

Page 23: Enterprise reference architecture   v1.1.ppt

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  

Case study 2

Page 24: Enterprise reference architecture   v1.1.ppt

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  

Summary, conclusions and call for action

Page 25: Enterprise reference architecture   v1.1.ppt

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   25  

Thank You Merci

Grazie

Gracias

Obrigado

Danke

Japanese

English

French

Russian

German Italian

Spanish

Brazilian Portuguese Arabic

Traditional Chinese

Simplified Chinese

Thai

Tamil

Hindi

Korean

Page 26: Enterprise reference architecture   v1.1.ppt

End  of  presenta7on  

April  2009,  v0.2   Enterprise  Reference  Architecture  -­‐  ©  2009   26