In Align Metadata and Business Initiatives, we discussed the two types of metadata: technical and business. The fact that there are two metadata types may be old news to some of you, but plenty of people still succumb to the classic metadata trap of not really understanding what kind of metadata the business users need.

This unhappy scenario begins when the IT staff thinks that the business users want all the technical, tool-specific metadata. But that’s not what the business users want at all – they want to know what the data represents. So, despite this misunderstanding, the metadata project gets underway. The IT staff collects the technical metadata (thinking it’s what the business users want) and confirms this hypothesis with the business group’s power users. The power users are happy because, after all, they are power users – not typical business users. They think that technical, tool-specific stuff is great. Then, the so-called business metadata is rolled out to the “real” business users – and they don’t know what to do with it. They become frustrated and label the metadata project a failure.

The Age of Discovery

You cannot meet the business users’ needs until you know what they want. That means you have to talk with them … and listen to them. A quick hint: if their eyes roll back in their heads when you mention the word metadata, it’s time to approach the subject in another way. That means you need to speak their language. You may need an interpreter to translate what you are asking and what they are answering. Without that interpreter, you’ll both walk away from the discussion thinking that you agreed but actually having totally different outcomes in mind. Pick your interpreter wisely. Many times, the business group’s power user thinks too much like an IT person to really translate the business users’ needs. An IT business analyst or a business user who is tech savvy (but not too tech savvy) would be good candidates.

As you go through the discovery stage, gathering business users’ requirements for metadata, make sure that you create a feedback loop with groups of business users to validate these requirements. Don’t accept nods from businesspeople during review sessions; make sure you confirm that they see the value and are going to use it in their jobs. If the business metadata is not perceived as producing business value, it’s time to retrench. You may need to market and sell the business metadata project to the business. If you overlook this effort, you may learn a very expensive lesson in building a product that nobody buys.

The Value of Documentation

We may complain about the quality of the documentation we receive from vendors, but what about the documentation that we provide to the business users? We need to provide the business metadata (i.e., the business solution’s documentation) in the business users’ language. Techno-speak won’t do.

Just as we needed an interpreter to understand what the businessperson was talking about, we need a translator (i.e., a good writer) to describe what the data represents. Skipping this documentation step guarantees that the business users will be frustrated when they try to understand how and, more importantly, if they are going to use the system you just built.

The documentation should answer the business users’ question: “What does this data represent?” The answer should be in business-speak, not techno-speak. Done right, the documentation provides the business user with a clear description of what the data represents – a description provided by the business users during the discovery phase. Once everyone is clear on the business metadata, it can be linked to the underlying technical metadata for IT and power users to view.

Don’t be fooled into thinking that you know what your users want or that you can explain to them what you built. Technical prowess has always been valued in the IT community; however, communication and writing skills are equally valuable if you aim to get business users to use and value the data systems you developed for them.