creative commons sustainable it architecture is rating tool course 2010, june beta version 1 1 / 166...

Cre

ativ

e C

om

mo

ns

Sustainable IT Architecture

IS Rating Tool Course

2010, June

Beta Version 1

1 / 166


www.sustainableitarchitecture.com

IS Rating ToolTraining

By Pierre Bonnet - 2010, JuneCreative Commons


This material provides you witha course to learn the key conceptsof the IS Rating Tool

This material is freely available onhttp://www.sustainableitarchitecture.com

You can use this document for your own needs and publications under the condition to quote the source “Sustainable IT Architecture”

This document is protected by a Creative Commons

2 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Agenda

1. Introduction in relation to IS/IT changes2. Terms and definitions3. The IS/IT foundation to enforce a progressive reshaping

4. Rules of thumb5. Data Assessment part6. Rules Assessment part7. Processes Assessment part

Note:You can download freely the IS Rating Tool (spreadsheets open office) via our web sitehttp://www.sustainableitarchitecture.com

3 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

1. Introduction in relation to IS/IT changes

4 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

At the inception of IT: 1960-2000

IS ITrelies on

supports

• No real overlap between IS and IT systems

• Systems were pretty easy to understand and manage• Systems were rigid because of the gap between IS and IT

5 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Current position of IT: 2000-2010

ITWhattarget?

• A world where• no work without a PC• IT systems are everywhere

• Too many overlaps between IS and IT systems• IT systems are opaque, rigid and hard-coded which

generate significant difficulties to distinguish IS from its IT systems

• This situation is a blind alley

IS

6 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Near future of IT: Today ->

• IT systems rely on a new foundation to carry out IS Assets based on Ref/Master Data (MDM), Business Rules (BRMS) and Processes (BPM)

• IS/IT alignment is achieved following a natural path as IT systems are no longer opaque and hard-coded but implemented within business repositories (MDM, BRMS, BPM)

IS + ITMDM

BRMSBPM

RealIS Governance

7 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

In short

IS + ITMDMBRMSBPM

RealIS Governance

ISIS ITITrelies on

supports

ITWhattarget?IS

1960-2000

2000-2010

Today

8 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

BOOM in the data management field

Black box

1960-2000 => under control

Don’t worry… be happy!

9 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


Black box Black box Black box Black box

1960-2000 => under control 2000-2010 => a nightmare

What a mess!

10 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


Black box Black box Black box Black box

Black box Black box Black boxBlack box

1960-2000 => under control 2000-2010 => a nightmare

After 2010 => BOOM in thedata management field

Internet of ObjectsCloud Computing

Rising of IS/IT growth

RFID object Collapse!

11 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

A new IS/IT charter is necessary

Company’s stakeholdersShareholders

Executive ManagementAuditors

GovernmentsEmployees

ClientsSuppliersPartners

IT Internal zone

MDM

BRMS

BPMIS G

ov

ern

an

ce

IT black-boxIS Assets

• This is the sole approach to enforce traceability and auditability of Information (Data, Rules, Processes)

• The holistic use of MDM, BRMS and BPM provide stakeholders with a high level of confidence in their Information System

• Reporting• Risks management• Facing the boom in data management including the Internet of

objects (RFID, intelligent sensors, water meter…)

12 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

2. Terms and definitions

13 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Which terms do we use?

• IS Assets• Linking value• Enterprise Architecture• IS Value (use value, business value, intrinsic value)• Performance level and rating

14 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

IS Assets: what we own, not what we do

Tangible assetsphysical existence

------machines

toolsreal estates

cashhardware

../..

Intangible assetsno physical existence

------brands

Intellectual propertiespatents

knowledge – working proceduresHR - Organizations

Customer relationships - PartnersSoftware (ERP, Legacy, SOA…)

Information System

Ref/Master DataBusiness RulesProcesses

IS Assets

Assets

Accounting,Chart of accounts

Innovative accounting approaches like IAS/IFRS and assets classifications such as Edvinsson & Malone, ARC IC reporting, The Danish Guidelines, Meritum, IC-

Rating, Wissensbilanz, the METI model, the IC-dVAL method, etc.

15 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Value 1

Linking Value

• Creation of additional added-value stemming from a mix of several resources

Value 2

ExampleThe linking-value of Data + Rules

Data Data validation rules

Rules execution

Rules

16 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Enterprise Architecture: state-of-art

• Wikipedia: “An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, its decomposition into subsystems, the relationships between the subsystems, the relationships with the external environment, the terminology to use, and the guiding principles for the design and evolution of an enterprise. This description is comprehensive, including enterprise goals, business functions, business process, roles, organizational structures, business information, software applications and computer systems.”

Business

Information

Application

Technology

standard four layers in EA

To get more information see: Zachman (1987), Togaf, Dodaf, Modaf, Agate, FEA, NIH, the enterprise framework, etc.

strategy, business rules, business processes, organizations, functional decomposition, etc.

Information flow within organization, data models, etc.

applications software, interfaces, etc.

IT infrastructure, databases, programming languages, EAI, etc.

17 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Enterprise Architecture: pitfalls

Pitfalls of Enterprise Architecture Frameworks when there is a misunderstanding

EA Frameworks don’t guarantee a good or bad final IS/IT Architecture

Zachman is just a taxonomy of concepts and modelsTOGAF is architecture agnostic

Therefore you need an IS/IT Architecture targetIt means A VISION TO RESHAPE YOUR IS/IT

To describe your vision you must take into account your real IS Assets

18 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Enterprise Architecture: our contribution

Enterprise Architecture and IS Assets

Data

Rules

Processes

Intrinsic value

Businessvalue

Usevalue

Quality of: the

Knowledge, the

governance

functions and

the IT

Integration

Business

goals,

alignment

business/IT,

IS accounting

Working

procedures,

how people

work together

Regardless of any EA framework, every IS/IT relies on Data, Rules and Processes and their linking value

Regardless of any EA Framework, every IS/IT is measured through its intrinsic value (IS Assets), business value (alignment and ROI), and use value (working procedures)

FIRST TRUTH SECOND TRUTH

Business

Information

Application

Technology

standard four layers in EA

IS Assets value

Architecture viewpoint

IS Assets viewpoint

19 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

IS Value

Intrinsic Value is the actual value of IS Assets regardless of its Use Value and its Business Value. In other words, when a rating is established to measure the Intrinsic Value, then the quality of working procedures, modeling procedures and financial considerations are ignored. IS Assets are based on Data (ref/master data), Business Rules and Processes

Intrinsic Value

IS Rating Tool

20 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

IS Value


Intrinsic Value

The Use Value of IS deals with an assessment of company’s working procedures used by IS stakeholders to communicate, build, maintain and run their Information Systems. When Use Value is studied, specialists in charge of the assessment admit that the IS value is related mainly to its mode of use not to its intrinsic value

Use Value

ISO900x, CobiT, CMMI, PRINCE2, TOGAF, ITIL, etc.

IS Rating Tool

21 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

IS Value


Intrinsic Value

The Use Value of IS deals with an assessment of company’s working procedures used by IS stakeholders to communicate, build, maintain and run their Information Systems. When Use Value is studied, specialists in charge of the assessment admit that the IS value is related mainly to its mode of use not to its intrinsic value

Use Value

Regardless of working procedures, the Business Value of IS tackles the Information Systems quality to align them with business strategy and operational requirements. One significant aspect is the responsiveness, in other words the IS ability to react quickly to change. The Business Value also encompasses the computation of market values, including financial measurement

Business Value

ISO900x, CobiT, CMMI, PRINCE2, TOGAF, ITIL, etc.

IAS-IFRS,financial method to compute ROI

IS Rating Tool

22 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

IS Value: holistic point of view

Intrinsic Value

Use Value

Business Value

Analysis

Bad Bad Bad Worst situation => no real value within such a company

Good Bad Bad

Strange situation => where IS assets are good even though bad working procedures are used (use value). By the way, as the business value is bad either IS assets should be sold to another company, either the company should change its strategic business commitments

Good Good BadStrange situation => where IS assets and working procedures are good whereas business value is not important. This is a similar situation with the previous one

Good Bad Good

Strange situation => where IS assets are good even though bad working procedures are used (use value). Fortunately, the business value is good. The question raised should be: can these bad working procedures damage IS assets over time?

Bad Good GoodSuspect situation => because good outcomes in use value and business value hide a deeper weakness in IS assets (intrinsic value). This good situation in use and business values is unsustainable as the IS assets still remain bad

Bad Bad GoodStrange situation => where business value seems good even though bad working procedures are used (use value) and IS assets are weak (intrinsic value)

Bad Good Bad

Trap situation => where working procedures (use value) are good but IS assets (intrinsic value) and business value still remain bad. In reality, this company has a poor value and the bad quality of its IS assets will generate serious problems soon

Good Good Good Ideal situation => where all values are aligned

23 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Performance level and rating

• Before establishing a financial assessment of IS Assets it is necessary to measure their performance level i.e. their quality

Data

Rules

Processes

Performance level

Performance level

Performance level

Rating

Rating

Rating

Financial assessment



Rating

Rating

Rating

IS/IT point of view Accounting point of view

24 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

3. The IS/IT foundation to enforcea progressive reshaping

25 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

What goals do we have?

Transparency• Allowing a better understanding of IS Assets by all

company’s stakeholders

Auditability• Guaranteeing a full and detailed auditability of IS

Assets used in the past, present and future (version management)

Mastering the complexity• Keeping a stable level of IS/IT complexity

regardless of the business changes and growth

Agility• Allowing rapid and secure changes in data,

business rules and processes

TAMA

ransparency

uditability

gility

astering the complexity

26 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Key principles to achieve the goals

The more the IS/IT is hard-coded the more the transparency is bad

• Duplication of data in rigid and scattered databases• Spreadsheets effects• Programming languages used by IT specialists (Cobol, Java…)• Lack of up-to-date documentation

27 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


The more the IS/IT is opaque the more the auditability is bad



• IT audit trails available to IT specialists mainly• Tunnel effect when using IT programming languages (Cobol, Java…)• Lack of traceability between data, business rules and processes

28 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


The more the IS/IT is opaque the more the auditability is bad



• IT audit trails available to IT specialists mainly• Tunnel effect when using IT programming languages (Cobol, Java…)• Lack of traceability between data, business rules and processes

Reshaping the whole existing IS/IT in one step is impossible

• A natural path to reshape IS/IT must be enforced with an iterative lifecycle implementation: first ref/master data, second business rules and then business processes

29 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Step 1 – Regaining the data control

R/M

Functional silo

R/M

Functional silo

R/M

Functional silo

MDM

Ref/Master data

Unified data model

Step 1. MDM is synchronized with existing

databases

Data governance

Referential/Master data

R/M

Transactionaldata


R/M

Transactionaldata

The MDM approach is deployed with no impact on what already exists, without modifying the data repositories which are already in place in any historical databases

