Pondering on Data and CDO (Chief Data Officer)

A successful approach to organizing a business is to avoid overhead, i.e. to decentralize responsibilities as much as possible and to centralize as little as necessary. Having this in mind, I closed an earlier post "Close encounters with the 3rd resource" postulating that business departments take their ownership and responsibility to govern Data as assets.

Since governing the other two main resources, Finance and Human Resources, as assets were established early on and practices are not widely disputed, it should be deemed worthwhile to explore how Finance and Human Resources are fostered in a balanced approach between centralization and decentralization:

In medium or large enterprises, Finance and Human Resources are typically represented by central organizational units, headed by the CFO (Chief Financial Officer) and the CHRO (Chief Human Resources Officer), respectively, each of them directly reporting to the CEO. In their respective realm, Finance and Human Resources a.o.

• Develop corporate target scenarios and related strategies
• Ensure that the organization follows legal and regulatory obligations
• Advise business departments regarding strategic and legal aspects
• Perform tasks that are not assigned to the department level, but to the corporate level (e.g. declare taxes, report to regulatory authorities, compose the balance sheet, negotiate with the workers' union)
• Provide standard templates / procedures that operational departments can / must apply (e.g. standardize expense reports)

Any item of the above list is abstractly applicable to the resource Data, therefore, I suggest that medium and large enterprises implement a central unit headed by a CDO (Chief Data Officer) who directly reports to the CEO. 

More precisely, the Chief Data Office(r)'s tasks ought to include e.g.

• Develop a High-Level Enterprise Information Management Map (also see my post here)
• Ensure that the organization follows worldwide-applicable regulations such as the GDPR (General Data Protection Regulation) and industry-specific regulations such as HIPAA, Solvency II, Basel III etc.
• Derive measures that respond to international, national and corporate requirements of Data Governance and advise business areas accordingly
• Develop a detailed data model for the intersection of business areas (Master Data)
• Conceive standard interfaces for Master Data Management and related hubs
• Build a corporate Business Data Dictionary

Taking this approach, the enterprise will fulfill a crucial prerequisite to govern Data as an asset of the organization. 

Close Encounters With the 3rd Resource

No business can operate without people, at least it requires the person that manages and represents the business, the CEO. S/he will need funds (Finance) to run the organization, hire additional people (Human Resources), rent a place for the business etc. The organization will develop products/services, acquire clients and look for suppliers. The business will collect and record Data, i.e. pieces of information about its products / services, clients, addresses, orders etc.. The recording of Data contributes to the organization's long-term memory, to information that can be shared within the organization to function effectively and efficiently, which by definition makes Data a resource.

In fact, Human Resources, Finance and Data are the three essential business resources that any organization has always been built on, independent of its size or industry, regardless whether it operates locally or globally or whether its products / services are tangible or not. Moreover, in various business branches (e.g. banks, insurances, public administration) these are the only resources. (Herein, the term Finance is used to summarize all items which traditionally appear on balance sheets as assets or liabilities and thus describe the financial status of an organization, including e.g. cash, loans, real estate, machinery.)

The ultimate target of a business is to turn resources into assets which implies that resources are governed to increase revenue, to lower costs and to minimize risks, all in alignment with the organization's mission and goals as well as with the legal and regulatory requirements for the respective industry.

As the CEO is responsible to the Board to accomplish the business targets, s/he may want to especially ensure that managers at the senior level (VPs) contribute their share to the set out goals and advise their subordinate management levels to govern the resources accordingly. However, to be successful, such top-down leadership also requires that the hierarchical structure remains horizontally cohesive, i.e. departments on the senior management level do not develop as independent organizational, cultural, informational or technical resource silos.

While governing Finance and Human Resources as assets had been established early on, senior-level driven cultivation of business data resources has been neglected for decades. With the advent of information technology, Data were considered to be a technical matter, and business departments passed the responsibility for Data on to the IT department. As a result, business departments became alienated from the Data that they created themselves.

It's time for business departments to not only closely encounter with Data, but take ownership and responsibility to govern Data as assets... 

Stay tuned for my next post.

How to Define the Target for Enterprise Information Management

In my recent post "The Organizational Challenge of Enterprise Information Management", I recommended to create a high-level conceptual data model as a target map for Enterprise Information Management (EIM), with Master Data Management (MDM) and Data Governance being core strategies to transform the organization from legacy structure to a data-driven business.

Below I have included a (not necessarily exhaustive) example of a high-level EIM map for an insurance company. 

Click to enlarge

(The blue rectangles are Master Entities while the grey rectangles represent the major transactional entities.)

The decisive advantage of such an EIM map as a strategic orientation is: This target is not moving! As long as the business subject does not change (in this example: as long as the business does not add or drop any insured risk), this model does not need to be altered. It represents a sound structure that was valid 20 years ago (even if the term Master Data Management was not coined at that time), it is applicable today, and I dare to predict that it will still be in 20 years from now.

If applications are aligned to this model, they can answer business questions that a disparate system cannot (or cannot sufficiently), e.g. such as:

• Which policies are owned by a certain party? (Single view of the customer)
• Who are the most profitable / most risky customers? (Risk management)
• Are there same groups of people that are - with changing roles - repeatedly involved in car accidents? (Fraud detection)

Being implementation-independent, a high-level EIM map will help any business in any industry to develop a long-term strategy to move from a siloed data / application architecture to integrated Enterprise Information Management and to provide answers to any organization's respective business questions.

The Organizational Challenge of Enterprise Information Management

Medium and large enterprises as well as public administrations are constructed hierarchically, and that is for obvious reasons the best, if not the only principle to successfully conduct any endeavor that involves a certain number of people.

At some point in history, when the benefits of information technology were discovered, enterprises innocently imposed the same paradigm on their applications and also organized them by department. As a consequence, multiple information objects have been reinvented in several departments, and isolated data silos have been created, causing the known problems of conflicting definitions, redundancy and inconsistency that hinder to obtain complete customer views, to create real-time analytics as well as to swiftly respond to external legal and/or regulatory requirements. 

However, business information does not live in hierarchies but is represented by a network structure: the (conceptual) data model with master entities as their central objects.

Click to enlarge

Such a conceptual model on its highest levels serves as a target map for Enterprise Information Management (EIM) with Master Data Management (MDM) and Data Governance being core strategies to transform the organization from legacy structure to a data-driven business.

Since MDM and Data Governance demand harmonization throughout multiple departments, many organizations have set up committees to solve the related issues.

However, work for and participation in committees will always have to compete with departmental day-to-day tasks and therefore are in permanent risk of being treated as second priority. Also, EIM requires "central" tasks which do not have any "natural" representation in existing business units and therefore tend to end up in "IT" where they do not belong.

As a viable alternative, I suggest to replace the committee(s) by an additional permanent business unit that acts as the CEO's "right arm" to execute all central as well as coordinative tasks of EIM. For illustration purpose, I will here just name a few:

• Develop and maintain the conceptual model that serves as the target for EIM
• Define shared business entities e.g. Party (which then assumes its different roles such as Customer, Supplier, Employee in the operational business departments)
• Develop strategies to accomplish legal and/or regulatory compliance 

In a future post, I will elaborate further on the role of the EIM unit, on necessary peer roles in the operational business departments and comment on frequently suggested responsibilities such as Chief Data Officer (CDO) and Data Stewards.

Business Value of Master Data Management

In recent posts Aaron Zornes (@azornes: MDM and Next-Generation Data Sources) and Henrik Liliendahl Sørensen (@hlsdk: Another Facet of MDM: Master Relationship Management) shared their vision about the future of Master Data Management as a discipline that does not only mitigate architectural flaws of the past, but will create business value for the years to come. They identified management of relationships as a next-generation focus, and Henrik even suggested the terms Master Entity Management and Master Relationship Management.

Indeed, this is another reminder that successful Master Data Management is based on Master Data Modeling which actually distinguishes Master Entities and Master Relationships. Moreover, here is the historic opportunity to underscore the business value of (Master) Data Modeling.

Party (as described in my comment post What domains are people managing with MDM?) refers to any natural person or legal entity that is relevant for a business. High-quality Party data are necessary ingredients, but to generate business value, an organization needs to win Parties as Customers, Suppliers, Employees etc., i.e. to create and record relationships between those Parties and the business.

In a traditional siloed approach, Parties and their relationships with the business organization are not differentiated. Parties in the role of Customer are kept in sales systems, Parties in the role of Supplier in procurement systems and Parties in the role Employee in systems related to Human Resources. This approach neglects a.o. that

• A Party can e.g. be Customer and Supplier
• A Party can be Customer in multiple sales systems that may coexist and be used depending on the product / service which was ordered
• Even within the same organization, Marketing, Sales, Order Processing and Accounting will naturally have a different understanding of what a "Customer" is
• Depending on the industry, even one purchase (order) / contract may have multiple "Customers", e.g. the roles of Contract Partner, Beneficiary and Payer may be represented by different parties.

Conclusion: The differentiation of Master Entities and Master Relationships is not only paramount for a structurally-sound approach that allows to generate a complete view of all relationships which a party has with a business organization. It is also a crucial prerequisite to extract and distill the value-critical components from the Master Entities and thus to reliably evaluate the actual benefits and costs as well as the opportunities and risks of a business connection based on the detailed benefit / cost / opportunity / risk that come with each single role that a Party occupies.

A Different Introduction to Data Governance

Most likely, you have heard the term Data Governance before, or even read multiple attempts to define it...

No, Data Governance is not just a hype, and it's not the latest intrigue of your IT department. It's not about pushing responsibilities or blaming people. It's not about being picky, and you don't only do it to please others.  

It does not even require more work, actually it's the opposite, and - put in simple words - the principles of Governance can be summarized as: Do things right the first time!
 

And Data Governance: Do all things data right the first time!

Who wants to question this approach? What is the alternative? "Do it sloppily now, we'll fix it later if necessary!"? Well, if it's not necessary why even taking the time to do it sloppily? And if it's necessary, why spending additional time later when it's much easier (faster, more economical) to do it properly right away?

In any event, too many organizations have 'let it go' for too long, over time data issues have accumulated - and that's why we are talking Data Governance now...

Modeling Party-to-Party Relationships

Inspired by a question that was raised on a data modeling forum, namely, how relationships between instances of the master entity Party should be modeled, I created a representation as of image 1.

Image 1 - Click on image to enlarge it

To illustrate a solution by example, the model includes a

• 1-to-1 relationship (Is_Married_To)
• many-to-1 relationship (Is_Child_Of_(Mother))
• many-to-many relationship (Is_Employed_At)

as well as a relationship attribute (Employment Start_Date).

This model is normalized, i.e. built in a way that it enforces the maximum of  semantic / business rules (particularly maximizes mandatory (NOT NULL) attributes) and referential integrity. Attributes and relationships are assigned to the specialized level, since e.g.

• a Legal Entity is a Party, but does not have a First Name,
• only a Person can be employed at a Legal Entity.

The normalized model serves as a reference for an operational process / application that creates, updates and/or deletes instances of the included entities.

Image 2 shows a “soft” (denormalized) model of the very same scenario.

Image 2 - Click on image to enlarge it

In this model, Persons and Legal Entities are not distinguished on the entity level, and all relationships are submerged under a generic many-to-many representation. As a result, there is nearly no enforcement of semantic rules and referential integrity.

Accordingly, the denormalized model is not suitable for an operational application. Depending on the purpose, it may be useful as a data warehouse model provided that its instances have been captured using an application based on the normalized model and then mapped / ETL'd into a database created from the denormalized model.

Please be invited to weigh in.