What does represent for you Enterprise Information Map? | LinkedIn Group: MDM - Master Data Management

Follow the LinkedIn discussion

My comment 

Your approach perfectly makes sense.

Call it "Enterprise Data Architecture", call it "Enterprise Information Map" - it is indispensable to get ready for the future. In any medium and large organization, (almost) all operational units create, update, use and interpret data for the major part of their daily business duties (even where tangible goods are produced using machines, the latter ones are data-driven.) Consequently, medium and large organizations are first and foremost in "information business" (whereas the underlying data model may vary depending on the industry).

An Enterprise Information Map is therefore not only helping the CIO to develop a road map from a siloed to an integrated application landscape, but should primarily serve as a blueprint for the CEO (with "E" as in "Executive") to pursue the alignment of the operational business units with the "new reality" of being an information business. The CEO should assume leadership in this alignment process, nominate responsible parties and monitor progress and results closely.

In a nutshell, the alignment includes (but is not limited to) business (not IT!) activities such as:

• Design the Master Data model as the core piece of the Enterprise Information Map
• Assign ownership of information entities to business units 
• Identify "central" information entities without "natural" owner (such as master entities Party and Location as well as reference data) to a (new) central unit responsible to conceive mechanisms for management and governance of "central" information entities and to license the above mechanisms for reuse in decentral business units
• Nominate data stewards in decentral business units that are responsible to reuse central mechanisms and, based on entity ownership, to conceive decentral measures for data governance
• Reorganize business processes based on the above mechanisms as well as to integrate data governance measures
• Restructure existing business units to support the reorganized processes
• Train managers and staff how to support the "new" culture.

The above is only a primer to answer your initial question within the given limitations of this medium. Therefore, please feel free to follow up or contact me directly.

I'd like to emphasize here, though, the importance of the CEO's commitment to make sure that the investment into an Enterprise Information Map pays off and will not only remain a sandbox game.

Bank of England doesn't need a Chief Digital Officer, claims CIO | Article in Computerworld UK on November 12, 2013

Interesting article in Computerworld UK titled "Bank of England doesn't need a Chief Digital Officer, claims CIO" citing Bank of England's recently appointed CIO John Finch. 

One of the core sentences in this article: "Speaking at Gartner's Symposium in Barcelona this week, Finch detailed his vision for the BoE [Bank of England] to become a 'digital social enterprise', but said that this will be achieved by ensuring that the entire senior executive team is technology savvy." 

My comment 

Mr. Finch' statements (as cited in this article) promote a long-due paradigm shift in the self-understanding of senior managers, applicable not only at the Bank of England.

However, I take a slightly different view on what will be a must-have for senior managers to qualify as such in the future. In a nutshell: The business of any financial institution is nothing else but trading with information. Accordingly, it is indispensable that all senior executives are 'information-savvy' (not necessarily 'tech-savvy' which ought to be the IT's/CIO's domain) and assume responsibility for their respective business-area's information model aligned with the institution's Enterprise Data Architecture.

The Corporate Data Model – Holy Grail? Doomed to Fail? Hype? | LinkedIn Group: DAMA International

Follow the LinkedIn discussion

My comment 

Without Corporate Data Model, any organization will end up in a siloed application landscape with all the known issues when trying to get some insight from 'cross-border' attempts such as analytics / business intelligence that are indispensable for optimal decisions as well as to differentiate from the competition.

The way Corporate Data Models (or Enterprise Data Models) have been tackled in the past, i.e. to cover the whole organization in one project, is doomed to fail: Such a project takes too long, binds too many resources, does not promise any value before finished, and, whenever ending, the resulting model will not reflect the business reality anymore.

Instead, I recommend to limit the 'Corporate Data Model' to the intersection of the business areas, i.e. in a first step to model only those objects that are shared by all parts of the organization including their major connectors to the different areas.

Interestingly, those objects include the Master Data Entities (Party, Product / Service, Location), connectors include the roles that these entities take (such as Customer, Supplier, Employee, Invoice Address, Delivery Address etc.). The adjacent business areas can be modeled later, as priorities of reorganizing them come up and related projects can economically be justified.

This approach 

• Lays a solid foundation to the Enterprise Data Architecture,
• Serves as the core piece for Master Data Management, Data Quality and Data Governance,
• Creates the frame (primary dimensions) for a virtual or real data warehouse (as it gives answers regarding the Who (Party), Where (Location), What (Product/Service) and When (versioning / timestamps)).

My follow-up comment (Nov 10, 2013)

To foster cohesion and reuse of the model and its components (and, more importantly, nourish "common" sense among the heads of the business areas led by a committed CEO), the "Common" Corporate Data Model must include all major entities and connectors that define the business as a "Corporation". (Example from insurance industry: Though not being Master Entities, "Policy" and "Claim" are "Common" Corporate Entities.)

The "All-including" Corporate Data Model will evolve over time - by integrating business area model after business area model with the "Common" Corporate Data Model (whereas adjustments of the latter one ought to be the rare case, but cannot be avoided.)

Do we really need a CDO? - Installment #2 | LinkedIn Group: Data Governance & Stewardship

Follow the LinkedIn discussion

My comment 

Today's business in medium and large organizations is to process nothing but information. (Even if organizations produce tangible items, they will use machines which are information-controlled.) With reference to my blog post "Who is responsible for Master Data?", I like to emphasize the CEO's responsibility for Master Data as well as the C-level-managers' / VPs' responsibilities for the information that is created, updated and deleted in their respective business unit. 

