Clear Communication - The Foundation for Successful Business Metadata Projects
Data Integration Adviser
Information Management Magazine, February 2006
In my last column, 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.
Advertisement
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.
Rick Sherman has more than 20 years of business intelligence and data warehousing experience, having worked on more than 50 implementations as a director/practice leader at PricewaterhouseCoopers and while managing his own firm. He is the founder of Athena IT Solutions, a Boston-based consulting firm that provides data warehouse and business intelligence consulting, training and vendor services. Sherman is a published author of over 50 articles, an industry speaker, a DM Review World Class Solution Awards judge, a data management expert at searchdatamanagement.com and has been quoted in CFO and Business Week. Sherman can be found blogging on performance management, data warehouse and business intelligence topics at The Data Doghouse.You can reach him at rsherman@athena-solutions.com or (617) 835-0546.
In addition to teaching at industry conferences, Sherman offers on-site data warehouse/business intelligence training, which can be customized and teaches public courses in the Boston area. He also teaches data warehousing at Northeastern University 's graduate school of engineering.
For more information on related topics, visit the following channels:
