Version

1
Enterprise Architecturerelying on MDM BRMS
Information Systems And Sustainability

• Version 01 - July 07th 2009
• Author - Pierre Bonnet - Orchestra Networks
• pierre.bonnet_at_orchestranetworks.com

2
Condition of use
You can use this document for your own needs and
publications under the condition to quote the
source (author credit) Sustainable IT
Architecture community. This document is
protected by a Creative Commons, described
opposite. This document is freely downloable via
the Sustainable IT Architectures website
http//www.sustainableitarchitecture.com/home
3
List of contributions
You can suggest contributions to improve this
presentation via our online group
http//www.linkedin.com/groups?gid1879652trkhb_
side_g
4
The landscape

• Enterprise Architecture needs proceduresto
  encourage sustainable IS
• The target is both Agility Traceability
• In other words a better IS Business Governance
  driven by business users directly
• Struggling against pure hard-coded approach
• IS Business Governance is deliveredby using
• Master Data Management (MDM)
• Business Rules Management (BRMS)
• Business Process Management (BPM)

Business features Data Rules traceability Collab
orative provisioning Version management Right
management Data querying Model-driven
How to take benefit from MDM, BRMS and BPMto
leverage usual EA?
5
How to achieve this goal?

• With help from a basic concept namedACMS
  Agility Chain Management System
• This is the natural path to restructure IS in a
  progressive and sustainable manner
• First streamline your reference/master data
  (MDM)
• Second streamline you business rules (BRMS)
• And finally include your processes (BPM)
• This brings us to theSustainable IT Architecture
  Framework (SITAF)
• Data and Rules must share an unifiedData
  Architecture
• Processes must rely on a business rules
  referential

6
Why should we need SITAF?

• Existing EA Frameworks such as TOGAF and Zachman
  dont really tackle IS agility
• They dont show the way for restructuring IS with
  help from business referentials MDM and BRMS
• This is an IT approach without sufficient
  openness to the Business Governance
• Why should we need to hard-code reference/master
  data and business rules when MDM and BRMS can be
  used efficiently?
• This is a Business Governance approach mitigating
  bad effects of usual software opacity

FromClosed EA
ToSmart EA
7
Struggling against software opacity

• The bad effects of opaque software arise when a
  pure hard-coding approach is used
• Data and Rules are trapped inside the code
• Documentations are rarely aligned because
  software are modified frequently
• Business users cannot handle IS Assets
• Where are reference/master data?
• Where are rules and processes?
• Over time IT specialists are loosing the IS
  control
• Bad IT alignment with business needs
• High maintenance cost to the detriement of new
  systems and value-added
• Unfortunately most of the time this nightmare is
  a reality
• The whole system is hard-coded whennot using MDM
  and BRMS!

8
IS agility Traceability are not a virtual issue
Business referentials more agile, less opaque

• This is a real example coming from the leading
  insurance company in the construction secteur
  (French SMABTP)

Hard-coded (opaque software)
Years
9
SITAF and SOA
SOA
Extended SOA

• SOA is a blind alley without agility
  traceability mechanisms

DANGER
FULL ROI
Rewriting without externalization of rules and
parameters
Rewriting with externalization of rules and
parameters
Overhaul
New conception
SITAF
Revamping of current applications(web to host,
XML to host, adapters)
Externalization of rules and parameters of
existing applications
Non intrusive
Cosmetic
DISILUSION
TRANSITION
10
From existing silos
Technical silo (MVS)
Technical silo (AS400)
Technical silo (Unix, Java)
Technical silo (Internet)
Functional silo
Functional silo
Functional silo
Functional silo
Functional silo
Customer
Claim
Customer
Financial
Claim
Contract
People
Contract
People
Contract
Product
Product
Permission
Permission
Permission
Permission
Permission
GUI
GUI
GUI
GUI
GUI
?

• No end-to-end processes (no seamless processes)
• Multiple data keying
• Low data quality
• Lack of traceability

?

• Heterogeneous UI
• Permission management is not unified
• Openness to third parties is tricky

?
11
Functional silos
IS Architecture with silos generates duplication
Order entry
Customer care

• Duplication of updating address
• Different GUI
• May be data duplication related to address
  management

Selecting product code
Score analysis
Choosing quantity
Sending mail
Calculating discount
Updating address
Updating address
Using Business Objects and SOA, IS architecture
is enhanced and duplication should be removed
12
Restructuring with an opaque SOAis very risky gt
rigid services
Organizational rules, rights management,
integrity of business transaction, customization
according to execution contexts, orchestration of
services that are located in business stratum.
These orchestrations implements processes and
uses-cases.
ORGANIZATION
Order entry
Customer care
Reusable services for any organization, Business
Objects lifecycles, regulatory rules (core
business rules)
Customer
Order
Product
CORE BUSINESS
Updating address
Selecting product code
Choosing quantity
Choosing discount
Sending mail
Score analysis
13
Restructuring with an efficient SOA means using
MDM BRMS
UI Unified portal
Reference/Master Data Management
Business Rules Management System
MDM
BRMS
VARIANTS
VARIANTS
System inter-working (ESB - Enterprise Service
Bus)
Legacy silos
Technical services
Third parties systems
- Printing - Supervision - Running - ../..
14
Variants of service
Without variants of service
With variants management
Example order entry with three variants
IT
Order entry
service
service
Business
Retailer 1
Retailer N
../..