30 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Step 2 – Regaining the rules control

R/M

Functional silo

R/M

Functional silo

R/M

Functional silo

MDM

Ref/Master data

Unified data model BRMS

Business Rules

Step 2. BRMS is used for extracting business

rules locked in silos

Data and Rules governance


R/M

Transactionaldata


R/M

Transactionaldata

Business Rules Management System (BRMS) approach is established to get certain business logics out of the existing hard-coded software and have them translated into a rules language before being placed in the rules repository

31 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Step 3 – Regaining the processes control

New system

Functional silo

R/M

Functional silo

MDM BRMS BPM

Business Rules ProcessesMaster Data

R/M

IS governance (Data, Rules, Processes)


R/M

Transactionaldata


R/M

Transactionaldata

New developments benefit from the ref/master data and business rules that have already been capitalized. At this stage, Business Process Management (BPM) enters into play

The circle is thus closed: the processes, the business rules and the ref/master data are under control. A new IT system is born: an open IT system for business, more open to evolution and more sustainable

32 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Applied to software packages

MDM BRMS BPM

Business Rules ProcessesRef/Master Data

SOFTWARE PACKAGE

Transactional data

IT Integration of MDM, BRMS and BPM

IS Assets

If the MDM were locked within the Software Package scope, then it would mean risks of maintaining or reinforcing the silo effect

This is the same concern with BRMS and BPM

33 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Business triggers to start and lifecycle

which ref/master data? MDM

BRMS

Re

qu

ire

me

nts

Imp

lem

en

tatio

n

1

which business rules?

2

3

Case 1Business Trigger: ref/master data rationalization

which data validation rules?

• In this project lifecycle, the company needs to regain the control of its ref/master data first

• When needed, data validation rules are implemented within the BRMS to guarantee a full transparency and auditability of the data management

34 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Business triggers to start and lifecycle

which processes?



BRMS

BPM

Re

qu

ire

me

nts

Imp

lem

en

tatio

n1

2

3

4

5


BRMS

Re

qu

ire

me

nts

Imp

lem

en

tatio

n

1


2

3

Case 1Business Trigger: ref/master data rationalization

Case 2Business Trigger: processes/rules rationalization


• In this project lifecycle, the company needs to regain the control of its ref/master data first

• When needed, data validation rules are implemented within the BRMS to guarantee a full transparency and auditability of the data management

• In this project lifecycle, the company needs to regain the control of its processes

• To achieve this goal, business rules used by these processes are identified and then ref/master data which are consumed (data scope)

• The implementation lifecycle starts with the MDM applied to the required data scope, following by the BRMS and then the BPM

35 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Lifecycle: top down + bottom up


BRMS

Re

qu

irem

ents

Imp

lem

enta

tion

1


2

3


which processes?



BRMS

BPM

Req

uir

emen

ts

Imp

lemen

tation1

2

3

4

5

which processes?



BRMS

BPM

Req

uir

emen

ts

Imp

lemen

tation1

2

3

4

5

Enterprise Data Architecture

Business Objects

Domains of business objects

Data Category

Enterprise Rules Architecture

Rules classification

Rules naming

Enterprise Processes Architecture

Processes classification

Processes naming

which processes?



BRMS

BPM

Req

uir

emen

ts

Imp

lemen

tation1

2

3

4

5

which processes?



BRMS

BPM

Req

uir

emen

ts

Imp

lemen

tation1

2

3

4

5

En

terp

ris

e A

rch

ite

ctu

re

Top Down

Bottom Up

36 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

4. Rules of thumb

37 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Rules of thumb

• We want to measure the Intrinsic Value of IS• It is based on real IS Assets, it means data, rules and processes

Data• Ref/master (shared data)• Transaction• Decisional• Flow

Rules• business rules• organization rules• security policies

Processes• workflows• uses cases

Applications Services portfolio IT infrastructure

Software packages Networks ../..

Out of the scope of IS Assets because they all rely on Data, Rules and Processes

38 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Rules of thumb

Data

• Ref/master (shared data)• Transaction• Decisional• Flow

Rules

• business rules• organization rules• security policies

Processes

• workflows• uses cases

Linking value Linking value

• We take into account the linking value between MDM+BRMS+BPM

39 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Rules of thumb

Data

• Ref/master (shared data)• Transaction• Decisional• Flow

Rules

• business rules• organization rules• security policies

Processes

• workflows• uses cases

Linking value Linking value

• We take into account the linking value between MDM+BRMS+BPM

• We focus on the IS Intrinsic Value only

IS Intrinsic Value

What we own

IS Use Value

What we do

IS Business Value

What we win

IS Rating Tool CobiT, ITILISOxxxx, etc.

Financial assessment,IAS-IFRS, etc.

40 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

3 domains of assessment

• How data, rules and processes are documented?• What are the modeling procedures used?

Knowledge management

“You own a data model… but is it a low-level description or a semantic model?”

Quick illustrations

Quick example in the next slides

41 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

This is not a semantic data model

• Lack of referential integrity constraints

• No business lifecycle, i.e. no state attribute whereas this is an important ref/master data attribute

• Very poor expressivity as this data model is a flat point of view (data flows)

Figure from OASIS

42 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Address

Object

SiteCoordinate System Code

Location coordinate

::MAG::Business::Utilities::Period

0..1

language

location nature

longitude minutes measure : real

latitude degrees measure : real

latitude minutes measure : real

latitude direction code : real

longitude degrees measure : real

longitude direction code : string

identification code : string

description : string

* *locates

* resides

1

short name : string

full name : string

other details : Text

*

building number (address line 1) : integer

number for the nature (address line 2) : integer

name for the nature (address line 2) : string

additional name (address line 3) : string

post box : string

floor : string

room : string

other details [*] : Text

building name (address line 1) : string

Semantic modeling –

Address stage 1

43 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Address

Object

Country

Currency Code

SiteCoordinate System Code

Location coordinate

City

Territory

Territory Type

Territory Office

Address Nature

Address Code

Postal Code Pattern

Type Territory Office

::MAG::Business::Utilities::Period

*order

manages0..1

language

location nature

1

longitude minutes measure : real

latitude degrees measure : real

latitude minutes measure : real

latitude direction code : real

longitude degrees measure : real

longitude direction code : string

identification code : string


* *locates

* resides

*

serves

name : string

code : string

special code : string

1

0..1 *

1..*

divides in

nom : string* 1

defines

short name : string

full name : string

other details : Text

*

building number (address line 1) : integer

number for the nature (address line 2) : integer

name for the nature (address line 2) : string

additional name (address line 3) : string

archive()

locates

name : string

name : string

name : string0..1

1

post box : string

floor : string

room : string

other details [*] : Text

building name (address line 1) : string

check()

start()

*

locates

*


pattern : string

remove()

complete()

1

territory name : stringincludes

regional phone prefix : string

international phone prefix : string

territory code used : boolean

mail office

manages

city name : string

city code : string

/postal code : string

1

* *

locates

0..1

0..1

/relates to

*

1

*

*

/locates

manages through

time zone offset : string

territory code : string

1

*locates

name : string

time zone offset : string

uses

1 *

* 1

structures by

*

defines

0..1

1

1


Address stage 2

44 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Return To Sender (RTS)

To be checked Valid

To be completed

Archive

Undeliverable as Addressed

Insufficient Address

No such numberstart/start()

check/check() [ok]

[undeliverable]

[insufficient]

[no such number]

[not complete]

complete/complete()

archive/archive()

archive/archive()

remove/remove()check/check()


Address stage 3

Business lifecycle (state machine)

45 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Decision table applied to Address

BUSINESS STATES

ADDRESS Valid Archive

building number yes no yes no no no no no

number for the nature yes no yes no no no no no

name for the nature yes no yes no no no no no

additional name yes no yes no no no no no

building name yes no yes no no no no no

post box yes no yes no no no no no

floor yes no yes no no no no no

room yes no yes no no no no no

other details[*] yes yes yes yes yes yes yes no

yes = modif ication possible / no = modif ication impossible

To be checked

To be completed

Return to Sender (RTS)

Undeliv erable as Addressed

Insuf f icient Address

No such number

Carried out by the MDM automatically when checking data modifications of Address. It means less approach of hard-coding software and more auditability and traceability of integrity constraints applied to ref/master data

MDM

Stored into the MDM

46 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1




• What are governance features available to usersto manage their IS Assets (data, rules, processes)?

Governance features

This part doesn’t deal with the quality of the organization but the quality of the governance features like: version management, permission management, authoring, etc.

“Do you manage you ref/master data with spreadsheets or with a more robust

solution bringing real governance features?”

Quick illustrations


47 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1




• What are governance features available to usersto manage their IS Assets (data, rules, processes)?

Governance features

This part doesn’t deal with the quality of the organization but the quality of the governance features like: version management, permission management, authoring, etc.

• How data, rules and processes are implemented? Are they based on MDM, BRMS and BPM?

IT management

“Do you manage you ref/master data with spreadsheets or with a more robust

solution bringing real governance features?”

“Are your IS Assets hard-coded or managed through business repositories

such as MDM, BRMS and BPM?”

Quick illustrations


48 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

3 domains x 3 types of IS Assets

• This is the IS “Rating Tool matrix”

• It provides nine points of assessments

• Every case of this matrix holds a set of questions to conduct the rating

• Enterprise Architecture is employed at the level of the knowledge management• MDM, BRMS and BPM tools are employed at the level of the IT infrastructure

49 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Set of questions for every case

• About 100 questions to cover the whole matrix

• Each answer is ranked with help from 5 levels

• low• basic• medium• advanced• optimized

• Therefore about 500 points of measure

50 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

A: >=90% B: >=50% and <90% C: >=10% and <50% D: <10%

Letter #1 Letter #2 Letter #3

At the highest level of the consolidation

• Each letter gives a consolidated rank (performance level) for Data, Business Rules and Processes

51 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

IS Rating example – 1/4

This company has a huge risk in Data management (C) and Rules management (C). Its ability to well manage its Processes (B) doesn’t prevent this company from facing a serious IS crisis because of a data and/or business rules loss of control. More precisely, according to its detailed IS rating outcomes, we have to study why its data knowledge is so poor (only 5% = D)? From this first rating, the company’s stakeholders should demand detailed information describing the IS plan to manage data and rules risks.

Once this plan will be delivered, a further IS rating will be done to gauge the IS improvement. May be, this company could decide to raise its data consolidated mark to the "B" level within a year and then attain a "BCB" rating which would be reassuring for its stakeholders.

Then, after a full year of work on data knowledge improvement, the company’s rating goes up to "BCB” (see the next rating card).

52 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


On the basis of this new rating, the company has a huge interest in improving its business rules management to reach a ‘B’ level rather than a poor ‘C’. The key factor to succeed seems to deploy a stronger approach in rules governance, as shown in its detailed IS rating outcomes (21% = C).

