|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DATA
ASSESSMENT - IS Rating Tool
Creative commons by sustainableitarchitecture.com
Version Beta V30 – 2010 - February 24th |
Mark-> |
weight for your rating |
Bad
|
Basic
|
Medium
|
Advanced
|
Optimized
|
|
Guidelines |
|
| Criteria |
Explanation |
|
1 |
3 |
5 |
7 |
10 |
|
Tip: use this
column for vertical scroll |
|
| Mastering Data Knowledge |
For
each question check one choice ONLY |
|
|
|
DT-KN-01
Enterprise Data Architecture
Enterprise Data Architecture should be seen as a subset of Enterprise
Information Architecture (EIA) since it tackles data only, not business
rules. The IS Rating Tool copes with Business Rules in the Rules Assessment
part.
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 (1). Other organizational issues should be tackled
through frameworks and methods such as CobiT, CMMI, etc.
(1) Before using the IS Rating Tool we invite you to find out the
definition of IS Intrinsic Value and its differences with IS Use Value and IS
Business Value (see our website).
|
DT-KN-01-1 Reference
and Master Data
Enterprise Data Architecture is applied to reference and
master data. This is the less difficult data architecture level to achieve as
it can be established without being intrusive to existing data models and
databases.
To regain data knowledge by enforcing a real ROI not limited to
establishing new data models, it is valuable to start with ref/master data
architecture. Indeed, once ref/master data models are available, it is easy
and cost effective to implement them with a MDM to benefit from data
governance features such as authoring, querying, version management of data,
etc. |
1 |
|
|
|
|
|
0,0 |
Reference data
are standard codes and labels such as countries, time interval types,
enumerations. Master data are core business concepts such as Address,
Product, Organization and Structure, Chart of accounts, etc. It means that
reference data are steadier than master data.
If you have unified ref/master data models at the whole scale of the system
then you should check 'optimized'. If these data models are applied to a
subset of ref/master data only with data structures duplications then you should
decrease your mark.
|
|
| |
More
than 50% of ref/master data models are duplicated. Most of the time
ref/master data models are intertwined with transactional data models which
reduce the ability to establish EA applied to ref/master data |
Lack
of metrics but you suppose less than 50% of ref/master data models are
duplicated. Most of the time ref/master data models are intertwined with
transactional data models which reduce the ability to establish EA applied to
ref/master data |
Less
than 50% of ref/master data models are duplicated. Ref/master data models are
well-identified and complement with transactional data models |
Less
than 20% of ref/master data models are duplicated. In other words, 80% of
your ref/master data models are unified and shared. Ref/master data models
are well-identified and complement with transactional data models |
Complete
unified ref/master data modeling with very limited duplications within data
structures. Ref/master data models are well-identified and complement with
transactional data models |
|
Main criteria to
be considered for rating:
level of duplication within ref/master data models, ability to maintain
ref/master data models regardless of transactional data models |
|
DT-KN-01-2 Transactional Data
Enterprise Data Architecture is applied to transactional
data. This 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. Unlike ref/master data, when restructuring
transactional data models it is needed to rebuild existing systems. It means
that Enterprise Data Architecture applied at the level of transactional data
is intrusive to existing systems, which can slow down its deployment. |
1 |
|
|
|
|
|
0,0 |
When unified
transactional data models are used by every project to avoid the blank page
effect, you should check 'optimized'. Conversely, if your modeling procedures
allow duplications of transactional data structures then your mark should be
decreased. Your mark should be 'initial' when unified transactional data
models don't exist.
|
|
| |
More
than 80% of transactional data models are duplicated. There is not initiative
to share transactional data models |
Lack
of metrics but you suppose less than 80% of transactional data models are
duplicated. There is not initiative to share transactional data models |
Less
than 50% of transactional data models are duplicated. A first approach
exists to encourage the sharing of
transactional data models |
Less
than 20% of transactional data models are duplicated. In other words, 80% of
your transactional data models are unified at the whole scale of the system
and shared by every project |
Complete
unified and shared transactional data models with very limited duplications
of data structures at the whole scale of the system |
|
Main criteria to
be considered for rating:
level of duplication within transactional data models, level of sharing
between projects |
|
DT-KN-01-3 Decisional Data
Enterprise Data Architecture is applied to decisional
data. Most 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
|
1 |
|
|
|
|
|
0,0 |
Decisional data
corresponds with information used in the field of Datawarehouses and
Datamarts. These data are both ref/master data and transactional data, most
of the time designed through an Operational Data Store (ODS). The more your
decisional data models are aligned with ref/master and transactional data
models the more your mark should be raised. In other words, when you have a
good command of dependency links between ref, master and transactional data
models (upstream data sources) and decisional data models, then your mark is
high. When these dependency links are not well-managed, the mark should be
decreased.
|
|
| |
No
real reuse of ref/master and transactional data models to establish ODS |
Lack
of metrics but you suppose a partial reuse of ref/master and transactional
data models to establish ODS |
Reuse
of transactional data models only to establish ODS |
Reuse
of ref/master data models only to establish ODS |
Complete
reuse of ref/master and transactional data models to establish ODS |
|
Main criteria to
be considered for rating:
alignment with EA applied to ref/master and transactional data |
|
DT-KN-01-4 Data flow
Enterprise Data Architecture is applied to data flow.
Frequently data structures handled within ETL/EAI/ESB are IT oriented with
huge concerns about the management of integrity rules. The purpose of EA
applied to data flow is to reuse ref/master, transactional and decisional
data models within ETL/EAI/ESB directly. To achieve this goal, usual IT pivot
formats should be replaced by new ones more business oriented. |
1 |
|
|
|
|
|
0,0 |
Data flow
corresponds with data conveyed at the level of the integration layer between
distributed systems both internal and external. These data are both
ref/master, transactional and decisional data. Then, similarly with
decisional data, your score depends on the alignment of data flow models with
ref/master and transactional data models. In other words, data flow should be
designed and maintained by benefiting from EA applied to ref/master and
transactional data. If this is not the case then your mark should be
'initial'. |
|
| |
No
real reuse of ref/master, transactional and decisional data models to
establish data flow models |
Lack
of metrics but you suppose a partial reuse of ref/master, transactional and decisional data models to
establish data flow models |
Reuse
of transactional data models only to establish data flow models |
Reuse
of ref/master data models only to establish data flow models |
Complete
reuse of ref/master, transactional and
decisional data models. It means that the pivot format used at the level of
systems integrations stems from transactional, ref/master and decisional data
models |
|
Main criteria to
be considered for rating:
alignment with EA applied to ref/master and transactional data. |
|
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 be
existed 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. |
DT-KN-01-5 Unified
Data Architecture
All 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 |
1 |
|
|
|
|
|
0,0 |
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 (mdmalliancegroup.com) |
|
| |
Lack
of shared data modeling procedures. Every project redefines its own data
modeling approach depending on its requirements |
First
level of shared data modeling procedures but without reusing business
concepts at the whole scale of the system. For example, business objects are
designed with shared procedures but their data structures are not reused
within projects |
Existing
of shared data modeling procedures with partial reuse of business concepts
such as business objects |
Complete
shared data modeling procedures enforcing key business concepts and their
reuse by every project except for systems developed by third parties |
Complete
shared data modeling procedures enforcing key business concepts and their
reuse by every project including systems developed by third parties |
|
Main criteria to be considered
when rating:
data modeling procedures enforcing key business concepts at the whole scale
of the system |
|
DT-KN-02 Basic Data Modeling
Business Dictionary and data modeling procedures should
be enforced to succeed in the field of the Basic Data Modeling.
If the Basic Data Modeling is not enforced sufficiently then it is difficult to achieve goals related to the Semantic
Data Modeling (DT-KN-03). It means that your mark about the Basic Data
Modeling should be 'medium' at least
before starting the Semantic Data Modeling. |
DT-KN-02-1
Business Dictionary
One or several business dictionaries are used to gather
key business concepts with definitions of terms, taxonomy, synonyms,
etc.
|
1 |
|
|
|
|
|
0,0 |
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'. |
|
| |
Lack
of shared business dictionary |
First
level of business dictionary but not shared, not really usable by all IS
Stakeholders and with potential duplications of terms and definitions |
Shared
business dictionary not applied at the whole scale of the system, partially
usable by all IS Stake- holders and
without being connected to your data models |
Shared
business dictionary applied at the whole scale of the system, fully usable by
all IS stake-holders but without being connected to your data models |
Shared
business dictionary applied at the whole scale of the system, fully usable by
all IS stake-holders and connected to your data models |
|
Main criteria to
be considered for rating:
shared, comprehensiveness, connected with data models. |
|
DT-KN-02-2 Business point of view
Business data models are available and maintained
regardless of physical implementations and databases schemas |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
Lack
of business data models because of an IT approach when modeling information.
Moreover, business data are described through an unstructured representation
mainly, without formal notation such as UML or other DSL |
First
attempt of business data modeling. Data models include some relationships
between business objects but with a lack of commitment to achieve this goal.
A formal notation is partially used with unstructured description |
Business
data models are partially described because relationships between business
objects are not well-established. Even though it exists a real commitment to
achieve this goal, Business Data models still remain readable by IT
specialists mainly |
Business
data models are fully described, including relationships between business
objects but still remain readable by IT
specialists mainly. Even though it exists a real commitment to achieve
this goal, Business data models are not seen as a real IS Asset |
Business
data models are fully described in meaningful terms for all IS Stake-holders,
describing relationships between business objects with help from a formal
notation such as UML or other DSL. Business data models become a real IS
Asset |
|
Main criteria to
be considered for rating:
shared, meaningful for IS stakeholders, comprehensiveness, relationships
between business objects, formal representation. |
|
DT-KN-02-3 Logical point of view
Logical data models are derived from business data
models. They establish the logical point of view of the data architecture |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
Lack
of real logical data models because every project uses its own representation
with possible confusions with physical databases schemas |
Logical
data models are established but without real derivation rules from business
data models. Therefore the business-logical data models alignment is rough |
Logical
data models are established with help from derivation rules defined by every
project, not applied at the whole scale of the system |
Derivation
rules are well established to drive translation of business data models to
logical data models. They are applied at the whole scale of the system but
without shared and formal logical naming rules |
Derivation
rules are well established to drive the translation of business data models
to logical data models. These rules are associated with logical naming rules
enforced at the whole scale of the system |
|
Main criteria to
be considered for rating:
Derivation rules from business data models to logical data models, formal
logical naming rules |
|
DT-KN-03 Semantic Data Modeling
The richness of data is revealed through their business
lifecycles, their relationships and their business rules. Business lifecycles
describe core business behaviours of data, not organizational processes such
as data approval workflows. These processes are assessed within the Process
Assessment part of the IS Rating Tool.
The Basic Data Modeling (DT-KN-02) doesn't tackle these issues as it
remains focus on static modeling only.
|
DT-KN-03-1
Business Objects' lifecycles
The real semantic of data is revealed through business
objects's lifecycles. Indeed, modeling behaviours 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. |
1 |
|
|
|
|
|
0,0 |
Data modeling
must encompass Business Objects' lifecycles in a formal representation with
help from state machines, decision tables or other patterns. For example, the
business object 'Product' holds several states defining its lifecycle and
declared as an enumeration data: to be negotiated, negotiated, deprecated,
updated, etc. These states are used to enforce data integrity constraints.
For example: updating attributes of the product depends on its current state
value; changing the state of the product depends on its current state, etc. |
|
| |
Business
objects' lifecycles are not established |
Business
objects' lifecycles are established within some projects only |
Business
objects' lifecycles are established systematically but without shared and
formal models. Sometimes it is represented as informal specification only |
Business
objects' lifecycles are modeled with help from a shared and formal
representation but not managed as master data. In other words, business
states are not managed as enumeration data within the MDM |
Business
objects's lifecycles are modeled with help from a shared and formal
representation and managed as master data. These master data are
automatically used when enforcing integrity constraints? In other words,
business states are managed as enumeration data within the MDM |
|
Main criteria to
be considered for rating:
shared and formal design, managed as master data.
|
|
DT-KN-03-2 Relationships between
Business Objects
The 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 |
1 |
|
|
|
|
|
0,0 |
Cardinalities
between business objects are managed as master data. In other words,
minOccurs and maxOccurs defining links between data are not frozen when
establishing data models. Therefore, minOccurs and maxOccurs can be fed to
adapt data models depending on requirements and contexts of use. For example,
a Product could be associated to three Factories when it is sold by the
headquarters whereas this relationship becomes one Factory only when it is
sold by a subsidiary. Here, the headquarters and the subsidiary are two
different uses contexts of the same data models.
Then rather than freeze cardinalities within data models or complement them
with a hard-coding of integrity rules, a more agile approach is established
by viewing and managing data cardinality as master data. This is an effective
way to parameterize data models and to enforce a real semantic data modeling. |
|
| |
Relationships
between business objects are frozen
when establishing data models. There are no modeling procedures to set up
integrity rules required to check data cardinality, which means hard-coded
developments |
Relationships
between business objects are frozen when establishing data models. Modeling
procedures exist to set up integrity rules required to check cardinalities |
Relationships
between business objects are not frozen when establishing data models. Every
project uses its own approach to implement integrity rules required to check
cardinalities |
Relationships
between business objects are not frozen when establishing data models.
However, cardinalities are not managed as master data. This is parameters
only used by business rules that complement with data models. Every project
uses this shared approach to implement integrity rules |
Relationships
between business objects are managed as master data. Changing cardinalities
is established by parameterization
within the Master Data Management. In other words, MDM is used to check
cardinalities between business objects. Every project uses this approach to
implement integrity rules |
|
Main criteria to
be considered for rating:
cardinalities frozen or not, shared implementation of integrity rules,
cardinalities managed as master data
|
|
DT-KN-03-3 Business Rules applied to data
When 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.
|
1 |
FALSE |
|
|
|
|
0,0 |
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. |
|
| |
Business
rules applied to data are not managed through a rules repository. Only
informal descriptions are enforced without a real portfolio of rules |
Business
rules applied to data are declared through a portfolio of rules but their
descriptions still remain informal |
Business
rules applied to data are declared through a portfolio of rules and their
descriptions rely on a formal grammar even though neither a business
requirements tool nor a BRMS is used |
Business
rules applied to data are designed with help from a formal language and
declared through a portfolio of rules, but it is not a BRMS. This is a tool
managing business requirements. Therefore version management, rules authoring
by business users and ability to execute rules are very limited |
Business
rules applied to data are designed with help from a BRMS, relying on a formal
description readable by all IS Stakeholders. This rules repository is
connected to data models and allows for distinguishing rules depending on
business objects' states. When data models are shared at the whole scale of
the system, then business rules are shared at this scale also |
|
Main criteria to
be considered for rating:
portfolio of rules, Business rules repository, ability to execute business
rules, connection between data models and rules
Note: the portfolio provides rules descriptions without any added-value
feature to manage rules over time: version, permission, query, test,
etc.
|
|
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(1)
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.
(1) Before using the IS Rating Tool we invite you
to find out the definition of IS Intrinsic Value and its differences with IS
Use Value and IS Business Value (see our website). |
DT-KN-04-1
Funding
A budget is
established to support the Enterprise
Data Architecture |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
No real
budget dedicated to Enterprise Data Architecture |
Partial
budgets are identified depending on projects requirements related to
ref/master, transactional or decisional data |
A
complete budget is established to support Enterprise Data Architecture at the
level of ref/master data but applied to a subset of the system only |
A
complete budget is established to support Enterprise Data Architecture at the
level of ref/master data applied at the whole scale of the system |
A complete budget is established to support
Enterprise Data Architecture with key indicators to measure results. It
covers ref/master, transactional and decisional data at the whole scale of
the system |
|
Main criteria to
be considered for rating:
complete budget, applied to ref/master data, applied to the whole scale of
the system |
|
DT-KN-04-2 Replacement value
Ability of your organization to (re)design data models
from scratch (blank page) |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
The
effort to redesign is too high. It would be impossible to do this work |
It
should be possible to do this work within a subset of the system, less than
30%, but we cannot estimate it. Doing this work at a large scale of the
system is impossible |
We
are able to estimate the work of redesign but applied to less than 50% of the
system |
We
are able to estimate the work of redesign applied to a large scale of the
system, more than 50% |
We
are able to estimate the work of redesign applied to the whole scale of the
system, at least more than 80% of the scope |
|
Main criteria to
be considered for rating:
scope of possible redesign, ability to estimate the work
|
|
Intermediary
mark
Mastering Data Knowledge |
0 |
out of |
130 |
0,0% |
|
|
|
Mastering Data Governance Features
Reminder: organizational issues are out of the IS Rating
Tool scope |
For
each question check one choice ONLY |
|
|
|
DT-GV-01 Reference and
Master data
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. |
DT-GV-01-1 Unified
ref/master data governance
Ref/master data benefit from unified and shared
governance functions used by all IS Stakeholders, not only by IT specialists |
1 |
|
|
|
|
|
0,0 |
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') |
|
| |
Data
governance functions are not unified. Every system and/or type of data used
its own data governance functions with discrepancies from other systems and
types of data |
Lack
of metrics but you suppose that less
than 50% of ref/master data share some governance functions without using MDM |
About
50% of main ref/master data share
governance functions brought by a Model-driven MDM applied to a subset
of the system. The rest of ref/master data is managed through heterogeneous
functions including spreadsheets |
More
than 50% of ref/master data share governance functions brought by a
Model-driven MDM applied at a subset of the system. The rest of ref/master
data is managed through heterogeneous functions including spreadsheets |
Almost
all ref/master data share governance functions brought by a Model-driven MDM
applied at the whole scale of the system. Use of spreadsheets to manage
ref/master data is very limited |
|
Main criteria to
be considered for rating:
shared and unified data governance functions, use of spreadsheets,
Model-driven MDM
|
|
DT-GV-01-2 Ref/master data version management
Amongst data governance functions, the version
management is a significant feature requiring a specific assessment |
1 |
FALSE |
|
|
|
|
0,0 |
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.
This data version management is used to enforce a lot of
key data governance processes such as: data staging (deploying data within IT
environments like development, integration, UAT, production, etc.), data
approval (temporary version of data awaiting for validation by processes),
data archiving when legal compliance is required, data matching (comparing
records and merging), data publishing ( branches/versions to ESB and the
opposite way), Data-Rules alignment (merging a version of data with a version
of rules declared as ref data), etc.
|
|
| |
No
unified and full data version. Every project establishes its own mechanism,
including basic copies of data without real governance |
Version
management is enforced by adding dates of validity to every data element. Therefore it is
difficult or impossible to manage versions spanning a scope of several data
elements. Most of the time, this version management is used by IT specialists
only and required a strong IT knowledge |
Version
management is enforced at the scope of every business object only, which
means without managing relationships between business objects and without
using the branch concept. To go beyond this first level of version
management, IT specialists must implement hard-coded software |
Unified
and full data version management is available but without the branch concept.
Therefore it is difficult or impossible to make live together several
versions of the same data scope. This version management is usable by all IS
Stakeholders |
Unified
and full data vesion management relying on version and branch concepts,
usable by all IS Stakeholders. All types of ref/master data benefit from this
version management with help from a Model-driven MDM applied to the whole
scale of the system. Therefore all data governance processes benefit from the
ability to compare and merge versions located to different branches |
|
Main criteria to
be considered for rating:
version, branch, compare and merge of version, usable by all IS
Stakeholders
|
|
DT-GV-01-3 Active data quality
Ref/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. |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
No
real data quality process. Every project established its own approach |
Some
data quality tools are used to clean data within existing databases directly.
There is not a unified ref/master data repository |
Some
data quality tools are used and connected to the ref/master data repository
but without governance features
allowing a real active data governance, such as versions and branches
management |
Full
active data quality process applied to a subset of the system only. It means
that the MDM repository is used as the foundation to achieve data quality.
This MDM brought all data governance features needed, including versions and
branches management |
Full
active data quality process applied to the whole scale of the system. It
means that the MDM repository is used as the foundation to achieve data
quality. This MDM brought all data governance features needed, including
versions and branches management |
|
Main criteria to
be considered for rating:
use of data governance to streamline data quality processes
|
|
| DT-GV-02 Transactional data |
DT-GV-02-1 Data
governance applied to applications oriented data
Data governance functions established for ref/master data
can be reused to enforce an unified management of transactional data within
applications oriented data. |
1 |
|
|
|
|
|
0,0 |
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.
|
|
| |
Lack
of unified approach to deliver applications oriented data. Every project
establishes its own solution from spreadsheets to light developments using
RAD tools (Rapid Application Development). Therefore, data governance
features still remains weak |
Only
a few applications oriented data are established with help from the data
governance functions brought by the Model-driven MDM |
Less
than 50% of applications oriented data are established with help from the
data governance functions brought by the Model-driven MDM |
More
than 50% of applications oriented data are established with help from the
data governance functions brought by the Model-driven MDM |
Most
of applications oriented data are established with help from the data
governance functions brought by the Model-driven MDM. Therefore, the number
of spreadsheets and light applications decrease for the benefit of a more
secure and sustainable approach |
|
Main criteria to
be considered for rating:
number of oriented data applications, use of Model-driven MDM
|
|
| DT-GV-03 Decisional data |
DT-GV-03-1
Data governance applied to datawarehouses
Datawarehouses 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. |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
Lack
of a real data governance at the level of dataware-houses. Every project
established its own approach |
Only
a few dataware-houses reuse data governance brought by the Model-driven MDM |
Less
than 50% of dataware-houses reuse data governance brought by the Model-driven
MDM |
More
than 50% of dataware-houses reuse data governance brought by the Model-driven
MDM |
All
datawarehouses reuse data governance features brought by the Model-driven MDM |
|
Main criteria to
be considered for rating:
reuse of data governance brought by the Model-driven MDM |
|
| DT-GV-04 Data Flow |
DT-GV-04-1
Data governance applied to
data flow
To give to business users an autonomy in their daily data
flow management, data governance functions must be applied to data flow as
well. |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
Data
flow management is enforced by an IT
approach only at the level of integration layer. Integrity rules applied to
data flow are hard-coded and the audit trail is meaningful for IT specialists
only |
Data
flow management is enforced by a pivot format established at the level of the
integration layer. There are not data governance functions and the audit
trail still remains IT and usable by IT specialists only |
Only
B2B data flow management is enforced by using data governance features
brought by the Model-driven MDM. It means that internal data flow don't
benefit from data governance |
More
than 50% of data flow management is enforced by using data governance
features brought by the Model-driven MDM. This approach is applied to both
external (B2B) and internal data flow |
More
than 80% of data flow management is fully enforced by using data governance
features brought by the Model-driven MDM. All integrity rules applied to data
flow are well-established and the audit trail is easy-to-use by all IS
Stakeholders. This means that the integration layer (ETL, EAI, ESB) is
connected with the MDM repository |
|
Main criteria to
be considered for rating:
reuse of data governance brought by the Model-driven MDM
|
|
| DT-GV-05 Security information |
DT-GV-05-1
Data governance applied to
security policies
Every information system needs a lot of data defining
security policies. The management of these data should also benefit from data
governance functions |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
Lack
of unified and shared solution to manage security policies. Every project
establishes its own implementation |
Many
solutions are used to enforce the security policies management. Then there is
a lack of unified and shared data governance features. A lot of discrepancies
exist between these different solutions |
Only
some strategic security policies are managed through the Model-driven MDM and
then benefit from its data governance features |
More
than 50% of security policies is managed through the Model-driven MDM and
then benefit from its data governance features |
More
than 80% of security policies is viewed as meta-data and fully managed
through the Model-driven MDM. It means that these data benefit from all data
governance features. This approach enforces a more secure and sustainable way
to manage security information at the whole scale of the system |
|
Main criteria to
be considered for rating:
reuse of data governance brought by the Model-driven MDM
|
|
DT-GV-06 Managing Data as a real Asset
Data is a real IS Asset changing over time both in terms
of data models and data values. It is significant valuable to measure trends
rather than an occasional performances only, which means that key indicators
should be defined and measured regularly.
Moreover, once ref/master data are well-managed through a unified data
governance approach, it is valuable to set up business rules overseeing data
values. This approach allows to throw alerts in real time when needed.
At last, as a real IS Asset, all ref/master data access should be tracked
through a unified business audit trail.
|
DT-GV-06-1
Data Asset measurement
Key indicators should be defined to follow data assets
over time |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
Lack
of key indicators to follow data
assets. Therefore an informal knowledge of data assets is enforced only and
still remain in hands of some key people within the system |
Some
key indicators about data assets are established but they don't rely on a
structured approach such as the IS Rating Tool. Therefore, these key
indicators are used mainly within IT department, without a real involvement
of all IS Stakeholders and without possible bench-learning with other
organizations |
A
first level of key indicators about data assets is established and rely on a
structured approach such as the IS Rating Tool. As these indicators are not
fully detailed, they are used within IT department mainly |
A
rich set of key indicators about data assets is established and rely on a
structured approach such as the IS Rating Tool but they still remain IT
oriented only. This set of key indicators is updated over time and allows IT
department for managing its own risks. This is a good foundation to deploy a
further extended approach encompasses business key indicators |
A
rich set of key indicators about data assets are followed closely by
different IS Stakeholders, not within IT department only. These key
indicators are updated over time to compute trends. They rely on a structured
approach such as the IS Rating Tool. Correlations between key indicators
allow for making some forecasts and then contribute to risks management at
the whole scale of the system |
|
Main criteria to
be considered for rating:
key indicators relying on a structured approach, ability to provide key
indicators meaningful outside the IT department
|
|
DT-GV-06-2 Data Asset overseeing
Beyond key indicators applied to Data Assets (see
DT-GV-05-1), Business Rules used to oversee some key data values should be
established
|
1 |
|
|
|
|
|
0,0 |
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). |
|
| |
Lack
of unified approach to set up business rules overseeing ref/master data and
data flow. Every project establishes its own solution depending on
requirements |
Some
business rules are defined to oversee ref/master data and data flow but they
are hard-coded within opaque software, not meaningful for all IS
Stake-holders. It means that BRMS and CEP are not used |
Some
rules are defined to oversee ref/master data and data flow through a BRMS
and/or a CEP. However, as these rules still remain limited, IS Stake-holders
are not involved |
A
rich set of business rules are established over the MDM repository to oversee
ref/master data and data flow in real time, but limited to less than 50% of
the system. These rules are authored and executed through a BRMS and/or a CEP
to avoid the approach of hard-coding |
A
rich set of business rules are established over the MDM repository to oversee
ref/master data and data flow in real time, at a large scale of the system.
These rules are authored and executed through a BRMS and/or a CEP to avoid
the approach of hard-coding. IS Stake-holders are fully involved in managing
these rules |
|
Main criteria to
be considered for rating:
using BRMS/CEP to establish rules overseeing data values, involvement of IS
Stakeholders
|
|
DT-GV-06-3 Data Asset tracking
All data access should be tracked in order to enforce IS
traceability. |
1 |
|
|
|
|
|
0,0 |
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. |
|
| |
Lack
of unified approach to ensure traceability of data. Every project establishes
its own audit trail mechanism |
A
unified solution to ensure an audit trail of ref/master data is established
but without taking benefit from the Model-driven MDM. Therefore, governance
features brought by the MDM are not available. This solution still remains IT
and business IS Stake-holders are not really involved |
Audit
trail of data is established with help from the Model-driven MDM at a subset
of the system, less than 50% only. It copes with ref/master data only which
means that data flow don't benefit
from the audit trail brought by the Model-driven MDM |
Audit
trail of data is established with help from the Model-driven MDM, at a subset of the system, less than 50% only.
It copes with both ref/master data and data flow |
Audit
trail of data is established with help from the Model-driven MDM, at the
whole scale of the system, including both ref/master data and data flows. It
means that all IS Stakeholders are able to use the audit trail, depending on
their permissions |
|
Main criteria to
be considered for rating:
using Model-driven MDM to establish a unified audit trail of data,
involvement of IS Stakeholders
|
|
| |
Intermediary mark
Mastering Data Governance |
0 |
out of |
100 |
0,0% |
|
|
|
| Mastering IT Approach To Manage Data |
For
each question check one choice ONLY |
|
|
|
DT-IT-01 Reference and
Master Data repository |
DT-IT-01-1
Model-driven MDM
To 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)(1) 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.
Note: data governance features brought by the MDM are assessed within
''mastering data governance'' part of the IS Rating Tool. |
1 |
|
|
|
|
|
0,0 |
Amongst Model-driven IT
capabilities, two features should be available in priority:
Many to many relationships managed as objects
Many to many relationships between business
objects shouldn't rely on join tables but should benefit from the object
oriented approach. It means that multi-valuated attribute is used to set up
lists of foreign keys joining business objects each other. Join tables still
remain an IT concept that business IS Stakeholders haven't to understand. It
means that data models using join tables are not semantic because they are
meaningful to IT specialists only. Furthermore, when generating user
interface to manage information through data models, join tables cannot be
kept. Therefore an heavy IT process development is required to build user
interface hiding these join tables.
Conversely, when using a Model-driven MDM taking benefit from the object
oriented approach, then generating user interface automatically is easier and
cost-effective.
Cardinality of relationships managed as master
data
Cardinality (minOccurs, maxOccurs) shouldn't be
frozen within data models. They should be managed as master data and then
being set up depending on contexts where data models are used. For example, a
maxOccurs cardinality between Product and Factory could be initialized to
''one only'' for the Headquarters context and ''one to many'' for a
Subsidiary context. Rather than using an approach of hard-coding rules to
enforce integrity over minOccurs and maxOccurs, it is more valuable to manage
them as master data directly within the MDM repository. The more the contexts
of use are numerous and diversified the more the integrity rules over
cardinalities are extended and should benefit from a management by the MDM. |
|
| |
Lack
of model-driven MDM. Only vertical MDM are established relying on a pure
relational approach. It means that an heavy IT development is required when
modifying data models since no real automatic generation of user interface
and CRUD services is possible |
Use
of a partial model-driven MDM as it relies on a weak object oriented
approach. For example, data cardinalities are not managed as master data.
They are either frozen within models or they required additional hard-coded
rules |
Full
Model-driven MDM applied at a first scope of the system, less than 50%.
Applied to this scope, It brings a complete model-driven architecture to
generate user interface and CRUD services automatically. It means that 'what
you model is what you get' |
Full
Model-driven MDM applied at a subset of the system, at least 50%. Applied to
this scope, It brings a complete model-driven architecture to generate user
interface and CRUD services automatically. It means that 'what you model is
what you get' |
Full
Model-driven MDM applied at the whole scale of the system. It brings a
complete model-driven architecture to generate user interface and CRUD
services automatically. It means that 'what you model is what you get' |
|
Main criteria to
be considered for rating:
object oriented approach, model-driven architecture
|
|
DT-IT-02 Rules integration
|
DT-IT-02-1 MDM with
rules repository (BRMS)
|
1 |
|
|
|
|
|
0,0 |
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.
|
|
| |
Rules
applied to ref/master data are hard-coded. When the number of rules increases
it brings troubles in term of development and maintenance. The traceability
and auditability of the system is weak due to a lack of business rules
management |
A
subset of rules applied to ref/master data relies on parameters allowing
their adaptations depending on contexts of execution. Even though BRMS is not
used, a first level of agility is enforced through this parameterization
mechanism. Every rule is listed to the MDM repository so as to keep their
knowledge |
The
Model-driven MDM is connected with a
BRMS in a loose coupling architecture. Only a few rules benefit from this
integration, less than 20%. Adding new rules to the BRMS doesn't impact on
the MDM. As the BRMS brings governance features applied to rules it
complements with the MDM. The system is really traceable and auditable |
The
Model-driven MDM is connected with a BRMS in a loose coupling architecture.
This integration is achieved to less than 50% of rules. Adding new rules to
the BRMS doesn't impact on the MDM. As the BRMS brings governance features
applied to rules it complements with the MDM. The system is really traceable
and auditable |
The
Model-driven MDM is fully connected with a BRMS in a loose coupling
architecture. This architecture is achieved to more than 50% of rules. Adding
new rules to the BRMS doesn't impact on the MDM. As the BRMS brings
governance features applied to rules it complements with the MDM. The whole
system is really traceable and auditable |
|
Main criteria to
be considered for rating:
loose coupling, scope of rules managed through BRMS
|
|
| DT-IT-02-2 MDM with events management (CEP) |
1 |
FALSE |
|
|
|
|
0,0 |
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 behaviours. 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. |
|
| |
Integration
between MDM and CEP is not possible because the data repository is a black
box and/or don't publish in real-time its data logs. Therefore, overseeing
data in real time is a big trouble |
Some
rules are hard-coded to oversee data in real time. It means that implementing
a new rule requires an heavy hard-coding to catch events. Over time this
approach brings maintenance troubles and slows down the ability to oversee
data in a real-time approach |
na |
na |
Integration
between MDM and CEP is fully established by using data logs published in
real-time by the data repository. Overseeing ref/master data in real time is
enforced at the whole scale of the system |
|
Main criteria to
be considered for rating:
data logs used to integrate CEP |
|
| DT-IT-03 IT Data integration |
DT-IT-03-1
MDM integration with the rest
of the system
|
1 |
|
|
|
|
|
0,0 |
To 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). |
|
| |
Lack
of unified architecture to ensure the MDM integration with the rest of the
system. Every project establishes its own solution depending on its
requirements. Business objects' lifecycles are not really used to streamline
data integration |
Unified
architecture is defined to streamline the MDM integration with the rest of
the system, but it doesn't take benefit from
business objects's lifecycles. Therefore, it remains a partial
streamlining |
Even
thought an unified integration architecture is defined and takes benefit from
business objects's lifecycles, its implementation remains partial. Indeed,
Business objects's lifecycles are not always designed. Every project makes
the choice to design business objects' states or not |
Business
objects' lifecycles are used to conduct data integration when it makes sense.
This is an unified architecture pattern enforced at a subset of the
integration system only, at least 50%. It means that the MDM repository
encompasses business objects' states |
Business
objects' lifecycles are fully used to conduct data integration when it makes
sens. This is a unified architecture pattern enforced at the whole scale of
the integration system. It means that the MDM repository encompasses business
objects' states |
|
Main criteria to
be considered for rating:
use of business objects' lifecycles
|
|
DT-IT-03-2 Data mapping
|
1 |
|
|
|
|
|
0,0 |
To 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. |
|
| |
Lack
of unified architecture to tackle data mappings. Every project establishes
its own solution depending on its requirements |
A
pivot format is used but it still remains IT oriented. Therefore a lot of
hard-coded software is required to implement data mappings. This architecture is not cost-effective and
raises troubles when updating existing data mappings |
A
rich pivot format is established but without a global semantic data modeling
approach. Therefore, this pivot format is not generic enough to be
sustainable. Over time, troubles to maintain this common and rich pivot
format appear because of lack of enterprise data architecture |
Semantic
data models are fully reused as the pivot format to conduct data mappings.
This architecture is enforced to a subset of the integration data, less than
50%. A semantic data integration tool
is used to enforce this architecture and then streamline data integration in
a cost-effective way |
Semantic
data models are fully reused as the pivot format to conduct data mapping.
This architecture is enforced at the whole scale of the system. A semantic
data integration tool is used to enforce this architecture and then
streamline data integration in a cost-effective way |
|
Main
criteria to be considered for rating:
reuse of semantic data models as rich pivot formats
|
|
| |
Intermediary mark
Mastering IT approach to manage Data |
0 |
out of |
50 |
0,0% |
|
|
|
|
|
|
|
|
|
Performance Level Percentage about your IS ability to
manage
Data as a real asset |
0,0% |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|