Tool to Track Which Databases Keep Customer Data | LinkedIn Group: Master Data Management Pros

Follow the LinkedIn discussion

My comment

I suggest you to use a professional data and process modeling tool suite.

The data modeling tool component will allow you to have an inventory of the data, i.e. which fields (particularly: customer data) reside in which database. Typical use of the data modeling tool could be:

• Reverse engineer each database, i.e. automatic transfer of the database structure to a graphical/textual representation in the data modeling tool.
• (Since even (semantically) same fields will have different physical names in different databases...) Link synonyms to a common business name, e.g. "cust_name" and "cli_nam" could both represent "customer name". 
• Add/modify any other crucial description that may be missing/incorrect.
• Integrate the database models into subject areas (A subject area will give you the synchronized business view of how e.g. a customer is - and perspectively should be - described in your organization, e.g. by customer first-name, customer family-name, customer date-of-birth, etc.)

The process modeling tool component will provide you a graphical/textual representation how the database fields "flow" through your organization, i.e. which fields are included in the "input" and/or "output" data flow(s) of a process (program, module, dialog,...).

Ideally, the tool suite will be integrated, i.e. database fields that are captured in the database reverse engineering step (using the data modeling tool) can be linked to the fields found in the analysis of the data flows (using the process modeling tool) and vice versa.

How you apply the modeling tool suite in detail will certainly depend on the mid and long-term goals of your organization, e.g. merging/replacing application systems, evaluating new software packages, changing platforms, going mobile etc.

Considering any of these targets combined with your initial question, I recommend you to check out the SILVERRUN Professional & Enterprise Series at www.silverrun.com . (In the spirit of full disclosure: I represent Grandite, the maker of the SILVERRUN tools.)

Please do not hesitate to contact me for further information directly, you will find my coordinates in "Contact Info" of my LinkedIn profile.

A Master Data Mind Map | LinkedIn Group: DAMA International

Follow the LinkedIn discussion

My comment 

Starting with a mind map is definitely a more "relaxed" technique during the brainstorming stage of an MDM endeavor, compared to immediately using a data modeling tool. The relationships between master data entities are simply specializations, so, at the first stage, the creative process is not overloaded with the pressure to name relationships and assign cardinalities.

Therefore, this approach is more suitable to obtain acceptance from the target audience (stakeholders / representatives of the business units). Their engagement and contributions are not only indispensable to find and define master data entities as the center of operational transactions, but also to build a sustainable basis for analytics processes: As you mentioned in your blog, master data are about the Who (Party), What (Product / Service) and Where (Location), i.e. these master data entity categories (together with When = Time) also define the dimensions of the analytics space, as most business questions can be projected into and then answered from this 4-dimensional structure.

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.

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.)

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).

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.

MDM vs DWH vs CRM | LinkedIn Group: MDM - Master Data Management

Following the LinkedIn discussion

My comment

Subject of MDM is the management of all master entities and the relationships among them as well as with other non-master entities, since the commercial value of MDM is derived from the relationships (roles). ...

An insurance company like your organization that covers Life, General and Health Insurance will need to consider the following master data entities

* Party (natural person or legal entity, but also social group such as household) with their roles "policy owner", "insured person", "injured person" etc.

* Thing (any tangible or non-tangible object, e.g. your products, but also cars, houses) with their roles "policy product", "insured object", "claim object" etc.

* Location (physical or virtual place) with their roles "insured address", "claim location" etc.

The above examples show that MDM in an insurance company is quite complex if you want to profit from it to the maximal extent. Since MDM in any established insurance company is a multi-year integration endeavor that will affect (almost) each and every department, I recommend to develop a plan for the best individual economical approach (cost of inaction, return on investment) to stepwise cover your organization's application landscape.

My additional comment

The duplication of master data should of course be avoided.

In the ideal case, master data are managed by a central application, and all operational applications directly create and update master data using an API of that central MDM application (hub architecture style: "Transaction"), but this is also the most ambitious solution.

Since it will not be possible (and is not recommended) to reorganize all operational applications in one project, your organization will need to develop the already mentioned stepwise approach. During the interim period, it may be necessary to keep master data redundant in the legacy applications and the evolving central MDM application.

However, what will be the best economical solution (i.e. which hub architecture style will best resonate with your organization), can only be found via an individual analysis and business modeling (data, data flows and processes) of existing and potential future applications. For a quick overview of the principal architecture styles for the MDM hub, I recommend you to check out this page: http://datamanagement.manjeetss.com/page/2

