Enterprise reference architecture v1.1.ppt
•
4 recomendaciones•5,062 vistas
The purpose of this presentation is to share my experiences in the use of Reference Architecture for addressing some key EA challenges.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Enterprise reference architecture v1.1.ppt
Similar a Enterprise reference architecture v1.1.ppt (20)
Último
Último (20)
Enterprise reference architecture v1.1.ppt
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. End of presenta7on April 2009, v0.2 Enterprise Reference Architecture -‐ © 2009 26