• Variants are declared according to execution
  contexts
• Products
• Processes
• Right management
• Rules

heavy SOA!
MDM
BRMS
15
The new IS without IT revolution
Inhouse orsoftware package
Inhouse orsoftware package
Inhouse orsoftware package
Inhouse orsoftware package
The active governance with help from referentials
Progressive IS transformation by externalizing
master data, business rules and processes into
the ACMS Backbone
ACMS backbone
CEP/BAM provide active events. It consumes
unified information stemming from ACMS backbone
Referential ofMaster Data
Referential ofBusinessRules
Referential ofProcesses
Activeevents
MDM
BRMS
BPM
CEP/BAM
Extended processes
Traceability
Reporting
Thanks to the ACMS mechanism, IS alignmentwith
regulation constraints such as traceability,audit
ability, versionning, permission managementare
attained
SARBANE OXLEY SOLVENCY II BASEL 2, IFRS

• Active entreprise governance
• Traceability, auditability, one version of the
  truth

EXTERNAL BUSINESS CONSTRAINTS
16
Insight into SITAF

• SITAF at a glance
• Detailed information by levels andEA domains
• Four levels
• Reality, Logical, Referential and Governance
• Two EA domains
• Data
• Processes

17
SITAF at a glance
18
Reality level
UML
UML

• Data and their business lifecycles

Organization is described with help from uses
cases and processes
Organization mustenforce the business
19
Reality level Data issue

• It exists three levels of Data Quality
• Most of the time companies tackle the basic level
  only
• and this is not sufficient to support
  Sustainable IS

Level 3 FULL DATA QUALITY

Level 2 EXTENDED QUALITY

• Semantic modeling to manage the data model
  quality improving the data meaning
  (associations, integrity constrains, rules
  validation, etc.)
• Model Driven MDM
• Data Quality Tools MDM to manage versions,
  contexts and concerns related to time

Level 1 BASIC QUALITY

• Focus on data values only
• Usual Data Quality Tools

• Data Quality Tools MDM to manage versions,
  contexts and concerns related to time

20
Reality level Data issue
Tricky situation
Base 1
Base 2
Base 3
?
A Product (database 1) is created only if the
Factory involved (database 2) is under the
management of an Organization(database 3)
holding an updated Contract (database 4) with
the company or one of its partners (database 5)
duringthe last twelve months
Base 4
Base 5
21
Base 1
Semantic Modeling
Base 2
Rich and Unified data model
The situation becomes clearer when using a rich
data model before data cleansing
Product
Factory
Base 3
manages
Data integration (ESB)
role 2
Organization
Base 4
role 1
Manufacturing contract
Data model
Base 5
A Product (database 1) is created only if the
Factory involved (database 2) is under the
management of an Organization(database 3)
holding an updated Contract (database 4) with
the company or one of its Partners (database 5)
duringthe last twelve months
22
Reality level Data Model Example of Address

• An unified view of the Address whatever countries
• Business operations attached to the main class
  Address are identified with help from the
  business lifecycle (see next slide)

postcode is a derivated attribute respecting a
postcode pattern (rules)
see the complete data model here
www.mdmalliancegroup.com
23
Reality level Data Model Example of Address
State machine
Business objects lifecycle without
organizational concerns
24
Utilization of the state machineto handle data
pre-condition
Yes updated is possible No updated is
forbidden

• This decision table is managed as a
  reference/master data
• version management
• right management
• feeding by contexts
• collaborative management
• traceability

This decision table is plugged into the MDM and
executed automatically without useless
hard-codedgt less opaque more traceable and agile!
25
Business rules

• Business rules are detailled with help from a
  natural language
• These rules are attached to business objects as
  UML operations

26
Data EA
Thanks to Dominique Vauquier, author of the
Praxeme method and co-author of some prebuilt
data models published on MDM Alliance Group
see the complete data model here
www.mdmalliancegroup.com
This is a unified data Enterprise Architecture
relevant for both reference/master data and
transactionnal data
27
Data EA Example of a Data Category

• The data category Geography contains the Adress
  data model (already seen before)
• Therefore the Address is modeled once only
• You must be able to plug and play every data
  category without corrupting the whole enterprise
  data model

see complete modeling rules here
www.mdmalliancegroup.com
Iterative approach within the data EA perimeter
28
Reality level Organization issue

• Usual approach relying on uses cases and
  processes modeling
• Organizational rules are described with help form
  a natural language
• As they can depend on the context (version,
  organization, variants) it is often relevant to
  design meta-rules rather than detailed rules only
• Rules related to right management must be
  distinguished from others