That may sound absurd to some, as it alters the business managers' traditional role, but it is preferable to reorganize existing business units and responsibilities instead of adding another layer such as a CDO which only contributes to confusion and conflicts.

Duration and ROI of MetaData Project | LinkedIn Group: Data Quality and Metadata Management

Follow the LinkedIn discussion

My comment

There is certainly no formula to estimate the cost, workload, time associated with a metadata / business modeling / information architecture project.

It's axiomatic to do it, as we do not question whether a country needs an army, whether we have to clean up our office desk (at least once in a while) or whether we take a shower with a certain frequency (at least I have not heard of anybody yet that has put an ROI on it). Just because their ROI cannot be quantified does not mean, it's legitimate to neglect certain tasks, sometimes common sense ("what would my mother have told me") provides a sufficient answer. Unfortunately, it has become "popular" in medium and large organizations over the past 20 years not to pay to much attention to activities without direct monetary outcome, and that is the reason why so many businesses today struggle with legal compliance, security, privacy and data quality issues.

Surely, the way out of such a situation is not to "boil" the proverbial "ocean". I suggest to collect and model metadata by business unit and/or application following the priority in which their reorganization and modernization is justified and scheduled. However, proceeding by line of business comes with the risk that existing vertical silos are maintained or newly created. It is therefore important to start with a horizontal integration modeling project that lays the foundation for the information architecture of the organization. It will show on a high level how the lines of business interact and exchange information with each other, and thus indicate where central objects are shared (Master Data Modeling / Management).

Standardization Of Terms At All Costs?

(This post was originally published as a comment to Paula Wiles Sigmon's article "Define Terms, or Doom Your Project" on IBM's The Big Data Hub.)

Though being desirable in an idealized world, the attempt to unify the terminology is quite problematic in larger organizations, as the standardization process throughout multiple disciplines of the business and IT is not only very time-consuming, but

• may result in artificial deviations from traditional terminology for certain disciplines
• will leave "winners" and "losers"
• will start again with the next M&A
• may create naming conflicts with the next acquisition of standard software.

To avoid, at least to minimize, the above effects, I recommend to decompose the business data model into a "global" data model and several "local" data model (one per each "department" / line of business). In a nutshell, the approach should be as follows.

For entities and attributes that are supposed to be used "globally", i.e. by more than one line of business:

• Create a global model.
• Agree globally on the semantics and definitions.
• Derive a unique, logically meaningful term / name for each object ("common item") in the global model.

For each line of business:

• Create entities and attributes in a local model.
• Link objects of a local model with the semantically corresponding objects of the global model (as far as a local model intersects with the global model).
• Agree locally on the semantics and definitions (as far as they are not "governed" by the global model).
• Derive a unique, logically meaningful term / name for each object (common item) in the local model (as far as it is not "governed" by the global model).
• Allow local synonyms for the common items in the global model.

The above approach reduces frictions among departments with partially overlapping local models and creates a cross-reference system of common items and synonyms. There is no need to "boil the ocean", but local models can be created as projects come up and be iteratively integrated with an incrementally growing global model.

Professional and practical data modeling tools will support the above mentioned steps to link and integrate the global model with local models and to maintain the lineage between the "same" objects in different models.

How to assign Data Stewards to logical pieces of an org's data | LinkedIn Group: DAMA International

Follow the LinkedIn discussion

My comment

As a first step, an organization needs a high-level logical data model to represent the target enterprise data architecture. Using that model, you can assign each subject area / entity to an organizational target unit that is typically responsible to create/update that entity as their respective owner. (I use the term "target" because the current enterprise data architecture - if even documented - may be siloed and also that the current organizational structure may not be optimized for future purpose.) 

Each owning organizational unit should be represented by one or several Data Stewards. 

Applying the above principle, the subject areas / domains of entities that are assigned to a certain organizational unit can be easily drawn, as the vast majority of entities has (more precisely: in the future should have) only one natural owner which typically is not only the creator of the data but usually also its main consumer. 

However, particular attention is to be paid to the Master Data domains, especially Party. The objects of Party occur in many different roles (customer, supplier, employee etc.) and therefore have either none or many potential "owners" (Sales, Customer Service, Purchase, Human Resources etc.). 

I recommend to create a separate central unit that takes ownership e.g. for all matters related to Party and represents the interest of the organization as a whole and not only of one department (the latter being one of the reasons for a siloed structure in the first place). This central unit has "the license" to define the entities/attributes related to Party, the business rules, the data governance measures etc. Other organizational units ("licensees") embed this "one and only" way of creating/updating objects of Party into their processes and supporting applications. Certainly, the Data Steward(s) representing the licensor need to consult the data stewards representing the licensees to make sure that all the requirements of the latter units are taken into consideration. 

This been said, there is no reason to "boil the ocean", i.e. no need to have a complete coverage of the whole organization, before any fruitful work can be started. 

I agree with a previous comment to focus in priority on areas with problems, i.e. where engaging in Data Stewardship can be justified by the ROI and/or where the COI (cost of inaction) indicates ongoing loss of money or the risk of fines (for industries that need to comply with requirements of regulatory authorities). Data Stewards for prioritized areas can start their work as a project task force and may later evolve into a formal, permanent role.