When the Navy SEALS embraced its motto, “Slow is smooth, and smooth is fast,” they may as well have been discussing building data models in the same breath. The SEALS chose the phrase to remind its participants not to rush but to act thoughtfully and deliberately. Data Modeling does the same thing by helping businesses design and update data architectures intentionally.

Using the data representations produced by Data Modeling, business teams communicate system requirements and solve design problems before jumping into coding. But top executive managers do not have the patience to wait for a data schema in a volatile economy. Instead, they want everyone to move faster with data and processes, now! How can Data Modeling adapt to these conditions by providing thoughtful and timely information without becoming irrelevant?

At DATAVERSITY’s Enterprise Data World (EDW) panel “Modern Data Modeling Issues and Challenges,” participants shared first-hand experiences with Data Modeling and how it continues to change the data industry.

The following experts spoke:

• John O’Brien: a principal adviser and CEO of Radiant Advisors
• Donna Burbank: Managing director of Global Data Strategy
• Karen Lopez: Senior project manager and architect at InfoAdvisors
• Pascal Desmarets: Founder and CEO of Hackolade

All four discussed Data Modeling issues and challenges, both now and in the future. 

Data Modeling Continues to Grow

For those who think that Data Modeling cannot keep up with the speed of business, Donna Burbank begged to differ: “Data Modeling has not gone anywhere and only continues to grow,” she said. 

This theme echoed throughout the panelists’ comments. Data Modeling continues to grow because of the following:

• Increases in Data Architecture Complexity: Karen Lopez noted the difficulty of remembering thousands of database systems. She said, “I can’t keep track of their products and services, let alone the features inside them.” Pascal Desmarets expanded this idea into polyglot persistence, where “organizations store the same data in different types of technologies.” Furthermore, “companies must pull and integrate data from pre-existing systems to meet their other needs,” said John O’Brien. This increasing complexity means that organizations need to update existing data models.

• Increases in Data Modeling Self-Service Options: Data consumers have more choices, especially in data preparation, according to O’Brien. Consequently, businesspeople and the public have tools to build and engage in “interactive data visualizations,” noted Lopez. Burbank agreed: She sees the self-service improvement as encouraging everyone to get in on Data Modeling, including small museums, nonprofits, and health care organizations. Better self-service means more people are modeling.

• Compliance with Privacy and Data Regulations: Even if companies never initially planned to do Data Modeling, they must do so upon releasing their data products for compliance. Desmarets mentioned that teams go back and reverse-engineer data applications to ensure they meet data regulations, like the European General Data Protection Regulation (GDPR).

Data Modeling Represents Business Understanding

Data Modeling transcends technologies like JSON files: “Data Modeling represents your understanding of the business,” said O’Brien.

JSON And Business Comprehension

Look at a company’s JSON files and determine how well developers understand the business.

Companies use the JSON language “to structure data in a self-describing way. But how you describe it impacts the quality and efficiency of how data gets stored,” said Desmarets.

JSON tempts companies with its ease of capturing and transmitting data. Just modify the JSON for delivery by opening the correct file and changing its key-value strings in the code. 

These fast JSON updates strongly express themselves through altered business requirements, however, so they can potentially cause headaches downstream, O’Brien warned. The internal customers unpack the JSON data product received and see volatile and unpredictable results if business requirements remain unclear.

To prevent these issues upfront, Burbank encourages companies to agree on a common language to depict the data stored in the JSON. “Organizations better understand what they do when teams bridge the technical and business data structures,” Burbank observed. 

Using DataOps to Deepen Business Understanding

Lopez takes the idea of agreeing on a common language one step further. Her Data Modeling deals with integrations transporting data in various ways, e.g., XML, JSON, common delimited files, and parquet. She notices that the problems and lessons learned from engineers rushing in one language format are rehashed when they switch to a different one.

She says, “People give each clump of code a name. However, teams don’t know what that clump means without guidance.” Fortunately, some DataOps tools and processes assist organizations in defining what different globs of code do. 

DataOps uses models to help companies develop and deliver analytics effectively. However, doing so requires more than just a few database administrators (DBAs) who manage databases.

Also, DataOps needs businesspeople. Lopez thinks getting her “data professional peers involved in setting up, defining, and participating in DataOps” will lead them to work with IT and to better data schemas, no matter what the programming language.

Embracing a Rapid Evolution of Applications

Desmarets emphasized that data modelers and their tools must support the rapid evolution of applications generated by organizations. Other panelists also backed this need for more agile Data Modeling. 

Unfortunately, as O’Brien noted, “an old perception has materialized that Data Modeling takes forever and requires too much analysis.” However, this stereotype does not gel with the incremental approach businesses need when developing data products. 

Organizations must refactor their data requirements and structures as they go. Desmarets added that migration to the cloud and rapid application alterations press Data Modeling to support all this change.

To keep up with rapid evolution, the panelists suggested the following:

• Metadata as code: Automating metadata, the information about the data, helps bridge the technical and business definitions quicker. Desmarets thinks firms can see how to use, interpret, and process their data by using metadata coded in a data platform.
• Tools improvements: Burbank sees that PowerPoint and online whiteboarding or Meri boards have translated business needs better. PowerPoint allows users to convey Data Modeling at a high conceptual level, while visual whiteboarding digitization keeps the business focus lighter, where it can take on more iterations and react more. However, as Burbank noted, “We need faster, better, and different tools to explain data architectures between business units.”
• Model-driven database design: Lopez encourages data modelers to embrace model-driven data design for agility and as part of DevOps. In this methodology, data modelers handle all the design’s constraints, rules, and other requirements. “Teams get the Data Quality for which they planned and a defined state construct used to measure against the developer’s implementation,” said Lopez.
• Semantic/abstraction layers that separate data models from usage: Going faster requires representing technical code correctly, as O’Brien highlights. Having better intuitive tools that distinguish data models within their data platforms promises to get there through shared technical and business understanding faster.

Conclusion: Love Your Data

To go smoother and faster with Data Modeling, Lopez recommends that you “love your data.” Users love their data when they find it helpful and valuable, having sufficient Data Quality.

Lopez sees organizations taking on a more significant investment in Data Quality because anyone can jump in and model their data without the involvement of a DBA. This kind of self-sufficiency, as O’Brien observed, makes Data Modeling tangible and relevant to understanding the business.

For Desmarets, loving your data requires agile Data Modeling. He sees that modern data modelers probably work from an existing Data Architecture schema in production and stand removed from initial database choices. So, getting the Data Quality needed to love your data means taking what exists and ensuring it is compliant, through Data Modeling, after the next iteration.

Due to changing business demands, Burbank sees technical changes as companies pull and integrate from existing data architectures and re-represent it for another purpose. In this process, there needs to be enough cross-pollination between business units to model the company’s data conceptually and represent it in the code.

To love their data, companies need a common language that businesses and developers can use to iterate on existing data structures. This language comes from bridging business and technology by exchanging Data Architecture ideas.

To love their data, companies must take a deliberative, iterative approach, using data models to guide the way. This tactic would leave the Navy SEALS impressed.

Want to learn more about DATAVERSITY’s upcoming events? Check out our current lineup of online and face-to-face conferences here.

Here is a video of the Enterprise Data World presentation:

Image used under license from Shutterstock.com