MDM and map projection | LinkedIn Group: MDM - Master Data Management

See the triggering post

Follow the LinkedIn discussion

My comment

Surprisingly many organizations have not realized yet that they are part of a global economy. At least those that have a Web presence should consider that they have an audience (and maybe even clients) outside of their geographical, political and cultural area (usually their country).

On a daily basis, we can observe that Web publications, even those of internationally renowned businesses, show a lack of awareness and sensibility for their foreign visitors. A simple example is the date format:

Numerous organizations continue to use their "local" way of displaying a date like "02/04/2012" which leaves their audience second guessing if this is "February 4, 2012" or "April 2, 2012" (the latter one is the way most Europeans will interpret it). With all due respect to cultural identity and geographical habits, the Web is a worldwide forum, and time-related information such as a date needs to be displayed in a non-ambiguous manner.

My thoughts regarding MDM (certainly not exhaustive, but a start):

• Think as a cosmopolitan, make the world your universe.
• Make sure that the descriptors that comprise an address identify the place uniquely worldwide, i.e. the foreign post service can deliver successfully. (The use of a geographic coordinate system based on longitude and latitude in addition to the postal address system is already in discussion.)
• Apply international standards. If there is no globally accepted standard, the minimum "standard" is non-ambiguity. In the above example, a date should/could be comprised of using two digits for the day, (at least) three letters for the month and 4 digits for the year. So depending on the cultural background, personal taste etc. the date could be displayed as "4. Feb 2012", "Feb 4, 2012" and even as "4 2012 Feb" and will not leave any room for interpretation.
• Mention the unit system, e.g. a temperature of "40 degrees" can be either very warm (if related to "degrees Celsius (Centigrade)") or pretty cold if related to "degrees Fahrenheit"; same of course applicable to length, weight etc. Certainly the metric system is recommended.

Also, avoid derived data as part of MDM: the age of a person is not Master Data, the birth date is. (The Mercator projection coordinates of the outline of Greenland are not Master Data, the coordinates in longitude and latitude are.)

With the above suggestions, MDM should have a solid basis - until we conquer other planets or will be victim of a "merger" after being invaded from a distant galaxy... 

What domains are people managing with MDM? | LinkedIn Group: Multi-Domain MDM

Follow the LinkedIn discussion

My comment

There are three main domains to be considered for Master Data Management: Party, Location and Thing.

Party is any natural person or legal entity that is relevant for your business. Depending on your industry, you may also want to consider Household as a sub-domain of Party. A party can take multiple roles e.g. be a customer and/or a supplier and/or an employee and/or a subcontractor.

Location is a physical or virtual place that is relevant for your business. Traditional examples are Postal Address, Phone Number. With the raise of social media / alternative ways of communication, you may want to consider e.g. Twitter Handle, LinkedIn Account, Skype Id as (virtual) locations.

Thing is any tangible or non-tangible object that is relevant for your business. As opposed to Party and Location, the range of sub-domains for Thing will vary from industry to industry. Typical examples are Product, Service, Material, Item, Part, Store, Machine, Tool.

How to start MDM? | LinkedIn Group: Multi-Domain MDM

See the triggering post

Follow the LinkedIn discussion

My comment

Your question revives the age-old discussion whether the development of a new application system requires a detailed analysis of the legacy system, and if so, at which stage of the project and to which extent.

For MDM projects as well as for the development of any application, I recommend the following principal steps in this particular order (which is of course only an extract of the actual activities during a software project):

1. Develop the data model structure with the primary metadata (entities, relationships, keys, main attributes including their names and textual definitions) solely based on the requirements for the future application system to avoid being biased by the legacy system (or by any standard software package considered as candidate for the replacement of the legacy system).

2. Once the structure of the new data model is solid, compare the metadata (data model) of the new application with the metadata of the legacy system to add missing attributes including their names and textual definitions to the future data model (i.e. ensure that at least all existing metadata or their semantic correspondences are included in the new data model).

3. Analyze the current data content to complete the attributes’ descriptors (type, length, nullability, permitted range of values, default values) in the future system's data model (i.e. ensure that all values of the legacy system can be mapped / migrated to the new system).

In other words, the current data content does not need to be examined before the structure of the future data model is solid, but certainly before the (logical) data model can be considered being complete and verified.