Business Intelligence Network - The Vision for BI and Beyond

ADVERTISEMENT

What's in a Name?

Published: 6 June 2007

How can an organisation be expected to make correct decisions to move the company forward if they do not have a clear and trusted representation of how information is used across the organisation? What's the answer?

Plenty! Unless your business has been built on a green-field site or you are one of the few who have opted to take on a major investment and deploy the latest master data management (MDM) system, you will most likely have applications and systems distributed all over your IT landscape. The majority of these systems will be operational by nature and implemented over a long period of time. Therein lies the problem, multiple systems that act as systems of entry (SOEs) for the same business entity or domain causing inconsistencies between data attributes, either semantically or within the data characteristics such as data type and data rules.

Figure 1 shows four applications that are based at a manufacturing site. Each has a different name for the business entity and primary key. Do they mean the same thing?

 
Figure 1: Applications and Business Entities

How does this permeate through the business? At first glance there doesn’t seem to be a problem, especially when the data is being used at a single application level and therefore within the constraints of a particular user or role. Low visibility of other applications suppresses the problem; the problem is only revealed when you increase the number of applications or systems the user has to use. Consider the user in Figure 2. The user starts by having access to one application, then progresses to two, three or more. The example in Figure 2 shows how the problem becomes exacerbated with more applications.

 
Figure 2: A Confused User

Imagine a user who is trying to read more than one report based on the example in Figure 2! How do you reconcile each of the reports with one another? The answer is with time and a great deal of effort – and even then you can’t be sure.

The Semantic Problem
Each department seems to have its own terms for things like sites, plants, customers, consumers and suppliers.

Look at these real life examples from the same company:

• A territory manager calls his manufacturing locations “sites,” the IT department calls them “branches” and finance calls them “business units”. Distribution calls the customer’s store a “site”, while the territory manager calls it a “store”.
  
• Manufacturing uses “production line”, while finance calls it a “plant”.
  
• Some people say “customer and site”, while others say “account and customer”.

These examples make the point that the semantic meaning behind data is the cause of a lot of problems within the business.

The Characteristics of Data
As mentioned earlier, there is a second part to the problem, and that is with the characteristics of the data. Let’s take a real life example. A manufacturing site has a number of applications that have been acquired over a number years:

• Downtime
  
  
• Enterprise Asset Management
  
  
• PeopleSoft
  
  
• SCADA (Process Control)
  
  
• Planning & Scheduling

All these applications use Plant_id as a keyed attribute, but they all use a different format for the same plant. Again, how do we easily reconcile across the applications? As a site manager or CFO, I’d like to use some business intelligence (BI) and run a report based on plant efficiency by extracting data from all the applications listed and present it to the IS steering committee so that we can address the issues. Which Plant_Id do we use when creating or reading the report?

To take these issues to the extreme, how can the board of any organisation be expected to make correct decisions based on this sort of information? You would expect that the organisation you work for has the correct information to move your company in the right direction!

What’s the Answer?
Create a shared business vocabulary (SBV). An SBV is an agreement between the business and the IT department. Its focus is the enterprise–wide business entities. The SBV should be a business initiative that is implemented and facilitated by IT. Each business entity should be assigned an owner. For example, you could argue that the customer entity would be best placed with the sales department as they own the relationship with the customer. An SBV should address the semantic and data characteristic issues that I previously mentioned. Used correctly, the SBV could eventual be the logical and physical design for your underlying database. But this is not always as far as you would go.

However, an SBV isn’t the easiest thing to set up. I’ll try to explain why.

Although this should be a business initiative, it is highly likely that you will have difficulty getting the business interested. The only way to do this is to get sponsorship from the very top of your organisation and cascade down. Even then, other priorities will take precedence. If this is the case, then the most effective way is to push from the IT side. Following are the steps that you should take to establish an effective SBV strategy.

• Capture all the enterprise business entities.

• Understand the scope, use and meaning of each entity.
  
  
• Try to identify who owns each of the business entities that you found while conducting the previous exercise (an example would be sales owns customer).
  
  
• Establish the correct semantic meaning of the business entity.
  
  
• Establish the correct semantic meaning of the attributes.
  
  
• Ask the data architect or DBA to define the characteristics of the data. These could include:
  
• • Common data names
  • Common data definitions
  • Common data integrity rules
    
    
• Establish mappings from disparate data to common data.
  
  
• Analyse the business processes that affect the business areas and get the additional data requirements.
  
  
• Get agreement and sign-off from the business. Make sure business own the SBV and any changes that might arise.
  
  
• Find a tool to model the SBV at a logical and physical level.
  
  
• Understand how the SBV will fit in with the enterprise architecture.
  
  
• Implement it.

Once implemented, the SBV can be used either as a master data repository or an XML schema or both, but in all cases, it should be used as a protective barrier between the operational applications and the process, workflow and/or user interfaces. If a new project requires that the applications in Figure 2 are to be used to populate a data warehouse, then all the application-specific data schemas should be mapped and translated to the SBV. The same mapping exercise would also be applicable if we were presenting the operational data to a process, workflow or new user interfaces.

The Business Benefits
If the recommendations here are implemented, then the benefits to the business can be vast. The correct use of an SBV will provide all business users with a common view of data from across the various parts of the business. It doesn’t matter whether the user is using a BI report, a portal to view collated data, or a new user interface, the user will see the same information with the same semantic meaning and the same values. This also extends to the use of enterprise workflow management and business process management. Figure 3 depicts the SBV solution.

Figure 3: SBV Architecture

As can be seen in Figure 3, the SBV separates the process, workflow and user interfaces from the operational data, thus ensuring consistency. Now the decision makers in the business, from operational managers up to board level, have a clear and trusted representation of how information is used across the organisation, and confident decisions can be made about how to move forward.

Yes, names do matter!

If you found this article helpful and would like to receive the latest insights each month from Mike Ferguson and other experts featured on the Business Intelligence Network, please subscribe to the UK Business Intelligence Network Newsletter.