Business Intelligence Network - The Vision for BI and Beyond

Implementing and Using a Shared Business Vocabulary

Published: 11 July 2007

The author's last article discussed the concepts of a shared business vocabulary (SBV) and the benefits this would bring to the business. This article expands on the SBV concept and discuss how to implement and use an SBV successfully.

In my last article, I discussed how the business process drove the design of an SBV with the help of business stakeholders who owned the data entities. 

All that’s left is to implement, use and manage it!

The Toolsets

As in most IT strategies and developments, there is need for some sort of tool; and in all cases, there are vendors in the marketplace more than willing to sell you their products.  The correct tool is necessary to make the task of designing, developing and implementing an SBV solution possible.  There are a number of products on the market that will fit the bill, but product functionality needs to be assessed.  Following are the areas of functionality that I feel should be a priority.

• The data modelling tool should be packaged as part of an enterprise architecture toolset.
• Is the tool aligned to any enterprise architecture frameworks, like the Zachman Framework?
• Are the latest RDBMs (relational database management systems) supported – in-particular, the ones used by your business?
• What IDEs (integrated development environments) are supported (e.g., .NET or Java-based ones like Eclipse)?
• Document generation, which is very useful for publishing to the business users.
• Import and export functionality, which is very important when generating XML schema for data translation.
• Logical model to physical model translation.
• Ease of use.
• Synchronisation capability between models.

Data Modelling

Once the requirements are understood, then modelling of the SBV can begin. If you are following an enterprise architecture framework, then you will have already discussed the conceptual design with the business, agreeing on what business entities are to be included, their semantic meaning and their characteristics.  This concept needs to be modelled.

Conceptual data models include:

• Business entities and their relationships that have been discovered by process analysis.
• The business entity name (i.e., the semantics).

At the conceptual level, the data modeler attempts to identify the highest-level relationships among the different entities.

The conceptual model uses the semantic meaning agreed to with the business or data owner and is therefore the foundation for the SBV.

The logical model is also modelled in the aforementioned tool. This is where the benefits of tool usage become apparent as we now have the ability to align the model by reusing definitions already in place from the conceptual model.

Logical data models include:

• All business entities and their relationships.
• All attributes for each entity (i.e., the characteristics).
• The primary key for each entity.
• Foreign keys (keys identifying the relationship between different entities).
• Normalization.

At this level, the data modeler attempts to describe the data in as much detail as possible, without regard to how they will be physically implemented in the database.

There should be some caution taken here.  In my experience this is the point where it’s difficult to go back should the business change their mind about the previously defined entities.  Any change after this point has an ever increasing impact on the project.  Once the logical SBV is in place it allows the other members of the project team to use the modeled entities; such as the developers, they can now start to design the class models based on the logical models.

Physical data models include:

• Specification all tables and columns.
• Foreign keys are used to identify relationships between tables.
• Denormalization may occur based on user requirements.
• Physical considerations may cause the physical data model to be quite different from the logical data model.

At this level, the data modeler will specify how the logical data model will be realized in the database schema.

We now have an SBV that can be used during development and progressed through the environments into production.

SBV Integration with Subscribing Systems

In most businesses today, there is a requirement for some sort of data integration, whether that be downstream subscribing systems or user interfaces in the form of BI reports or portals.

How does the SBV improve integration?

Ultimately, it keeps integration between systems consistent. Most modern integration toolsets, such as Microsoft’s Biztalk, IBM WebSphere and SAP use XML and, hopefully, our new enterprise architecture tool will be able to export in the XML format.  In “What's in a name?”, I mention that the SBV would be a protective barrier between the operational data that may contain erroneous data and the process and presentation layers of the architecture.   Let’s discuss this in more detail.

If we need to integrate our “new product development” application with some operational applications at the manufacturing sites, then we can export the product subject area data schema (model) and use this as a generic SBV schema, as opposed to an application specific schema.  Please see further details in Figure 1.

Figure 1:  SBV Schema Architecture

Figure 1 shows one use of the SBV schema in an integration architecture.  The same principles can be used when populating a data warehouse using ETL (extract, transform and load), messaging and web services, etc.

Is it Really That Easy?

No!  There are a number of obstacles that can fall in your way – mainly from the business, not technology.

Unless you can tie down the SBV agreement, you will always be at risk from the SBV semantics changing. Even if you do get sign-off on the SBV, different departments will challenge the entity descriptions.  The last thing you want are changes at this stage.

The area that causes the most contention is BI reports.  There are typically two types of disagreement:

1. Column header size
2. Column header labels

The key point of an SBV is that it contains a meaningful description of the data.  Sometimes this can be too long to make sense (e.g., ”EstimatedOrderUnitVolume” that has a data type of int 100.  This example can become an issue when the report developer is running out of page space and wants to reduce the column width by abbreviating the SBV name to EOUV or something equally meaningless.  This then starts the debate about having aliases for things like labels. Again, this tends to lead away from the SBV.  I suppose the message here is that it’s a difficult balancing act between having a pure SBV and usability/acceptance.

Data Governance

In my opinion, the SBV is never finished. There will always be projects and requirements that want to add or change the design of the SBV. This is why I mentioned the importance of synchronisation capability between models earlier in this article.  The SBV, its design, maintenance and usage, needs to be governed.  The IT industry is currently seeing data governance and stewardship as a hot topic, and rightly so. 

According to KIK Consulting and education services, data governance is “the exercise and enforcement of authority over management of data assets and the performance of data functions” and data stewardship is “formalising accountability for the management of data resources”.

Why build and implement a data governance/stewardship program?

According to a Gartner data stewardship research note:

Poor data quality is a significant inhibitor to the success of strategic initiatives.

It is “impossible to generate business value from customer relationship management (CRM), business intelligence (BI), or any effort requiring significant integration of data without a focus on data quality through optimal stewarding of critical business data and process.

To add to these statements, I feel that any business wanting to establish an SBV at the centre of their business integration strategy must identify a data steward and empower him or her to make the strategic and tactical decisions relating to data and how its structures are designed.

More information on data governance can be found on the Data Governance Institute web site.

Summary

To summarise, an SBV is a fundamental part of any business intelligence or business integration architecture that will provide common data for the business process, business intelligence and user interfaces iin ncluding BI reporting.  However, a successful implementation has its difficulties usually in the shadow of the business user.  All of this can be managed by having a good data governance strategy in place.

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.