1.
The Canonical Data ZoneIssues in data selection for Service OrientedArchitecturesGary FarrowIT ArchitectDirector Triari Consulting

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.
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.
Context In this section the context of the canonical data problem is now described 4

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.
Reference Models In this section two reference models are described that are used in the analysis of the canonical data problem 6

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.
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.
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.
The Zone In this section the Canonical Data Zone is defined in terms of the Reference Models 10

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.
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.
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.
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.
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.
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.
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.
Conclusion The final section summarises some generalised design principles 18

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.
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.
Russian Gracias Spanish Thank You English Thai Merci French Obrigado Brazilian Portuguese ArabicTraditional Cinese Grazie Danke Italian German Simplified Chinese Japanese 21