Most organizations today are in some stage of developing large, cross-department, data-related initiatives. In this Information Age, data is a strategic differentiator – a retail organization that has a strong vision around its customer information is a step ahead of its competitors. Many of the buzzwords surrounding data-related initiatives are common in both business and IT circles: master data management, business intelligence and data governance. But what do these really mean, and how can a high-level data model help with the efforts?

The following is a brief overview of several of the hot topics in data management today and discuss how a high-level data model can help with these initiatives, many of which are siloed projects or programs. Programs are large ongoing efforts that have a begin date and, if they are successful, no end date. They require long-term participation from many different sections of the business. Each program contains many bite-sized pieces called projects. A project is a well-defined effort with a begin date, end date and solid deliverables that contribute toward the goal of the program.

Due to the broad scope of program initiatives, very few people (if any) understand the big picture – how the initiative will fully impact the business and how each section of the business, such as accounting or sales, will need to be modified to deliver the objectives of the program. What’s needed is a simple, yet broad and complete picture showing how concepts cross departments so that the full impact of these large programs can be planned for and prioritized.

One benefit of using a high-level data model that spans all of these initiatives is integration. The high-level data model, with its cross-department focus, is a perfect communication tool for planning, scoping, impact analysis and project status for each of these large initiatives.

Business Intelligence and Data Warehousing

As organizations realize how data can be a strategic differentiator, more BI initiatives are born. The Data Warehousing Institute defines BI as the processes, technologies and tools needed to turn data into information, information into knowledge, and knowledge into plans that drive profitable business action. Because of its business focus, BI is one of the initiatives with the greatest involvement of business personnel in the organization. Many businesspeople create their own BI reports.

Included in BI are the software, hardware, network, data models, process models, reports and code to take raw data and turn them into something on which people can base decisions. For example, a manufacturing company can take millions of sales transactions and summarize them into a monthly sales figure. This turns data into information. Monthly sales this year can then be compared against monthly sales from last year for the same month, providing knowledge to the user of the information. This knowledge can lead to plans for how much to produce next year, which will hopefully lead to more money, less waste or a better world with more ice cream.

The backbone of any BI initiative is a data warehouse. If a BI report is a flashy sports car, the data warehouse is the engine. A data warehouse is the central storage point for all of the relevant information that is needed for BI reports; and turning data into information is no small feat. A single piece of information on a report, such as total sales, can involve the aggregation of hundreds of database tables from multiple geographic and functional areas. And each of the data sources can have different business definitions and physical structures. A major part of the effort of creating a data warehouse is obtaining the big picture of what data exists, how it is defined and what the end result should look like. This is where a high-level data model can come in handy.

Common language. A high-level data model provides a single agreed-upon set of concepts, definitions and business rules. This language must be consistent across the scope of the  model. If the scope of the high-level data model is the data warehouse itself, concepts such as Customer and Gross Sales need to be defined consistently. Customer, as defined by accounting, must be consistent with the sales department definition of Customer.

Common language enables the reader of the model to understand where the organization is striving to go, as well as conceptually how to get there from the existing environment. This common language has a direct benefit for the many users of the data warehouse, who can confidently interpret the concepts the same way.

Impact analysis. The high-level data model can be an effective tool for determining overlap and touchpoints. An overlap is when two or more different development teams are impacting the same concept, such as when two different development teams are both updating customer information. A touchpoint is when two or more different development teams need to connect with each others’ work. For example, when one development team is working on Product and another development team is working on Order, which has a dependency on Product. The link from Order to Product must be managed successfully.

A high-level data model can represent the entire data warehouse. Color is one technique for effective model layout that could be used to indicate to management where the touchpoints and overlaps exist for a particular phase of the data warehouse program. For example, a red concept Customer could indicate that at least two development teams are working on this same area for the same release date. A large bold relationship line between Customer and Order could indicate that in this release, there is a touchpoint that exists between these two concepts. The high-level data model can be updated during the lifecycle of the development effort to indicate successfully managed touchpoints and overlaps, as well as those that are experiencing problems.