• Indeed right management is managed specifically
  most of the time through a dedicated module

29
Functional EA
This is a unified functional Enterprise
Architecture Usual approach in the field of IS
architecture
30
Logical level Rich data model and usual OLTP
approach
UML
UML
UML
Rules Langage / UML
Rich data model
Rigid modelfor OLTP issue
see complete modeling rules here
www.mdmalliancegroup.com
31
Logical and Referential levels are quite closed
SEMANTIC Logical Data Model (rich data models)
OLTP Logical Data Model (usual data models)
Rules language / SOA
Process
XML Schema
DDL
XML BPEL Etc.
Rules Langage / MDA
MDM(model driven)
DB-OLTP
BRMS / Software Factory
BPM
32
Rich data model MDM versususual OLTP approach
Reference/Master data injection
Model-driven MDM
Hub CDI (OLTP database)
Run time
Gouvernance time
Towards data governance
Reference/Master Data
Transactional Data
Rich and unified data model relying on
relational, object and hierarchical oriented
approches
Rigid data model based on relational oriented
approach only hard-coded development
Consolidation and enrichment
Usual transactional system

• Data governance ensured by business users data
  stewart, data owner
• Version management, data traceability, data
  historic, collaborative data management, feeding
  by contexts, etc.

• Usual users

33
Logical level Rules

• From this level Rules are expressed with the
  BRMS Grammar only (see also OMGs Business Rules
  MetaModel if you want to stay agnostic regarding
  rules grammar)
• Rules set are organized in compliance with
• Data EA building blocks (domains of business
  objets, data category and business objects)
• Functional EA (domains of functions, permission
  rules)
• Except rules that cannot be located at the BRMS
• In other words rules which dont have real
  added-value for the business
• They are implemented with help from a Software
  Factory (MDA) and/or hard-coded
• SOAgt Rules are encapsulated in form of services
  whatever they are located in the BRMS or not

34
RemindergtBRMS without MDM is a blind alley
Tricky situation
Functional silo
Functional silo
Services domain
Reference Dataand parameters
Portfolio of transactions
Portfolio of transactions
Fine grained
R


R
R
R
Meduim grained
R
Coarse grained
R
Import
Request
Request
Import
Import
Spaghetti connections!
Request
BRMS
Rules
Enumeration Decision Tables
Manual keying
Adding a new rule entails developing new data
connections to legacy systems! This is a blind
alley
35
MDM and BRMS reveal IS agility
Functional silo
Functional silo
Services domain
Reference Dataand parameters
Portfolio of transactions
Portfolio of transactions
Fine grained
R


R
R
R
Meduim grained
R
Coarse grained
R
MDM pipeline
Transactional data
Integration layer (EAI,
ESB, ETL)
Refresh
One version of the truth !
Request MDM to retrieve reference data
BRMS
MDM
R
Rules
Enumeration Decision Tables
Reference data and parameters governance
Import
According to ACMS principle first MDM and after
BRMS (not the opposite)
36
Governance level
What are business governance features? gt 6 KEY
FEATURES
37
Ergonomics

• Unified and friendly UI
• Whatever types of Data and Rules
• Customization must be allowed with help from a
  portlet strategy
• Screens must be aligned automatically with data
  models gt Model-driven
• All business governance features must be usable
  by non IT specialists
• Data/Rules Stewarts, Data/Rules Owners,
  Data/Rules Analysts, etc.
• Thanks to these features the IS is no longer
  opaque

38
Version management
GREAT INNOVATION!

• Well-known features used in the field of
  source/code management must be available at the
  level of data and rules management
• Branches and versions
• Comparing and merging data/rules
• Key features to align the IS with business
  regulations
• Data and rules traceability
• Auditability
• Proof of business operations
• Etc.

39
Context management

• Every Data and business Rule can be adapted by
  contexts
• These contexts inherite each other
• Example for a Product discount data
• Corporate10
• Southinherited value (10)
• North15 (overwritten)
• NorthSector01inherited value (15)
• NorthSector0214 (overwritten)

40
Concerns related to time management

• Every Data and Business rule can be adapted
  depending on time management
• Validity dates
• Value by periods
• Discount10 during the night and 5 during the
  day
• Complete historization of data
• From a technical point of view
• gt no data updating just data insertion

41
Approval processes

• Workflow to manage
• Data approval processes
• Rules approval processes
• Involving several types of actors
• Data/Rules Stewarts, Data/Rules Owners,
  Data/Rules Analysts, etc.

42
Rights management

• Permission regarding data and rules administration

43
If you would like further information

• Our websites

http//www.mdmalliancegroup.com/
http//www.sustainableitarchitecture.com/
44
List of contributions
You can suggest contributions to improve this
presentation via our online group
http//www.linkedin.com/groups?gid1879652trkhb_
side_g
45
Thanks

• Contact

The Author - Pierre Bonnet Consultant Manager
Orchestra Networks pierre.bonnet_at_orchestranetworks
.com 06 75 01 54 54 (Paris, France)
End