After delivering works on rules management, this company achieves this objective and attains a new rating "BBB" (see the next rating card).

53 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


"BBB" is an excellent rating, very reassuring for all IS stakeholders. By analyzing its detailed percentage levels per IS assets (see its detailed IS rating outcomes) additional improvements can be identified to target the "AAA" level.

Don't forget, the rating can be established both at the scale of the whole IS but also within a smaller scope such as a subsystem, a software package, a subsidiary, a web application, etc.

54 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


A progressive path to leverage yourIS Intrinsic Value and drive your Enterprise Architecture

55 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

When using the IS Rating Tool

• Within the IT Department to support and encourage an innovative reshaping of IS/IT based on a holistic use of MDM, BRMS and BPM

• Applied to a subset of the whole IS/IT system such as a business line, an application, a software package, etc.

• When selecting a new software package to gauge its ability to manage data, rules and processes as real IS Assets

• To complement with accounting operations and financial assessments such as IAS-IFRS

Audit

56 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1






Audit

• Between IT Department and IS stakeholders• To contribute to an annual IS assessment

Communication

57 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1






Audit

• Between IT Department and IS stakeholders• To contribute to an annual IS assessment

Communication

• Bench-learning between teams, partners, companies, etc.• As a requirement appended to RFP/RFQ to help selecting contractors

Management

58 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

5. Data Assessment part

59 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering Data Knowledge

Check-list

60 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-KN-01 Enterprise Data Architecture

• Enterprise Data Architecture enforces a politics encouraging a unified data modeling and data knowledge management at the whole scale of the system rather than siloed data modeling and implementations only

• It means that Enterprise Data Architecture is aimed at deploying knowledge management applied to data, at least towards main business objects reused within business rules and processes

• Working procedures and organizational issues are out of the scope of the IS Rating Tool. Indeed, this tool is focus on Intrinsic Value of IS. Other organizational issues should be tackled through frameworks and methods such as CobiT, CMMI, etc.

61 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



Ref/MasterData

Transaction Data

Data flowDecisional

data

DT-KN-01-1. Ref/Master dataCan be established without being intrusive to existing data models and databases. Quick ROI thanks to MDM and Data Governance

DT-KN-01-2. Transactional dataThis level of data architecture is more complicated to attain than ref/master data. Indeed, spending time to redesign existing transactional data models to reduce their duplications and defects could be difficult to justify without IS restructuring

DT-KN-01-3. Decisional dataMost of the time, this data level relies on an Operational Data Store (ODS). The ODS uses a data model stemming from a consolidated view of transactional data and ref/master data models

DT-KN-01-4. Data flowThe purpose of EA applied to data flow is to reuse ref/master, transactional and decisional data models within ETL/EAI/ESB directly

DT-KN-01-5 Unified Data ArchitectureAll types of data (ref/master, transactional, decisional and data flow) share a unified Enterprise Data Architecture relying on common concepts such as Business Objects gathered through Domains of Business Objects

62 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-01-1. Ref/Master data DT-KN-01-2. Transactional data

63 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-01-3. Decisional data DT-KN-01-4. Data flow

64 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-01-5. Unified data architecture

All types of data complement each other, which means that ref/master, transactional, decisional and data flow live together and share the same business objects. For example, the Business Object "Product" holds both ref/master data (its description) and transactional data (e.g. its quantity). It is also reused when conveying data product at the level of the integration layer and reused when statistics are computed by the datawarehouse. To succeed in deploying a Unified Data Architecture, dedicated and suitable modeling procedures must be used. These procedures are aimed at defining and sharing key concepts such as Business Objects, Domains of Business Objects and Data Category (as described in UML by Grady Booch to define business topics). To get further information about these modeling procedures we invite you to visit the MDM Alliance Group (MAG). The MAG delivers modeling procedures supporting a complete Unified Data Architecture foundation (www.mdmalliancegroup.com)

65 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


How to assess unstructured data?

• Even thought the IS Rating Tool is focus on structured data first, you can take into consideration unstructured data as supplemental information added to business objects. It means that no information should exist outside business objects boundaries

How to assess meta data?

• Meta-data are gauged when assessing ref/master data. Let's take an example in the field of Service Oriented Architecture. A repository describing relationships between providers and consumers must be established. There are a lot of meta-data defining services and stakeholders, including service level agreements and security policies. With help from a good data model, all meta-data structures are well-defined and then implemented to the MDM. Therefore, meta-data values are managed as usual ref/master data. It means that if you attain a good mark about the 'DT-KN-01-1 Reference and Master Data' then you should be able to manage all meta-data in a right way

66 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-KN-02 Basic data modeling

DT-KN-02-1. Business DictionaryOne or several business dictionaries are used to gather key business concepts with definitions of terms, taxonomy, synonyms, etc.

The business dictionary should be connected with data models. In other words, documentation of data models (class, attributes...) should be retrieved from the business dictionary directly. Then, if you have a shared business dictionary without linking it to data models then your mark should be 'medium' or 'advanced' only because of the lack of connection with data models. Conversely, the more your business dictionary is shared at the whole scale of the company and reused within your data models the more your mark is raised and should be 'optimized'.

67 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-02-2. Business point of viewBusiness data models are available and maintained regardless of physical implementations and databases schemas

Business data models describe information regardless of IT issues. All business objects should be fully described including all their relationships. Indeed, the more relationships between business objects are described the more valuable data models are. To enforce a sustainable data knowledge, a formal and shared notation should be used such as UML or other DSL depending on the company's culture. The more these business models are shared, known and readable by all IS stakeholders the more your mark should be raised.

68 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-02-3. Logical point of viewLogical data models are derived from business data models. They establish the logical point of view of the data architecture

Logical data models rely on IT database architecture styles such as relational oriented approach, object oriented object, hierarchical oriented approach or a mix of the three. These data models are independent of physical databases schemas. Logical data models are established by using derivation rules from business data models. In other words, these models should be the result of a translation of business data models into logical terms. They are represented with help from a formal notation, such as UML or other DSL. They rely on formal and shared logical naming rules. These data models are not meaningful for business users.

69 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-KN-03 Semantic data modeling

DT-KN-03-1. Business Objects’ lifecyclesThe real semantic of data is revealed through business objects' lifecycles. Indeed, modeling behaviors of business objects allows for establishing rich, reliable and sustainable data models. Without this approach, data models remain static and cannot express the richness of information.Beyond the data modeling procedures, this question copes with the mechanism used to really manage business objects' lifecycles as a real IS Asset, which means using the MDM to manage business objects' states values as master data.

Your mark about the Basic Data Modeling should be 'medium' at least before starting the Semantic Data Modeling


To be checked Valid

To be completed

Archive




check/check() [ok]

[undeliverable]

[insufficient]

[no such number]

[not complete]

complete/complete()

archive/archive()

archive/archive()


Example: Address’ lifecycle

70 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-03-2. Relationships between Business ObjectsThe semantic of a data is revealed through relationships between business objects. These relationships must be managed as a real IS asset rather than poor cardinalities frozen when establishing data models. These cardinalities become real assets when managing them as master data.Beyond the data modeling procedures, this question copes with the mechanism used to really manage cardinalities as a real IS asset, which means using the MDM to manage data cardinality as master data.

Cardinality links (minOccurs, maxOccurs) are managed as master data to ensure a better agility of data models depending on use contexts (head office, subsidiary, partner, country, language, classification, etc.)

../..

11Partner

51Subsidiary

10Head Office

Cardinality (p)Cardinality (n)Use context

../..

11Partner

51Subsidiary

10Head Office

Cardinality (p)Cardinality (n)Use context

MDM

Produit Usine

* on use context (n,p)Product FactoryProduit Usine

* on use context (n,p)

Produit Usine

* on use context (n,p)Product Factory

71 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-03-3. Business rules applied to dataWhen a data element is updated a rules set can be executed to check its integrity. These rules are a part of the Semantic Data Modeling. It is important to keep in mind that this question copes with business rules applied to data elements only, not other business rules spanning a large data scope or organizational rules required to conduct processes.

Business rules applied to data should be gathered through a repository of rules, such as a BRMS (see also Rules Assessment part). With help from this repository, business IS Stakeholders are able to author rules or at least consult them. It is easier to manage their versions and execute them to test the system. Moreover, a link between data models and the rules repository is then established.Business rules applied to data should be collected as follows: rules independent of business objects' states, rules having pre- or post-conditions relying on business objects' states, rules updating business objects' states. This approach means that designing business rules within Enterprise Data Architecture is achieved by taking into consideration business objects' lifecycles.

72 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-KN-04 Ability to act

• This part is aimed at assessing the ability to establish a sustainable funding for Enterprise Data Architecture and the ability to estimate the replacement value of data models

• The ability to act doesn't cope with the maturity of organizations to deliver an effective Enterprise Data Architecture. Indeed, the IS Rating Tool tackles the IS Intrinsic Value only which means that organization issues are not measured here. Therefore, you should use complementary tools such as CobiT and CMMi to assess maturity levels of organizations

73 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-04-1. FundingA budget is established to support the Enterprise Data Architecture.