Scoping and prioritization. Color can also be used to indicate which part of the BI program will be developed first, second and so on. For example, those concepts shown in green will be implemented as part of Customer Profitability by first quarter next year. In every project status meeting, this BI high-level data model can be presented to show progress since the last status meeting at a concept level. The model, therefore, becomes a part of every status document.

Employee education. When new people join the data warehouse team, there is usually a fairly steep learning curve. The new person needs to learn about the system architecture, data architecture, and the business in general. Starting this person off on the first day with a walk-through of the data warehouse high-level data model can give them a solid understanding of the area in which they will work – raising their confidence and reducing the amount of time it takes for them to learn the details.

Building reports. Businesspeople are often actively involved in building their own BI reports, which has, in part, fueled the growth of this technology. When building a report around total sales for product “X”, it is critical for them to understand the definition of both total sales and product. For example, does total sales include both U.S. and worldwide sales or just U.S. sales? There’s a big difference, but it might not be obvious without a clear, published definition. A high-level data model is a great tool for a business user to use in finding these definitions.

Master Data Management

Master data management, like data warehousing, involves the aggregation of diverse data sources into a single location with common structure and definitions. But while a data warehouse is used for reporting, a master data hub deals also with operational data. MDM initiatives are particularly difficult because they involve operational data that is in use by the business processes that run the organization.

Master data is any data used by and shared across the entire organization. MDM initiatives usually concentrate on the subject areas of information that are used by the majority of applications in a company. Not surprisingly, Customer and Product are two of the most common candidates for master data management today.

As we’ve seen, different areas of the organization can have very different names and definitions for the same concept. Customer for example, starts off as a Prospect in the eyes of marketing and may end up as a Customer Last Address Unknown in the eyes of billing. The same actual customer spans the entire organization however.

In order to use a piece of master data consistently, it must have the same definition and rules across the business. The high-level data model can be a great starting point to ensure that this consistency exists.

  • Consistent use. Because master data must be used consistently across the business, it must have the same name and definition. A high-level data model spanning the entire scope of a particular master data concept will ensure this. Customer, for example, will have one agreed-upon definition across the business.
  • Linkages. An important item to capture on master data is where it exists within the business. A high-level data model can provide important linkages back to everywhere a particular master data concept is created, changed or used. A high-level data model deliverable may be more than just a pretty set of boxes and lines. It can also include a mapping of the sources of and references to the concepts. This linkage at the concept level can be an invaluable starting point for mapping at a data element level.
  • Stewardship. The high-level data model can be color-coded or labeled in some other way to indicate who is responsible for a particular business area. “All concepts whose text appears in italics are Bob’s responsibility.” It can be a great technique for identifying and finding master data owners.

Data Governance

Data governance encompasses the overall management of the availability, usability, integrity and security of data.

There are four ways data governance is generally managed: by subject area, application, department or geographic boundary, or by a hybrid approach. Regardless of the approach implemented in your organization, the governance activities are coordinated through a community such as a data governance board or community of practice. These activities include planning, control and supervision, along with the associated processes for conflict resolution, education and awareness, strategic data planning, project oversight and key performance indicator monitoring.

A high-level data model with a broad organization scope provides the following benefits for data governance:

  • Planning. The high-level data model is used as the guide for all data governance activities and their associated processes. Each concept on the high-level data model will have a data owner and one or more data stewards. Data owners, stewards and information managers may reside in any part of the organization chart; however, their fundamental loyalty and belief structure must belong to the business community rather than the information technology community.
  • Accountability. In more mature organizations, traceability and accountability can be aligned directly within the high-level data model. This can be accomplished by adding properties to the data modeling tool to capture data governance attributes. It can also be accomplished using techniques mentioned earlier, such as the use of color or font.

How can you use high-level data models in your organization’s data initiatives? Consider which of the data initiatives described above are in place at your organization. Determine what information concepts are common to each of these initiatives (customer, product, etc.). Create a high-level data model to describe these concepts.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access