The data management literature is full of exhortations to recognize business needs: hold workshops to gather requirements, get approval for data models, appoint Data Stewards with a vested interest in data quality. Makes sense, because data is an asset, the basis for important business decisions and actions, right?
When a seminar speaker talks about getting good attendance at data-stewardship meetings by offering good snacks, I begin to wonder. When business representatives don’t find time to read through the data model before implementing the system, I wonder. Why don’t the business people care about the data? Here are some reasons more fundamental than the snacks – and what you, a data architect or data management person, can do about them:
- The business people don’t care enough about the future of the organization to take care of its assets or plan for good computer systems.
Your organization’s morale problem is much more important than the data issues. Go work on the policy or personnel issues that are demotivating everyone – or quit!
- The business people assume they can solve the data issues later; other issues are bigger right now.
Yes, some data decisions are hard to change later. Estimate the cost of modifying the database or making other changes later. These might be less than other potential costs the business is worried about, or they may be less than the potential revenue from getting the system implemented faster.
Yes, data quality has a long-term impact on customer service and business intelligence. Consider which data elements will actually be valuable to the business in a few years.
Remember that the business may change in unpredictable ways. (For example, the database you generalized to allow for change might get thrown out entirely.) Business people take bigger risks and deal with broader issues than data management people.
- The business people can tell that the data consultation is perfunctory.
If people think you will ignore their input, they won’t bother providing it. Find examples of business suggestions that were actually implemented in your organization.
Business people may also feel disempowered if a consultation is filled with technical questions that they can’t answer. Addressing the next issue may make your consultations more meaningful:
- The business people can’t see the important data issues, buried in long verbiage or complex diagrams.
In other words, you haven’t made the data issues clear enough, nor explained why they are important.
I believe the classic guidance to get one business person to approve a conceptual or logical data model is impractical. A data model contains thousands of decisions, reflecting input from senior and junior business people, other architects & analysts, external data providers, existing systems, and standards for data modeling, data codes and more. The same applies to ETL specifications, XML schemas, and so on.
I also disagree with the classic approach of teaching business people to read data-model diagrams. It doesn’t solve the problem that an important issue was buried in an attribute definition on page 47, while the reader fell asleep on page 43. Would it not be more effective, and less arrogant, to express the important data decisions in a format that business people are willing and able to read?
Senior managers are well-equipped to review and approve a business architecture, specifying why the organization exists, what it does, who plays what role, and an outline of information and other resource needs.
Potential system users will understand and care about screen designs and (if you’re lucky) process models and use cases.
As you develop a data model from these inputs, or any other specification, collect a list of questions you’re unsure of, and significant recommendations you are making. Review these with the appropriate people – business, technical or external. Observe which questions they don’t want to be troubled with, and think of other ways to get that information.
Your data-management peers should check the formal data model or specification. Does it correctly reflect the business architecture and system design? Is it normalized and generalized enough (or too much)? Does it meet your internal standards for naming, notation, definitions, etc.? Does it align with international and national data standards? If you will be exchanging data with an external system, you will also need their technical representative to review your specification.
If your organization is struggling with data governance or system design approvals, try to separate the different kinds of business decisions you need made into different documents. Talk to the business about what decisions they would like to be involved in, and where they trust your best judgement. Don’t forget to discuss how much risk the business is willing to accept, when they don’t have time to validate your data architecture, because they need it implemented ASAP!