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.

1. The Canonical Data Zone
Issues in data selection for Service Oriented
Architectures
Gary Farrow
IT Architect
Director Triari Consulting

2. Objectives
By 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. Agenda
1. Context
2. Reference Models
– SOA Reference Architecture
– Canonical Data Meta-Model
3. The Canonical Data Zone Defined
4. Issues in Canonical Data Selection
– Payments Hub and Payments Engine Case Studies
– CDM Strategies & Evaluation
5. 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 / standards
External 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+O
External • Common processes
– Single layer decoupled from channels
Internal
• 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 specific
Standardising across all data categories in all SOA
– e.g. IBM Service Component Architecture
architectural 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 architecture
The 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 demanding
Effort to Develop NFRs
• e.g. Faster Payments / Cards
Requirements Fit ISO 8583
• Commonality of processing
Performance sacrificed to achieve NFR's
Design Solution
Robustness to
• IS020022 supports data
Change requirements for a number of
payments schemes
• Enhanced / Reduced variant of
ISO20022 selected for the Hub
solution
16

17. Case Study 2: Payments Engine
Scenario
Channel • Relates to commercial payments processing CHAPS/SWIFT
SWIFT/ 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 CDM
CDZ Package • XML syntax / XSLT based transformations
ISO20022 / 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 Objectives
Now you have completed this session you
understand:
• 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
Arabic
Traditional Cinese
Grazie Danke
Italian German
Simplified Chinese
Japanese
21