The decision to raise a funding is dependent on the ROI. Spending time to rebuild data models and improve data documentations is not sufficient to guarantee a real ROI. This is the reason why data models should be reused to set up added-value data governance features to IS Stakeholders.Using a MDM is valuable to transform data models into ROI since real data governance features are brought by the MDM (see DT-GV section.However, this approach is dedicated to ref/master data only. Regarding transactional data, it is less easy to raise funds as the question is: what will we do with new transactional data models if we cannot restructure existing transactional systems? Here, MDM is not usable and data governance features are not really required. This is the reason why the marks 'Medium' and 'Advanced' are reached whereas ref/master data funding is enforced only.

74 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-KN-04-2. Replacement valueAbility of your organization to (re)design data models from scratch (blank page).

The replacement value must be gauged regardless of any financial issue. You must estimate it without any limitation as this is a theoretical assessment only. However when answering this question you have to provide detailed information explaining your score. When data documentations are up-to-date and teams have a good command of data modeling procedures then your score is high. Conversely, when it is difficult to gather data knowledge because of poor documentations and/or lack of specialists in data modeling, then your score should be decreased.

75 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering Data Governance features

76 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


• Data governance features are the business functions used by IS Stakeholders to manage ref/master data. This is a list of business features brought by the MDM, such as data version management, authoring of data, querying, etc.

• The way of these functions are used through processes and organizations are not measured here. Indeed, the IS Rating Tool copes with the IS Intrinsic value which means the list of data governance features, not the quality or maturity levels of organizations to use them

• Amongst these features, a detailed assessment is required to measure the ref/master data version management function. A focus on data quality is also integrated to measure how data governance should improve data quality processes

77 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


Check-list

78 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-GV-01 Reference and Master Data

DT-GV-01-1. Unified ref/master data governance featuresRef/master data benefit from unified and shared governance functions used by all IS Stakeholders, not only by IT specialists

All reference and master data are managed through unified and shared governance functions such as: collaborative authoring data, version management, traceability of data, right management, query, data approval workflow, etc. These functions are applied to any type of ref/master from simple enumerations data to complex data structures such as product configuration, chart of accounts, structure and organization, pricing configuration, customer information, parameters of business regulations, etc.From an IT point of view, data governance functions are brought by a MDM tool which is generic enough to manage all types of data. This is a Model-driven MDM (see also the part 'Mastering IT Approach to manage data')

79 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-GV-01-2. Ref/master data version managementAmongst data governance functions, the version management is a significant feature requiring a specific assessment

The version management of ref/master data is vitally important to enforce a real data governance. It should be possible to create versions applied to any scope of data. A scope can be a data element or a set of business objects linked each other through their relationships. Every version is located to a branch. This mechanism allows for living together several versions of a same data scope located to different branches.For example, a first branch could exist for a production environment and a second branch could be applied to a data matching process. Therefore, a same data scope is both used in production and managed by a data quality process. After executing this process, the data governance allows to compare and merge data scope between its version within the production environment and its version within the data matching environment.

80 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-GV-01-3. Active data qualityRef/master data quality is an acute issue because of heterogeneous existing databases and data duplications. However, when having real data governance functions as seen in DT-GV-01-1 and -2, it becomes easier to tackle this problem in an efficient way.

ProductProduct

Database No.1

FactoryFactory

Database No.2

OrganizationOrganization

Database No.3

AgreementAgreement

Database No.4

PartnerPartner

Database No.5

MDM

Package

Produit Usine

Organisation

Accord de production

fabrique

* *

gère*

1

rôle 1

rôle 2

*

A product (Database No. 1) is only created if the factory code (Database No. 2) which it is

affiliated with is under the management of an organization (Database No. 3) that has an

ongoing production agreement (Database No. 4) with the company or one of its partners

(Database No. 5), that has been active for the past twelve months, at its disposal

Mas

ter

Dat

a In

teg

rati

on

(E

AI/E

SB

/ET

L)

Rich and shared master data model

Product Factory

Organization

Agreement

affiliated

managed

role 2

role 1

Data Steward

Data Quality Tool

1/2

81 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-GV-01-3. Active data quality (next)

The data cleansing process is established by benefiting from the data governance functions brought by the MDM. It means that rather than clean data within data databases with poor data structures, an active data quality process is achieved by using the MDM data model.For example, when adding a new address to the system, its validity is checked by the MDM holding the shared data model about Geography business concepts. This address is validated both in terms of its data structure, its integrity rules and potential duplications. Once the data quality is checked through the data model and its integrity rules, then the address can be transformed if needed and pushed to target databases.During this active data quality process, the new address is stored within a dedicated version and branch avoiding conflicts with current version. The compare and merge data governance functions brought by the MDM allow for deciding which version is the right one. If needed, the MDM can use some data quality functions brought by specialized data quality tools such as: relocation addresses, postal address check, product compliance, etc.

2/2

82 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-GV-02 Transactional data

DT-GV-02-1. Data governance applied to applications oriented dataData governance functions established for ref/master data can be reused to enforce an unified management of transactional data within applications oriented data.

A lot of applications oriented data exist within information systems. These are either spreadsheets handling transactional data such as funding allocations, inventory measures... or light applications designed with help from Rapid Application Development tools (RAD) whose the foundation is the data model itself (e.g. Access). To enforce a full governance of these data without slowing down the delivery of light applications, it is helpful to use the Model-driven MDM and its data governance features rather than spreadsheets and RAD tools. Indeed, these data governance features are not provided by spreadsheets and RAD tools: collaborative data authoring, permission management, version management, querying data, tracking data, complete traceability and auditability, data approval workflows, etc.

83 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-GV-03 Decisional data

DT-GV-03-1. Data governance applied to datawarehousesDatawarehouses use ref/master data coming from operational systems but also defined within their own scopes. These latter should be managed by benefiting from data governance functions brought by the MDM.

Datawrehouses should get ref/master data from the MDM repository gathering ref/master data synchronized with operational systems. Other ref/master data established within the scope of datawarehouses directly should be managed with help from data governance functions brought by the Model-driven MDM.

84 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-GV-04 Data flow

DT-GV-04-1. Data governance applied to data flowTo give to business users an autonomy in their daily data flow management, data governance functions must be applied to data flow as well.

Data flow are both internal data conveyed between systems and external data exchanged with third parties (B2B). Most of the time, these data flows gather a lot of data elements coming from scattered databases within the whole scale of the system. This means that controlling integrity rules between data is very complicated. To fix this problem, data flows should be stored within a Model-driven MDM holding a Common Information Model encompassing all integrity rules and bringing all data governance features useful to track and audit data flows.

85 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-GV-05 Security information

DT-GV-05-1. Data governance applied to security policiesEvery information system needs a lot of data defining security policies. The management of these data should also benefit from data governance functions

All data defining security policies applied to data, rules and processes should be designed through semantic data models and enforced with help from a Model-driven MDM. In other words, these data should be considered as meta-data and then benefit from the data governance features brought by the Model-driven MDM. Following this approach, it is easier to set up shared and unified functions to manage security policies such as: permission management applied to security policies, collaborative data authoring, querying, data version management, etc.

86 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-GV-06 Managing data as a real asset

DT-GV-06-1. Data asset measurementKey indicators should be defined to follow data assets over time

A lot of key indicators could be defined to follow data assets. You should distinguish key indicators applied to data models and those applied to data values. These indicators should be useful to all IS Stakeholders, not only within IT department. Depending on the company's culture, key indicators related to data assets can enrich an IT scorecard and/or contribute to establish a more global scorecard at the whole scale of the system.Defining key indicators is not easy to achieve as it requires a good level of maturity in the management of systems. However, the accuracy of key indicators are less important than their variations over time. It means that you should be interested in trends rather than occasional performances only.Examples of key indicators:- all marks computed with help from the IS Rating Tool could provide a good first level of key indicators- other key indicators applied to data models: rate of data structures duplications, number of business objects, number of business objects' lifecycles, etc.- other key indicators applied to data values: rate of ref/master data misaligned with business regulations, number of version for every business object, rate of data modification by data domains, etc.

87 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-GV-06-2. Data asset overseeingBeyond key indicators applied to Data Assets (see DT-GV-05-1), Business Rules used to oversee some key data values should be established

Overseeing ref/master data and data flow is targeted first as other transactional data should benefit from the supervision enforces by business transactions within applications.When ref/master data repository and data flow are managed with help from a Model-driven MDM, it is easier to set up business rules over the data repository to oversee data values in real time (see DT-GV-01-1 and DT-GV-03-1).For example, overseeing a customer's address could be very complicated when this address is duplicated within several databases without a real master repository. Conversely, when using a Model-driven MDM to manage customers' addresses in complement with existing databases, it is easier to set up business rules over the MDM repository, such as: when the customer's address is updated more than three times within a month then send a real-time alert to the sales department. Applied to a financial classification, such a rule could be: financial classification codes mustn't be updated more than X times within a certain period of time. If this rule is not fully enforced then a real-time alert is thrown to executive managers.To implement these rules as real IS Assets, it is recommended to use a BRMS (Business Rules Management System) and/or a CEP (Complex Event Processing) (see also Rules Assessment part of this IS Rating Tool).

88 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



DT-GV-06-3. Data asset trackingAll data access should be tracked in order to enforce IS traceability.

Ensuring the tracking of all access to ref/master data and data flow is targeted first as other transactional data should benefit from traceability mechanisms established within applications. When ref/master data repository and data flow are managed with help from a Model-driven MDM, a unified business audit trail should be available directly. This audit trail is used to keep track all data access stemming from actors and systems. Query features of the Model-driven MDM allow all IS Stakeholders for seeking and consulting the audit trail, depending on their permissions.

89 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering IT approach to manage data

90 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


Check-list

91 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-IT-01 Reference and Master Data repository

DT-IT-01-1. Model-driven MDMTo enforce agility and scalability of ref/master data repository, it is recommended to use a Model-driven MDM rather than a vertical MDM.A Model-driven MDM is able to manage any type of data, from basic enumerations data and parameters to complex data structures (Product configuration, Structure and Organization, Chart of Accounts, Customer Information, etc.). These data models take benefit from a rich representation of knowledge, which means they enforce all capabilities brought by the semantic data modeling, as described in DT-KN-03.

Using a Model-driven MDM tool allows to generate user interface and services (CRUD) automatically. To achieve this goal, the MDM must combine relational oriented approach with object oriented and hierarchical approaches. It means that the MDM shouldn't rely on a relational approach only (RDBMS/OLTP with poor SQL data description language) but it should take benefit from relational, object and hierarchical data management approaches at the same time. In other words, it should bring ORM (Object Relational Mapping) features over usual RDBMS like Oracle, DB2, SQL-Server... with a rich data description language taking benefit from XML Schema.

Rich data model (Semantic)

OLTP(On-Line Transaction Processing)

CLASSIC MODEL DRIVEN

Model-driven MDMSemantic approach associated with a model driven software development = data governance functions

automatically aligned with data models=> OPEN FOR BUSINESS USERS

CDILack of real

data governance

PIM- PLMWeak data governance

at the whole scaleof the IS

Model Driven Architecture (MDA)Software development based on models

=> FOR IT SPECIALISTS

Object Oriented DatabaseSemantic approach based on a classic

software development=> NOT OPEN FOR BUSINESS USERS

Software development lifecycle

92 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-IT-02 Rules integration

DT-IT-02-1. MDM with rules repository (BRMS)Rules used to enforce data integrity should be implemented through a business rules repository (BRMS) rather than an approach of hard-coding only. It means that all data governance features brought by the Model-driven MDM should be also available to manage business rules.To achieve this architecture, a generic IT interface should be established from the MDM to the BRMS. When rules are triggered by the MDM, it should send a data flow describing the context of execution without any information about rules to execute. It means that the connection from MDM to BRMS enforced the loose coupling architecture pattern. Therefore, when rules are updated there are no impacts to the MDM repository. Furthermore, it is easy to configure a new context of execution within the MDM and author new rules for this context with the BRMS. Thanks to the loose coupling pattern, this configuration can be enforced without any hard-coded software.

BRMSBRMS

Full data flow of the business

object

ON|OFF : BRMS launched | not launched

Business object Product

Pre-condition UpdateProduct()

Configuration

Pre-condition UpdateProduct() : ON|OFF

MDM

access to the configuration database to drive the BRMS

invocation

Proxy

Result

Data governance

Business rules governance

93 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-IT-02 Rules integration

DT-IT-02-2. MDM with events management (CEP)CEP (Complex Event Processing) is complementary to BRMS. It allows to enforce an active overseeing of data in real time. The BRMS waits for an invocation coming from the MDM, whereas the CEP listens to the MDM repository and executes rules depending on data behaviors. The added-value of this mechanism has been measured in DT-GV-05-02. From an IT point of view, the integration of CEP with MDM depends on the ability of the MDM to publish in real-time a full data log containing a detailed description of modifications applied to the repository.

94 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-IT-03 Data Integration

DT-IT-03-1. MDM integration with the rest of the systemTo streamline the MDM integration with the rest of the system, business objects' lifecycles should be used when throwing synchronization events through the integration layer (ETL, EAI, ESB). It means that when a data is updated within the MDM its synchronization with the rest of the system can depend on business objects' states. Then rather than throwing atomic events for every modification occurring within the MDM repository, higher events are used depending on business objects' states. This architecture helps to streamline and secure data integration. To succeed in business objects' lifecycles modeling, you should take into consideration the semantic modeling (DT-KN-03).

ESB

SystemSystem SystemSystem SystemSystem SystemSystem

Data approvalprocess

CUCU CUCU

CUCU

CUCU CUCU

Business object’s lifecycle Return To Sender (RTS)

To be checked Valid

To be completed

Archive




check/check() [ok]

[undeliverable]

[insufficient]

[no such number]

[not complete]

complete/complete()

archive/archive()

archive/archive()


MDM

BUSINESS EVENTBUSINESS EVENT

ESB Configuration

ORGANIZATIONAL EVENT

APPLICATIVE EVENTAPPLICATIVE EVENT

CUCU

Use case

95 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


DT-IT-03 Data Integration

DT-IT-03-2. Data mappingTo streamline the data mapping required when conveying data flow between systems, a pivot format should be established. If this pivot format is IT oriented only then it cannot be used as a real shared and common data model usable at the whole scale of the integration scope. In this situation, a lot of hard-coded developments are required to enrich the pivot format, which means an heavy IT development for every data mapping and troubles when updating existing ones. To fix this problem, semantic data models should be used as pivot formats to conduct data mapping. In other words, this is a model-driven approach applied to the data mapping.When deploying a semantic data modeling (see DT-KN-03) it is valuable to reuse data models as pivot formats. From an IT point of view, it is needed to use a semantic data integration tool able to manage rich data models designed with the semantic data modeling. Semantic data integration tool brings all mapping features needed but also a version management of mapping configurations and tests/debugs functions.

MDMMDM

Semantic integration

Shared ref/master data model

ESB

SystemSystem SystemSystem SystemSystem SystemSystem

Transactional data model

Enterprise Data ArchitectureShared data foundation

Domains of business objects, data categories, business objects, business objects’ lifecycles

Ref/master data model

Data governance

Governance of data mapping rules

Enterprise Architect

96 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

6. Rules Assessment part

97 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering Rules Knowledge

Check-list

98 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-KN-01 Enterprise Rules Architecture

• Enterprise Rules Architecture should be seen as a part of the Enterprise Architecture. Indeed, it tackles rules and complements with Data Enterprise Architecture (see the Data Assessment part) and with Process Enterprise Architecture (see the Processes Assessment part)

• The goals targeted by the Enterprise Rules Architecture are similar to ones established for Enterprise Data Architecture but applied to rules:

• full knowledge management of rules• enforcing a politics encouraging a unified rules modeling at the whole scale of

the system rather than siloed rules modeling and implementations only within opaque IT languages

• About the strategy formulation• The rules management is a key topic as it allows to write down the company's

business and organizational strategy. To achieve this goal in a right way, the strategy should be described by benefiting from Enterprise Data Architecture (Business objects and their lifecycles) and Enterprise Processes Architecture (Processes and uses cases). This is a key point to enforce a real alignment of the company's strategy with its data and processes definitions

99 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



CoreBusiness Rules

OrganizationalRules

SecurityRules

applied to applied to

BR-KN-01-2 Business strategy formulationThe business strategy deals with all rules defining the core business of the company regardless of any organizational issues. Organizations rules can change frequently over time whereas business rules are more stable and represent the company's raison d‘être

BR-KN-01-3 Organizational strategy formulationThe organizational strategy deals with all rules defining how actors must/should act to deliver the business strategy in a cost-effective and optimum way

BR-KN-01-4 Security policies formulationThe securities policies gather all rules defining the permissions management applied to enforce the business strategy and the organizational strategy

Enterprise Data Architecture – Business Objects

Enterprise Processes Architecture – Processes, uses cases

linked to

linked to

BR-KN-01-1 Rules ClassificationThe IS Rating Tool provides a first level of classification that should be seen as the minimum to ensure

100 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-01-1. Rules ClassificationAt least you should have a classification relying on these three types of rules:• Core business rules. These rules are independent of any organizational issue. Whatever working procedures or workflows enforced within the

system, core business rules are identical,• Organizational rules. These rules depend on organizational choices such as working procedures and workflows. When organizations change

then organizational rules must be updated and/or extended,• Security rules. These rules are dedicated to security issues. They can enforce security policies both at the core business level and the

organizational level.

Even though this classification could be enriched differently from one company to another, it should be the basis to enforce.Other types could be added such as: functional, calculation, IT, internal rules versus those related to business regulations, etc.

101 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-01-2. Business strategy formulationBusiness rules should be established by benefiting from the business objects modeling as described in the Enterprise Data Architecture (see Data Assessment part). It means that every business rule should be attached to a well-identified business object or a specific domain of business objects. The business objects' lifecycles allow to establish business rules updating states of business objects (see Data Assessment part).

State machine (business object’s lifecycle) to discover business rules

Business Object

BRBR

BR

BRBR

BR

BR

BRBusiness

Object

BRBR

BR

BRBR

BR

BR

BR

Classification scheme to manage business rules

Business Object


To be checked Valid

To be completed

Archive




check/check() [ok]

[undeliverable]

[insufficient]

[no such number]

[not complete]

complete/complete()

archive/archive()

archive/archive()


BR: Business Rules

102 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-01-3. Organizational strategy formulationOrganizational rules should be established by benefiting from the modeling of processes and working procedures as described in the Enterprise Processes Architecture (see Processes Assessment part). It means that every organizational rules should be attached to well-identified processes or working procedures (uses cases).

Step Step Step

Step

Step

Actor 1, Tps1 Actor 2, Tps2 Actor 2, Tps3 Actor 5, Tps5

Actor 4, Tps3

Activity Activity Activity

Activity

Activity

Actor 1, Tps1

process(long-runningtransaction)

use case(atomic transaction)

103 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-01-4. Security policies formulationSecurity policies should be distinguished from other types of rules such as business and organizational rules. By isolating these rules it becomes easier to oversee them and ensure specific control. Even though they are isolated, they should rely on the same description process as one used to establish business and organizational rules. It means that security policies should be attached to either business objects stemming from the Enterprise Data Architecture or processes and uses cases stemming from the Enterprise Processes Architecture.

104 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-KN-02 Rules modeling

BR-KN-02-1. Rules grammarA rules grammar should be used to author all types of rules as described in BR-KN-01-1: core business rules, organizational rules, security policies. Many languages can be used depending on the company's culture. It could be a specific grammar such as a functional pseudo-code, a standard approach such as SBVR (Semantics of Business Vocabulary and Rules) from OMG, but also a rules grammar stemming from a rules engine also known as a BRMS (Business Rules Management System).

In any case, this grammar should be meaningful for all IS Stakeholders (not only IT specialists) and should be either IT runnable directly or translatable into runnable IT components.

Example of business rules from OMG SBVR specification (January 2008)

105 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-02-2. Rules namingA unified rules naming should be enforced to support the knowledge sharing. It should follow the rules classification as defined in BR-KN-01-1 by enforcing code such as: COR (core business rules), ORG (organizational rules) and SEC (security policies). Moreover, this naming rules should not include any specific code stemming from projects as reuse must be encouraged. It means that the rules naming should be aligned with Enterprise Architecture's concepts such as domains of business objects, processes... as defined through the Enterprise Data Architecture and the Enterprise Processes Architecture.

106 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-02-3. Rules set and dependenciesRules can be linked to each other to meet business requirements. Therefore, it becomes necessary to define sets of rules and links between rules.In order to encourage readability and reusability of rules, it should be possible to define sets of rules. Moreover, links between rules and sets of rules should be available to establish complete executions flows of rules meeting requirements.

Example of rules flow (Ilog) – Quote from “Sustainable IT Architecture” book, Wiley

107 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-02-4. Rules templateRules can be linked to each other to meet business requirements. Therefore, it becomes necessary to define sets of rules and links between rules.In order to encourage readability and reusability of rules, it should be possible to define sets of rules. Moreover, links between rules and sets of rules should be available to establish complete executions flows of rules meeting requirements.

Business Object

Business Object

Business Object

Business Object

Business Object

Business Object

Business Object

Rule Template

• predefined operators• predefined values

Rule authoring

Rule authoring

Rule authoring

Rule authoring

• Subset of data

108 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-02-5. Reference and Master Data values applied to rules definitionsWhen authoring rules, many reference and master data values are used. For example: types of clients, products hierarchy codes, marketing codes, pricing configurations, discounts values depending on countries, structures and organizations codes, functional and IT parameters, etc.

All reference and master data values should be retrieved from a unified data repository ensuring a high quality of data. It means that the rules definitions are aligned with ref/master data values stemming from the MDM (Master Data management). To get more details about the MDM see the Data Assessment part.

Rulesrepository

Ref/masterdata

repository

Authoring rules uses data definedin the ref/master data repository

(BRMS) (MDM)

109 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-KN-02-6. Transactional data subsets Applied to rulesModeling procedures should exist to establish the default transactional data set on which a rule can be defined and executed. These data sets should be established with help from the Enterprise Data Architecture and the Enterprise Processes Architecture.

For example, a rule applied to the business object Customer can use all data related to this business object's data structure. It means that rather than designing a specific data set for each rule, it is recommended to reuse data structures stemming from the Enterprise Architecture. In doing so, readability and maintainability of rules and data knowledge are reinforced.

Enterprise Data ArchitectureVocabulary, Information Architecture

Enterprise Rules Architecture

reuse

110 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-KN-03 Rules enforcement

BR-KN-03-1 Explicit demand versus event activationMost of the time, rules are executed through explicit demands submitted by human actors and IT systems.

However, beyond this usual approach, rules should be also executed when events are thrown within the system, regardless of explicit demands. Using events to enforce rules is very powerful and complements with usual explicit execution mode. From an IT point of view, this approach requires a CEP tool (Complex Event Processing) which complements with the BRMS (Business Rules Management System).

On each stock variation greater than 100within the last 20 seconds then execute <<RULE>>

Example of a rule executed only if well-identified events are validated

(BRMS extended to CEP – Complex Events Processing)

111 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-KN-04 Ability to act

BR-KN-04-1 FundingThe decision to raise a funding is dependent on the ROI. Spending time to establish a unified and shared rules classification and grammar is expensive. Therefore, the drivers to engage such a funding should be well-argued. At the very least, they include these four benefits:- better readability of rules which is a significant gain to ensure business-IT alignment and audit operations,- better reusability of rules which can be a real gain to streamline design and maintenance costs,- ability to set up a translation of rules into runnable IT components which is a right way to decrease IT costs and enforce the business-IT alignment,- reinforce the knowledge management applied to rules. It means a better command of the strategy formulation benefiting from a full and unified description, aligned with the Enterprise Data Architecture and the Enterprise Processes Architecture.

When these benefits are not well-understood within the organization it becomes difficult to engage sustainable funds supporting the Enterprise Rules Architecture. It means that the knowledge management of rules is not viewed as a key factor to support the business and its formulation.

112 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-KN-04 Ability to act

BR-KN-04-2 Replacement ValueAbility of your organization to (re)author rules from scratch (blank page).

The replacement value must be gauged regardless of any financial issue. You must estimate it without any limitation as this is a theoretical assessment only. However when answering this question you have to provide detailed information explaining your score. When rules documentations are up-to-date and teams have a good command of rules modeling procedures then your score is high. Conversely, when it is difficult to gather the knowledge of rules because of poor documentations and/or lack of specialists in rules authoring, then your score should be decreased.

113 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering Rules Governance features

114 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


Check-list

115 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


• Rules governance features are the business functions used by IS Stakeholders to manage rules. This is a list of business features brought by the BRMS, such as rules authoring, version management, auditability, etc.

• The way of these functions are used through processes execution and organizations are not measured here. Indeed, the IS Rating Tool copes with the IS Intrinsic value which means the list of rules governance features, not the quality or maturity levels of organizations to use them

• Amongst these features, a detailed assessment is required to measure the rules lifecycles and version management function

116 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-GV-01 Rules governance

BR-GV-01-1 Unified rules governanceAll rules are managed through unified and shared governance functions such as: authoring rules, version management, traceability of rules executions, rules history, rules tests, rights management, etc. These functions are applied to every type of rules: core business rules, organizational rules and security policies (see BR-KN-01-1).

From an IT point of view, these business governance functions are brought by a BRMS (Business Rules Management System).

117 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-GV-01-2 Rules lifecycles and version managementThe lifecycle and version management of rules is vitally important to enforce a real rules governance. Two types of features are needed:- It should be possible to create versions of rules and compare versions,- it should be possible to manage stages of rules from their inceptions to their retirements.

It means that at any time, it should be possible to reverse rules changes by benefiting from a full version history of rules authoring.

Rules used data which should benefit from the version management brought by the MDM applied to ref/master data structures and values (see Data Assessment part). It means that every rule should have a context identifier defining in which version of data its execution is issued. In doing so, when the BRMS looks up the MDM to retrieve ref/master data values, it provides the context in which this request is issued, then the version.

Rulesrepository

Ref/masterdata

repository

Get data in a specified version and context

(BRMS) (MDM)

• context: headquarter, subsidiary, territory, language, etc.• version: working, production, training, regulatory, etc.

118 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-GV-01-3 Rules authoringA unified rules authoring function should be available for all IS Stakeholders and managed through a secured authentication. It means that authoring rules should not be dedicated to IT specialists only. According to the company's culture, key business users can be involved in authoring rules directly or prefer to delegate this work to IT teams. In any case, rules should rely on a business oriented grammar ensuring a full business understanding and formulation of rules (see also BR-KN-02-1 Rules grammar).

119 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-GV-02 Managing Rules as a real Asset

• Rules are a real IS Asset changing over time. They allow to formalize the business strategy, the organization strategy and the security policies (see BR-KN-01-2, 3 and 4). It is significant valuable to measure trends rather than occasional performances only. It means that key indicators should be defined and measured over time

• Moreover, it is valuable to set up rules overseeing rules. This approach allows to throw alerts in real time when needed

• As a real IS Asset, all rules executions should be tracked through a unified business audit trail

120 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-GV-02-1 Rules Asset measurementKey indicators should be defined to follow rules assets over time.A lot of key indicators could be defined to follow rules assets. You should distinguish key indicators applied to rules executions and those applied to rules definitions. These indicators should be useful to all IS Stakeholders, not only within IT department. Depending on the company's culture, key indicators related to rules assets can enrich an IT scorecard and/or contribute to establish a more global scorecard at the whole scale of the system. Defining key indicators is not easy to achieve as it requires a good level of maturity in the management of systems. However the accuracy of key indicators are less important than their variations over time. It means that you should be interested in trends rather than occasional performances only. Example of key indicators:- number of rules related to a business regulation, number of rules modifications within a period of time, number of rules executions within a period of time, rules not used within a period of time, rules used the greatest number of time during a period, ratio of business rules compared to organizational rules per business unit within the company, all measures brought by the IS Rating Tool, etc.

Rules repository

Definition Execution IS/IT Scorecard

Enterprise Scorecard

Other assets/indicators

121 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-GV-02-2 Rules Asset overseeingBeyond key indicators applied to rules assets (see BR-GV-02-1), rules overseeing some key business and organizational rules and security policies should be also established.

When rules are managed through a rules repository such as a BRMS, it becomes easier to add alerts to oversee them. These alerts can check the outcomes of rules executions but also can react depending on thresholds applied to key performance indicators (see BR-GV-02-1). Alerts are defined as rules and benefit from the rules management system. For example:- outcomes of a rule must be conformed to min/max values constraints. It means that all post-conditions applied to rules could be considered as rules overseeing,- maximum number of a rule execution within a period of time,- etc.

Rules repository

Definition Execution

Rules overseeing

Alerts/Indicators

122 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-GV-02-3 Rules Asset trackingAll rules executions should be tracked in order to enforce IS traceability.

When a rules repository is enforced by a BRMS, then a unified business audit trail should be available directly. This audit trail is used to keep track all rules executions. Query functions allow all IS Stakeholders for seeking and consulting the audit trail, depending on their permissions.

123 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering IT approach to manage rules

124 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


Check-list

125 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


• All rules descriptions ensured with help from the Enterprise Rules Architecture (see BR-KN) and managed through rules governance functions (see BR-GV) shouldn't be diluted through an heavy and rigid hard-coded development only

• It means that to ensure a good Business-IT alignment, a rules engine should be used. When it is enriched with rules governance features, as discussed in BR-GV, it becomes a Business Rules Management System (BRMS)

126 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-IT-01 Rules engine versus hard-coding

BR-IT-01-1 BRMS applied to existing systemsTo leverage existing systems without overhauling them, it is recommended to extract key hard-coded rules to rewrite them with help from the BRMS.Modeling and implementation procedures should exist to enforce a progressive extracting of existing hard-coded rules for the benefit of the rules engine. In doing so, the readability, agility and ability to audit the system is really improved. When combining this approach with an efficient Enterprise Rules Architecture (see BR-KN), your company can attain a better Business-IT alignment.

Example of rules extraction – Quote from “Sustainable IT Architecture” book, Wiley

127 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-IT-01-2 BRMS applied to new developmentEvery new development and software package customization should benefit from the BRMS in order to improve transparency, agility and ability to audit systems. A strategic long-term plan should be defined to endorse the BRMS use at a large scale of the system.

Modeling and implementation procedures should exist to support the BRMS use rather than an approach of hard-coding only. It means that the number of rules grows when developing and acquiring new systems, including software packages such as ERP. Indeed, customizations of software packages should be put to the BRMS to ensure a better rules traceability and a better way of managing software packages upgrades.

128 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-IT-01-3 Level of hard-coded rulesRegardless of your mark about the BRMS applied to existing systems and new developments (BR-IT-01-1, 2), you should be able to measure the level of hard-coding of rules within the system.

You should be able to estimate the level of hard-coded rules within the system. Without any rule engine, your mark is bad. When using a rule engine, your mark depends on how it is deploy within the system.

129 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-IT-02 Rules execution and test

BR-IT-02-1 BRMS applied to batch operationsThe BRMS shouldn't be limited to real-time operations only. Most of the time, a significant part of the system works in a batch mode and rules can be shared with ones used in real-time system. Moreover, it could be helpful to restructure batch treatments with a rules engine for restructuring them into more real-time executions.

Most of the time the BRMS is applied to real-time operations first. However, to really improve the agility and traceability of the whole system, it is necessary to tackle rules within batch operations also. Then modeling and implementation procedures should exist to enforce the BRMS use when designing batch operations.

Today's new BRMS technologies remove many IT barriers in term of rules execution performance. For example, some BRMS tools allow for automatically translating business rules into Cobol language and then compile it to run on mainframes directly.

Beyond this IT ability to execute large set of rules, modeling procedures should be also well-established to redesign usual heavy batch operations in more real-time ones. As business is becoming more agile and real-time then the level of batch operations should decrease for the benefit of real-time operations.

130 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-IT-02-2 BRMS with MDMIn order to deploy the BRMS at a large scale of the system, it is necessary to streamline data quality first. It means that reference and master data values used by rules should be retrieved through a unified data repository providing the “one version of the truth”, in other words a MDM must be enforced.

When a rule is executed, it consumes two natures of data. First transactional data stemming from the system issuing the rule execution request. Second, reference and master data. For those data their origin is more complicated as they are often duplicated and scattered across the whole IS. Then when adding a new rule within the BRMS, this question is raised: where must we retrieve reference and master data values for this rule? Are they provided by the system issuing the rule execution request? Are they provided by other siloed systems? Are they provided by the integration layer? In short, adding a new rule within the BRMS could become a nightmare when ref and master data values are not well-managed. To fix this problem, it is necessary to establish a reference and master data repository first, in other words a Master Data Management solution (MDM).

Moreover, to succeed in this approach, modeling and implementation procedures should exist to ensure that the unified data model designed for the MDM is well-established to support rules integration as described here.To get more information about those modeling procedures we invite you to visit the MDM Alliance Group community (www.mdmalliancegroup.com).

131 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-IT-02-3 Test rules against requirementsWhen using a BRMS, rules are both readable by business users and IT runnable directly. It avoids heavy waterfall lifecycle development where rules are testable after having implemented them only. Even though all tests cases are not runnable before some IT integration and development, the ability to test rules when using a BRMS is significant improved. Furthermore, it is highly recommended to set up non regression user acceptance tests of rules.

Rulesrepository

non regression user acceptance tests

Ref/masterdata

repository

(BRMS)

(MDM)

data tests cases and outcomes

get data

132 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



BR-IT-02-4 BRMS loose-coupling architecture (1/2)To enforce a real agile rules management, it is recommended to follow the loose-coupling architecture. Then, three patterns should be used:-agnostic request: when a system issued a rule execution request, it mustn't know which rules could be run. It means that the requester is agnostic towards rules. It provides to the BRMS a context only. With this context, the BRMS must be able to compute which rules are the right ones to execute,-data context: the context provided by the requester to the BRMS must be comprised of a header and a body. The header brings the call context including the caller's identifier and from where its requests is issued such as its pre-condition or post-condition. The header should integrate other information such as a version label. The body is comprised of all data related to business objects handled by the caller. It means that rather than conveyed a specific data flow, it is more agile to send a large data flow. Thanks to this approach, when adding a new rule requiring new data values, it is more likely that these values are already conveyed by the caller, which avoids a useless software maintenance,- variation points: within the logical architecture of the system, it is highly recommended to set up some patterns establishing systematic calls to the BRMS, even if no rules are required when designing the first version of the system. For example, every pre- and post-condition of services (SOA) should integrate a call to the BRMS when implementing the software. Afterwards, when it is time to configure the system, it is easy to add new rules to customize pre- and post-conditions of services without any software maintenance.

Example of BRMS loose-coupling architecture – Quote from “Sustainable IT Architecture” book, Wiley

133 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


BR-IT-02 Rules execution and test (2/2)

BR-IT-02-4 BRMS loose-coupling architecture (2/2)

134 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

7. Processes Assessment part

135 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering Processes Knowledge

Check-list

136 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


PR-KN-01 Enterprise Process Architecture

• Enterprise Process Architecture should be seen as a part of the Enterprise Architecture. It complements with the Enterprise Data Architecture and the Enterprise Rules Architecture

• Most of the time, companies hold a good command of their processes map, by using disciplines such as City IT Planning or (in French term) “IS Urbanization”

• However, processes are too often documented and managed without taking care of underlying rules and data

• This missing link with data and rules is a significant problem because the true value of processes depends on the quality of data and rules

• To tackle this issue, the Enterprise Process Architecture must take into account the outcomes stemming from the Enterprise Data Architecture (Business Objects and their lifecycles) and the Enterprise Rules Architecture (organizational rules)

• By suggesting a classification of processes, the IS Rating Tool highlights how to align every type of process with data and rules

137 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



Business Line Business Line Third party

Core Process

Process

Micro-Process(use case)

Core Process

Process

Micro-Process(use case)

PR-KN-01-3 Business line organization formulationThis is an intermediate description of the organization. It allows for describing internal goals for every company's business line

PR-KN-01-2 Transversal organization formulationThis is the highest description of the organization, most of the time it allows for describing strategic goals related to the company's value chain

PR-KN-01-4 Activity formulationThis is the more detailed description of the organization. It allows for describing concrete interactions between one actor and the system through uses cases (micro-processes)

PR-KN-01-1 Processes ClassificationThe IS Rating Tool provides a first level of classification that should be seen as the minimum to ensure

Enterprise Rules Architecture – Organization rules

linked to

Enterprise Data Architecture – Business Object

linked to

linked to

linked to

138 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



PR-KN-01-1. Processes ClassificationAt the very least you should have a classification relying on these three types of processes:

• Core process: this is transversal process, spanning several business lines within the organization, and/or through external systems under the control of third parties. A core process is composed with steps orchestrating mainly processes. In certain context, a core process can also orchestrate micro-processes directly (see below). The core processes form the company's value chain

• Process: this is internal process, the execution of which is limited to the scope of one business line only. A process is composed with steps corresponding to micro-processes, also called uses cases

• Micro-process or use case: this is a working procedure defining an inseparable set of interactions between one actor and the system. A micro-process is always embedded within a process or a core process.

Micro-process (use case) is an atomic process. It means that its execution leaves the system in a stable organizational state. It involves one actor only.

Core process and process are long-running processes. Their execution involves several actors, the coordination of which is ensure through a workflow mechanism (push / pull of users tasks)

Even though this classification could be enriched differently from one company to another, it should be the basis to enforce. Other types could be added such as: value-chain, functional, calculation, IT, internal versus those related to business regulations, etc.

139 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



PR-KN-01-2. Transversal organization formulation (value chain)This is the highest description of the organization, most of the time it allows for describing strategic goals related to the company's value chain. Be cautious to not confuse this with the “company's raison d'être” which is defined in the Enterprise Data Architecture part:

- “company's raison d'être” is related to the business strategy formulation. It means rules defining the core business without any organizational issues (see BR-KN-01-2)

- company's value chain describes what are the goals of the company applied over its core business: customer effectiveness, cost reduction, HR incentives, stakeholders communication, etc.

The transversal organizational formulation relies on the core processes description. These processes handle organization rules that should be managed as described in the Enterprise Rules Architecture (see BR-KN-01-3 Organizational strategy formulation)

140 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



PR-KN-01-1. Business line organization formulationThis is an intermediate description of the organization. It allows for describing internal goals for every company's business lineThe business line organization formulation relies on the processes description. These processes handle organizational rules that should be managed as described in the Enterprise Data Architecture (see BR-KN-01-3 Organizational strategy formulation).

Most of the time, a process handles one main business object, the description of which is available through its lifecycle (DT-KN-03-1 Business Objects' lifecycles). To obtain a first conceptual version of the process, it is possible to upside down the business object's lifecycle. The outcome is a set of conceptual steps describing how the business object must be handled over time, regardless of any organizational choice.

With the UML notation, the state machine which describes the business object's lifecycle is translated into an activity diagram with one swimlane. This swimlane represents a conceptual organization, it means an organization which would have one actor only.

In doing so, it is easier to measure the discrepancies between the core business (defining by business objects and their lifecycles = “company's raison d'être”) and the organization establishes with the business line organization formulation.

141 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



PR-KN-01-4. Activity formulationThis is the more detailed description of the organization. It allows for describing concrete interactions between one actor and the system through uses cases (micro-processes).

The activity formulation relies on the micro-processes description (a.k.a. uses cases). Every use case orchestrates a set of activities, it means an action between one actor and the system. These micro-processes must be aligned with business objects described in the Enterprise Data Architecture (see DT-KN-01-5 Unified Data Architecture). Indeed, every activity must interact with one and only one business object. Examples of activities within an insurance company: cancel an Accident, search for a Contract, select a Client, visualize the insured Guarantees, etc. It means that activities are streamlined and don't admit data duplications.

The sequencing of a set of activities describes a micro-process or use case. Organization rules applied at this level are related to the piloting of the interaction between one actor and the system. They are not strategic as ones described at the level of the transversal and business line formulations. They are more operational

142 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


PR-KN-02 Process modeling

PR-KN-02-1. Processes notationRather than a pure informal description of processes, using a well-recognized notation brings many benefits: encourages knowledge sharing, improve auditability, allows for automatically translating processes into runnable IT components

A unified and recognized notation should be used to define processes as described in PR-KN-01-1 Processes classification. Core processes and processes can be defined with help from a process flow diagram (activity diagram in UML or with other DSL such as BPMN - Business Process Modeling Notation). Micro-processes (uses cases) are better designed with help from state machine, as each use case represents a set of interactions between one actor and the system; indeed only one “swimlane” is required as only one actor is involved in the process. A “swimlane” is a visual element used in process design to show the behavior of one actor.Last but not least, as processes handle business objects, it is more relevant to use a notation compliant with one used for the Enterprise Data Architecture. Most of the time, only the UML notation can support this unified view between Enterprise Processes Architecture and Enterprise Data Architecture

In any case, this notation should be meaningful for all IS Stakeholders (not only IT specialists) and should be either IT runnable directly or easily translatable into runnable IT components

143 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



PR-KN-02-2. Processes namingEvery process must have a unique naming allowing its identification in an easy way.

A unified processes naming should be enforced to support the knowledge sharing. It should follow the processes classification as defined in PR-KN-01-1 by enforcing code such as: COR (core processes), PRO (processes) and USE (micro-processes also called uses cases). Moreover, this naming should not include any specific code stemming from projects as reuse must be encouraged.

144 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1



PR-KN-02-3. Organization and security rules applied to processes definitionsProcesses execute a lot of rules to deliver their added-values. These rules should be authored with help from the grammar and naming stemming from the Enterprise Rules Architecture

Beyond rules, all data defining organization behaviors and security policies over your processes are unified and managed through the master data referential (MDM) so as to benefit from all business data governance features (see also data assessment)

145 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


PR-KN-03 Ability to act

PR-KN-03-1. FundingA budget is established to support the Enterprise Process Architecture.

The decision to raise a funding is dependent on the ROI. Most of the time, companies are more willing to spend money on describing their core processes rather than their data and rules used across the whole system. It means that the knowledge of processes still remains rough as data and rules handled by processes are not sufficiently described. Therefore, the budget raised for the Enterprise Process Architecture should be aligned with budgets dedicated to the Enterprise Data Architecture and Enterprise Rules Architecture. It means that executive managers should have a better understanding of the benefits targeted through the Enterprise Data Architecture and Enterprise Rules Architecture.

When budget applied to Enterprise Process Architecture is not aligned with rules and data management, it means that the processes knowledge is rough and not aligned with the reality of IT systems that run data and rules.

146 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1


PR-KN-03 Ability to act

PR-KN-03-2. Replacement valueAbility of your organization to (re)author processes from scratch (blank page).

The replacement value must be gauged regardless of any financial issue. You must estimate it without any limitation as this is a theoretical assessment only. However when answering this question you have to provide detailed information explaining your score. When processes documentations are up-to-date and teams have a good command of processes modeling procedures then your score is high. Conversely, when it is difficult to gather the knowledge of processes because of poor documentations and/or lack of specialists in processes authoring, then your score should be decreased.

147 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering Processes governance features

148 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Check-list


149 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-GV1-01 Processes governance

• Processes governance features are the business functions used by IS Stakeholders to manage processes. This is a list of business features brought by the BPM (for core process and process) and the BRMS (for micro-process also called use case), such as authoring, version management, auditability, etc.

• The way of these functions are used through the processes execution and across organizations are not measured here. Indeed, the IS Rating Tool copes with the IS Intrinsic value which means the list of processes governance features, not the quality or maturity levels of organizations to use them

• Amongst these features, a detailed assessment is required to measure the processes lifecycles and version management function

• A distinction between core-process, process and micro-process must be ensured, following the processes classification already established in PR-KN-01-1


150 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-GV-01-1. Unified processes governance applied to core processes and processesThis question deals with core processes and processes only. Micro-processes are managed through other governance functions (see PR-GV-01-2). In this question, the generic term “process” is used to describe both core processes and processes.

Reminder: processes are classified following these three types: core process, process (limited to the scope of one business line) and micro-process (use case). See PR-KN-01-1 Processes classification

All core processes (over business lines) and processes (limited to the scope of one business line) are managed through unified and shared governance functions such as: authoring, version management, traceability and monitoring of processes, process history, process simulation and test, rights management, etc.From an IT point of view, these business governance functions are brought by a BPM tool (Business Process Management) also called workflow engine



151 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-GV-01-2. Unified processes governance applied to micro-processesThis question deals with micro-processes (uses cases) only. The governance functions applied to other types of processes (core process and process) are described in PR-GV-01-1

Reminder: processes are classified following these three types: core process, process (limited to the scope of one business line) and micro-process (use case). See PR-KN-01-1 Processes classification

All micro-processes should benefit from a unified and shared governance approach: authoring, version management, traceability and monitoring of micro-processes, micro-process history, micro-process simulation and test, rights management, etc.However, using a process management tool such as a BPM to govern micro-processes is not always relevant. Indeed, every micro-process (or use case) describes an inseparable set of interaction between one actor an the system. Therefore pushing tasks between actors (tasks list) is not needed. Furthermore, governing these micro-processes through a formal representation (flows diagram) would be too rigid and complex due to their fine-grained dynamic and their variability.

BPM is more relevant when processes are stable enough to be modeled in a formal notation and then executed. This is the case when modeling core processes and processes. But to govern the fine-grained level of processes, in other words, micro-processes (uses cases), it is more efficient to author rules (BRMS). Even if the design relies on a state machine (see PR-KN-02-1 Processes notation) the governance is carried out with the rules management rather than a BPM. In doing so, it is easier to manage variants of uses cases depending on uses contexts, thus the formal representation brought by the BPM is not required.

Your company should have guidelines to conduct the choice of using BRMS rather than BPM to govern uses cases



152 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-GV-01-3. Processes lifecycles and version managementAmongst processes governance functions, the lifecycle and version management is a significant feature requiring a specific assessment

The lifecycle and version management of processes is vitally important to enforce a real processes governance. Two types of features are needed:- It should be possible to create versions of processes and compare versions,- it should be possible to manage stages of processes from their inceptions to their retirements.

It means that at any time, it should be possible to reverse processes changes by benefiting from a full version history of processes authoring.

Depending on the type of process, either BPM (core process and process) or BRMS (micro-process) is used to provide unified governance functions (see also PR-GV-01-1 and PR-GV-01-2).

Processes used data which should benefit from the version management brought by the MDM applied to ref/master data structures and values (see Data Assessment part). It means that every process should have a context identifier defining in which version of data its execution is issued. In doing so, when the BPM/BRMS looks up the MDM to retrieve ref/master data values, it provides the context in which this request is issued, i.e. the version.

Important note: the value linking with the rules version management is not valuable as a loose-coupling IT integration should be enforced between the BPM and the BRMS. It means that the BPM knows the version/context (data) in which it executes processes, but not the rules versions that the BRMS must enforce. The BRMS is autonomous to compute the right version of set of rules to apply depending on contexts and versions information stemming from the BPM (see also PR-IT-02 BPM with BRMS)



153 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-GV-01-4. Processes authoringProcesses authoring should be possible for all IS Stakeholders, not for IT specialists only

A unified processes authoring function should be available for all IS Stakeholders and managed through a secured authentication. It means that authoring processes should not be dedicated to IT specialists only. According to the company's culture, key business users can be involved in authoring processes directly or prefer to delegate this work to IT teams. In any case, processes should rely on a notation ensuring a full business understanding and formulation of processes (PR-KN-02-1 Processes notation).



154 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-GV-02-1. Processes Asset measurementKey indicators should be defined to follow processes assets over time.

A lot of key indicators could be defined to follow processes assets. You should distinguish key indicators applied to processes executions and those applied to processes definitions. These indicators should be useful to all IS Stakeholders, not only within IT department. Depending on the company's culture, key indicators related to processes assets can enrich an IT scorecard and/or contribute to establish a more global scorecard at the whole scale of the system. Defining key indicators is not easy to achieve as it requires a good level of maturity in the management of systems. However the accuracy of key indicators are less important than their variations over time. It means that you should be interested in trends rather than occasional performances only.Example of key indicators:- number of processes in failure during a period of time,- number of processes related to a business regulation,- number of processes modifications within a period of time,- number of processes executions within a period of time,- processes not used within a period of time,- processes used the greatest number of time during a period,- ratio of core processes compared to processes per business unit within the company,- all measures brought by the IS Rating Tool,- etc.

PR-GV-02 Managing Processes as a real Asset


155 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-GV-02-2. Processes Asset overseeingBeyond key indicators applied to processes assets (see PR-GV-02-1), rules overseeing some key processes executions should be also established.

When processes are managed through a processes repository such as a BPM and/or BRMS, it becomes easier to add alerts to oversee them. These alerts can check the outcomes of processes executions but also can react depending on thresholds applied to key performance indicators (see PR-GV-02-1). Alerts are defined as rules and benefit from the rules management system. For example:- outcomes of a process must be conformed to min/max values constraints. It means that all post-conditions applied to processes could be considered as rules overseeing,- maximum number of a process execution within a period of time,- etc.

To implement these rules as real IS Assets (open to the business, not with an approach of hard-coding), it is recommended to use a BRMS (Business Rules Management System) and/or a CEP (Complex Event Processing) (see also Rules Assessment part of this IS Rating Tool).



156 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-GV-02-3. Processes Asset trackingAll processes executions should be tracked in order to enforce IS traceability

When a processes repository is enforced by a BPM and/or BRMS, then a unified business audit trail should be available directly. This audit trail is used to keep track all processes executions. Query functions allow all IS Stakeholders for seeking and consulting the audit trail, depending on their permissions.



157 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Mastering IT approach to manage processes

158 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Check-list


159 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-IT-01-1. Processes engine applied to existing systemsModeling and implementation procedures should exist to enforce a progressive extracting of existing hard-coded core processes and processes for the benefit of the processes engine (BPM). In doing so, the readability, agility and ability to audit the system can be improved. When combining this approach with an efficient Enterprise Process Architecture (see PR-KN), your company can attain a better Business-IT alignment. However, this restructuring of processes is valuable only if data and rules are also extracted from hard-coded systems. The process value depends on the quality of rules and data that are used. It means that the marks applied to this question takes into account the linking value of the chain composed of MDM+BRMS+BPMNote: extracting micro-process (use case) from hard-coded software entails an in-depth overhauling of existing system, which is targeted with the next question (PR-IT-01-2)

PR-IT-01 Processes engine versus hard-coding


160 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-IT-01-2. Processes engine applied to new development

Every new development and software package customization should benefit from the BPM (core process, process) and BRMS (micro-process) in order to improve transparency, agility and ability to audit systems. A strategic long-term plan should be defined to endorse the BPM and BRMS use at a large scale of the system.

Modeling and implementation procedures should exist to support the BPM (core process, process) and BRMS (micro-process) use rather than an approach of hard-coding only. It means that the number of processes grows when developing and acquiring new systems, including software packages such as ERP. Indeed, customizations of software packages should be put to the BPM and BRMS to ensure a better processes traceability and a better way of managing software packages upgrades.As already stated in PR-IT-01-1, this restructuring of processes is valuable only if data and rules are not implemented with an approach of hard-coding. The process value depends on the quality of rules and data that are used. It means that the marks applied to this question takes into account the linking value of the chain composed of MDM+BRMS+BPM



161 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-IT-01-3. Level of hard-coded processesRegardless of your mark about the BPM and BRMS applied to existing systems and new developments (PR-IT-01-1, 2), you should be able to measure the level of hard-coding of processes within the system.

Reminder: BPM is used to govern and run core process and process. BRMS is more relevant to govern and run micro-process (also called use case). See the processes classification in PR-KN-01.

You should be able to estimate the level of hard-coded processes (core process, process, micro-process) within the system. Without any processes repository (BPM, BRMS), your mark is bad. When using a BPM (core process, process) and BRMS (micro-process), your mark depends on how it is deploy within the system.



162 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-IT-02-1. BPM with BRMS (loose-coupling)Rules used to drive the process flows should be authored and governed through the Business Rules Management System (BRMS), and then should enforce a better auditability and traceability of processes executions.

The value of the BPM is dependent on the value of the BRMS: linking value BPM+BRMS.

From an IT point of view, the integration of the BPM with BRMS should be enforced in a loose-coupling architecture.

Two level of integration should be distinguished:• when using a BPM, the formal representation of the process flow must

be able to launch rules managed by the BRMS in order to compute the flow execution: which step is the right one depending on the current context of execution? It is important to enforce a loose-coupling integration, therefore the BPM shouldn't be aware of rules really executed by the BRMS. It sends a data flow associated with its context execution (version, context) to the BRMS, and receives a result from the BRMS allowing to decide the next step of the process execution. This loose-coupling IT integration allows for modifying the set of rules used to compute the process flow depending on version, context (head-office, subsidiary, country, legislation, etc.) without modifying the formal process flow model carried out within the BPM,

• when using the BRMS directly to carry out a process, this means using the IT integration principles already defined in the Enterprise Rules Architecture. This approach is advised when carrying out micro-processes, in other words the more detailed level of processes (see PR-KN-01-1 Processes classification).

PR-IT-02 Processes execution and test


163 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-IT-02-2. BPM with MDMData used to conduct the processes executions shouldn't be hard-coded in opaque databases. Conversely, it is recommended to use the Master Data Management (MDM) repository to author and govern this data.

The value of the BPM is dependent on the value of the MDM: linking value BPM+MDM.

The process execution shouldn't need to retrieve directly data from the MDM directly. Indeed, this execution interacts with rules (BRMS), and these rules interact with data stemming from the MDM. However, if the need of a direct access to reference and master data is raised, then it must be carry out through the MDM (see Enterprise Data Architecture).Beyond this first mechanism, many reference and master data are used to configure the processes flows, such as the definition of contexts execution and versions. As already stated in the previous question (see PR-IT-01-1), rules executed to compute the flow execution can be different depending on the contexts execution (head-office, subsidiary, country, etc.) and versions. This configuration should be authored and governed with help from the MDM, in order to avoid a hard-coded approach, which is harmful to auditability, traceability and agility of processes



164 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

PR-IT-02-3. Test processes against requirementsWhen using a BPM, it is valuable and cost-effective to establish tests procedures of processes

When using a BPM, processes are both readable by business users and IT runnable directly. It avoids heavy waterfall lifecycle development where processes are testable after having implemented them only. Even though all tests cases are not runnable before some IT integration and development, the ability to test processes when using a BPM is significant improved.Furthermore, it is highly recommended to set up non regression user acceptance tests of processes.Note: regarding micro-processes, when they are implemented through BRMS as recommended, this means using the BRMS procedures tests (see BR-IT-02-3 Test rules against requirements, Data Assessment part)



165 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

Any remarks and suggestions?Do not hesitate to contact the author

[email protected]

And join us in our Linked grouphttp://www.linkedin.com/groups?gid=1879652&trk=hb_side_g

166 / 166



Su

sta

ina

ble

IT

Arc

hit

ec

ture

– I

S R

ati

ng

To

ol

Co

urs

e –

Be

ta V

1

You can use this document for your own needs and publications under the condition to quote the source “Sustainable IT Architecture”

This document is protected by a Creative Commons (see opposite figure)

You can reuse this material

This material is freely available onhttp://www.sustainableitarchitecture.com

creative commons sustainable it architecture is rating tool course 2010, june beta version 1 1 / 166...

Documents