Data model design tips to help standardize business data
Data models should be understandable to business users and kept to a reasonable scope, say the leaders of a data modeling initiative at England's Environment Agency.
England's Environment Agency had a big problem: a lack of internal data standards that made it hard to pull together information from different parts of the organization. Data definitions and terminology varied from system to system, saddling the agency with incompatible data silos. The answer, eventually, was a data modeling initiative to help harmonize things.
One of the eye openers on the need for enterprise data modeling was a move to combine all monitoring data on chemical use by regulated entities in a new application, according to Becky Russell, national lead for data standards at the Environment Agency (EA). Compiling a master list of the chemicals involved was a challenge because of internal terminology differences, Russell said in a Dataversity webinar that provided data model design tips and project management best practices based on the EA's experiences.
After she joined the EA -- England's equivalent of the U.S. Environmental Protection Agency -- in 2013, Russell initially focused on efforts to standardize the detail-level data in systems. "But it soon became clear that the data model level was where we needed to be," she said. Conceptual and logical data models could provide shared starting points for structuring data and fuel the development of common data definitions, controlled lists of data values and other agency-wide standards, Russell added.
Dos and don'ts on data modeling practices
Russell spoke during the webinar along with Donna Burbank, managing director of Global Data Strategy Ltd., a consulting firm based in Boulder, Colo., that is assisting the EA on the data modeling process. Here are some of the data model design tips and lessons learned that Russell and Burbank outlined.
Use business language in high-level data models.Conceptual and logical data models should "tell a story" about the data that business users can easily understand, Burbank said. That means using business terminology in the models and showing how they relate to real-world applications. Otherwise, data modeling can seem "so academic and abstract" to users, she warned.
"When a data model is successful, part of the reason is that you're using the language of your audience," Burbank said. In the EA's case, doing so led to "a lot of ah-ha moments" on data inconsistencies, she noted. "Different teams were doing similar things and calling them something different, or calling them the same thing with a slightly different meaning." That reinforced the need to find common ground.
Start with a draft model and refine it based on business input. Russell and Burbank didn't present the data models as finished products to business users. Instead, they adopted a consensus approach that combined top-down and bottom-up modeling work, with business managers and other users giving feedback on draft versions of the models that were created after initial research and user interviews.
"We had enough to start with, but we were flexible," Burbank said. "We did not come in and say, 'This is how it is.'" Showing that they were willing to listen and make changes based on the feedback helped gain support for the modeling initiative, she added.
We did go down some rabbit holes, but it was part of the journey to get us where we are now.
Becky RussellNational lead for data standards, Environment Agency
Stick to a reasonable scope on data modeling. On the other hand, Burbank cautioned that it's all too easy to keep iterating on data models with no end in sight. Prioritizing what's really needed is a key to effective data model design, she said. "We had to sort of keep ourselves in check on the scope to not let it get out of hand."
That included limiting the data modeling project to new IT systems and applications. Russell said doing so avoided thorny issues about making changes to existing ones -- another plus for the EA's business units. "It stopped them from being protectionist and allowed them to free their minds to think about new approaches," she said.
Don't pin your hopes on industry-standard data models. In their presentation, Russell and Burbank said they considered using a standard data model but decided that it wouldn't meet the EA's needs. "Any industry model doesn't match the way an organization really works," Burbank said. "I think that's the case everywhere."
Create virtual teams as part of the modeling process. Russell and Burbank held a series of data modeling workshops to bring together users from different departments at the EA. Part of the purpose was to explain data modeling concepts to them and get buy-in for the initiative. "We did have a lot of arguments and personalities," Burbank acknowledged. "It probably took a few workshops to [make them] realize that we were on their side."
But the workshops also enabled the users to interact with one another and reach consensus on data model design issues faster than could have been done through one-on-one meetings. "It got to the point where they were arguing things amongst each other rather than arguing things with us, which was quite refreshing to see," Russell said.
Make communication a top priority. In addition to the workshops, Russell and Burbank produced webinars and reached out regularly to update the business side on the data modeling work. "We needed to just keep telling people what we were doing and why it was important," Russell said. That also included acting on user feedback, "at least to respond to it," she added.
Eyeing data modeling's business benefits
Despite the efforts to bring business users into the fold and limit the scope of the data modeling activities, the process at the EA hasn't been entirely smooth. "We did go down some rabbit holes, but it was part of the journey to get us where we are now," Russell said -- to the point where business users "are blowing the trumpet, really, for data models and data definitions."
For the new chemical-usage monitoring application, Russell said the EA decided to create a register that maps different terms referring to the same chemical to a global ID number -- a step, nearly finalized, that lets different departments retain their own "domain flavor" on terminology but under a common data definition via the data models. "In the end, the business benefit is there," she said.
Data models don't need to be designed to underpin every data standardization move at the EA, according to Russell. "There are still data standards that can be done alone," she said. "But we're much quicker now to recognize when a data model is required."
