O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Open Group Conference 2011 - The Canonical Data Zone

1.799 visualizações

Publicada em

This is a presentation I gave at the Open Group Conference in London 2011. It discusses the role of data in Service Oriented Architectures and introduces the idea of a 'Canonical Data Zone' (CDZ). The issues in selecting a data standard for the CDZ are discussed with examples from the payments systems processing domain.

Publicada em: Tecnologia
  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

Open Group Conference 2011 - The Canonical Data Zone

  1. 1. The Canonical Data ZoneIssues in data selection for Service OrientedArchitecturesGary FarrowIT ArchitectDirector Triari Consulting
  2. 2. ObjectivesBy the end of this session you will understand:• The advantages of adopting a canonical data model in a SOA• The key issues in selecting an appropriate canonical data model• The architectural impact of operating using a canonical data zone 2
  3. 3. Agenda1. Context2. Reference Models – SOA Reference Architecture – Canonical Data Meta-Model3. The Canonical Data Zone Defined4. Issues in Canonical Data Selection – Payments Hub and Payments Engine Case Studies – CDM Strategies & Evaluation5. Conclusions 3
  4. 4. Context In this section the context of the canonical data problem is now described 4
  5. 5. Value Proposition Scenario Inputs (I) • Co-existence with multiple external partners / standardsExternal Partners / Industry Standards Delivery Channels • Multiple delivery channels Design Goals • Interoperability with multiple industry standards Canonical • Channel harmonisation Data – Common business process – Common data necessary to support these • To reduce integration complexity Advantages • Architectural simplicity Internal Systems / Components • Reduces integration complexity Outputs (O) – IxO problem reduced to I+OExternal • Common processes – Single layer decoupled from channelsInternal • Supports high coherence principle Reusable services shared across different channel – Channel components are responsible for contexts presentation 5
  6. 6. Reference Models In this section two reference models are described that are used in the analysis of the canonical data problem 6
  7. 7. SOA Reference Architecture Overview • Hierarchical model for services within the enterprise • Four layers inter-leaved with integration services • Use as a ‘ideal world’ framework for SOA solutions – Flexible – Support bespoke design – Supports package solution – Supports domain model (domains sit in the business services layer. ) Uses • Couple with architectural principles to provide SOA best practice • Illustrate Enterprise Architecture patterns • Defined anti-patterns relating to SOA misuse Context • Use this for analysis of the data requirements for SOA – Which layers of the architecture use canonical data? – Are there different selections of canonical data the different layers? 7
  8. 8. Canonical Data Meta-Model Require agreement on how logical information is represented 3 Layered Model 1. Business Concepts • Describes the core entities of the business and their relationships 2. Message Models • Constructed from the business entities • Messages constructed to fulfil the requirements of steps in a processes 3. Syntax • The implementation technology of the message models • Format in which the message is structured • Programming Objects – e.g Java Object • XML, JSON • Process Engine specificStandardising across all data categories in all SOA – e.g. IBM Service Component Architecturearchitectural layers is neither practical or necessary / Business Objects • Data Dictionary captures all the required meta data 8
  9. 9. Types of Data Standards • Standards paradox • Two dimensions to a standard 1. Open / Closed PDF • Refers to the extent to which information about the standard is ISO xxxx SWIFT published 1. Sponsored / Unsponsored J2EE • Refers to the maintenance of the standard by a single business organisation or by a standardisation body CDM Vulnerabilities – Basing on a standard makes it MS Word vulnerable to changes in the standard – Extent of vulnerability dependent on the type of the standard – Design objective make architectureThe wonderful thing about standards is that robust in response to changes there are so many of them to choose from 9
  10. 10. The Zone In this section the Canonical Data Zone is defined in terms of the Reference Models 10
  11. 11. Canonical Data Zone Defined • Given the objectives of common processes and reuse of Business Services canonical data is considered key: • In the Process Services layer • Within its orchestrations In the Zone • Business Concepts are reused to achieve common processes • Common Messaging model critical for service call between Process and Business Service layer • Common Syntax is desirable within the process layer Outside the zone: • Business Concepts may be reused within the Data Services • Common Messaging Model is not essential for Data Services • Strong encapsulation of data services is preferred when implementing custom Business Services • Package solutions provide black box business services • Syntax implementation differ to support different technology solutions for the components • Legacy • Package solutions • Actual data storage within a database 11
  12. 12. Issues in Canonical Data Selection In this section, issues in selecting a canonical data model for a given business domain are described in the context of payments processing case studies 12
  13. 13. Case Study 1: Payment Hub • Scenarios - merger / acquisition / modernisation • Payments hub solution proposed • Common payments processing decoupled from product systems • Route to two or more product systems • Framework technology solution for the Hub chosen Design Issues • Package integration – Core banking system vendors offer modules that already use industry specific format – Transform BACS-Canonical-BACS (-Internal) • Package design principles – Use ‘out of the box’ Framework – Scheme specific interfaces already provided • Hub design principles – Integration ‘heavy lifting’ – Execute common processes using canonical data model – Minimise transformations (BACS-Canonical) • Architectural tension – Hub vs. package principle – What is the appropriate CDM? 13
  14. 14. Industry Standard CDZ Scenario • Scenario assumes open standard and adoption of the same within the CDZ • Industry standard will change • Enrichment of the payments message required Advantages • Out of the box message format & syntax Disadvantages • Processes and the business services interfaces are impacted in the change case • Ability to respond rapidly is affected • Does not meet functional business requirements • Process and Business Services are tightly coupled to an external standard – Impact is worse if standard is unsponsored • Processes services are not harmonised • Business services are not reused. 14
  15. 15. Custom CDZ Scenario • Scenario assumes an open standard but adoption of a custom canonical data model in the CDZ • Industry standard changes • Integration service transforms into the CDM Advantages • Buffered from immediacy of industry standard enhancements • Meets ‘real world’ requirements • Processes harmonised • Business Services reused Disadvantages • Custom CDM development required 15
  16. 16. Qualitative Evaluation • Strategies for CDM selection are shown opposite Design Tradeoffs • Industry+ and +/- offer best robustness to change with least development effort • Limit of reduction is determined by the scope of the business processes Custom Industry Industry Industry that must be supported + +/- • Industry standard may offer least development effort and provide best performance for demandingEffort to Develop NFRs • e.g. Faster Payments / CardsRequirements Fit ISO 8583 • Commonality of processingPerformance sacrificed to achieve NFRs Design SolutionRobustness to • IS020022 supports dataChange requirements for a number of payments schemes • Enhanced / Reduced variant of ISO20022 selected for the Hub solution 16
  17. 17. Case Study 2: Payments Engine ScenarioChannel • Relates to commercial payments processing CHAPS/SWIFTSWIFT/ Proprietary/ message • Payments engine package selected for payments processing • Fulfilling Process Services & • Some Business Services SWIFT/ Engine weak on integration • MQ • Lightweight integration middleware selected • Reusable Services implemented using a CDMCDZ Package • XML syntax / XSLT based transformationsISO20022 / Custom / XML Problem • Business Concepts are similar in the channel and CDZ • Message models in the CDZ are unique to the IT landscape of the bank XML/ • CDZ Syntax is different to Channel Syntax XSLT • Integration technology selected not suitable for the channel integration solution • Delay and rework Key Points • Integration space is segmented • Functional and NFR’s may be different • Different technology implementations are allowed / required to support the CDZ 17
  18. 18. Conclusion The final section summarises some generalised design principles 18
  19. 19. Conclusions• Principle: Channel harmonisation and Business Service reuse are maximised through a CDZ comprising the Process Services architectural layer and its associated Business Services interfaces• A CDM based on an extended open, sponsored standard is generally optimal based on several identified evaluation criteria • Provides buffering to the immediacy of standards changes • To further optimise the CDM, consider also a simultaneously extended & reduced form of a standard• It may be required to optimise the CDM to meet specific NFR’s • In these circumstances design tradeoffs have been highlighted• Implementation of a CDZ infers that the Integration space is segmented • Variety of integration requirements must be supported • ‘One size fits all’ solution for integrations to and from the CDZ does not work• Principle: The theoretical minimal CDM comprises the Business Concepts, Messaging Model and Syntax necessary to fulfil the business processes of a given domain CDM = S Domain Data Requirements 19
  20. 20. Recap on ObjectivesNow you have completed this session youunderstand:• The advantages of adopting a canonical data model in a SOA• The key issues in selecting an optimal canonical data model• The architectural impact of operating using a canonical data zone 20
  21. 21. Russian Gracias Spanish Thank You English Thai Merci French Obrigado Brazilian Portuguese ArabicTraditional Cinese Grazie Danke Italian German Simplified Chinese Japanese 21