Modern data strategy includes cloud, domain federation

A modern data strategy is critical to the successful execution of an analytics program.

David Dadoun, chief data officer at Bombardier Recreational Products (BRP), outlined the dos and don'ts of building a modern data strategy in a session on Sept. 21 during Real Business Intelligence, a virtual conference hosted by Dresner Advisory Services,

Dadoun joined BRP, a Canada-based maker of snowmobiles, jet skis and other recreational vehicles, just six months ago.

Upon his hiring, he was tasked with overhauling the enterprise's analytics operations. Before taking any steps to modernize BRP's data strategy, however, he conducted meetings with almost 80 different data employees in both local and international offices to find out as much as he could about BRP's existing analytics operations and what changes he might accomplish.

He then tailored BRP's data strategy based on what he discovered. Any organization needs to tailor its data strategy to its individual needs, he emphasized.

But there are general best practices, beginning with a cloud-based data platform. On top of that, however, is implementing what he termed a domain federated data strategy.

Domain federation is a strategy that centralizes the architecture, governance and security of an organization's data operations but creates flexibility beyond that centralization by establishing domain teams. Those teams then develop data assets that enable knowledge workers across multiple departments to access and use data to drive the decision-making process.

"In domain federation, we look at eliminating bottlenecks, scaling our ability to deliver value across data products, those products are interoperable, and the fact that those products are interoperable creates a network effect that drives the value of data," Dadoun said.

Typically, organizations have developed either centralized, decentralized or federated data strategies, according to Dadoun.

In domain federation, we look at eliminating bottlenecks, scaling our ability to deliver value across data products, those products are interoperable, and the fact that those products are interoperable creates a network effect that drives the value of data.

A centralized data strategy puts a single data team in charge of all data-related matters, meaning that regardless of whether an analytics project is for the human resources department or finance department, among others, the data team undertakes the project and turns over a finished product when it's done.

Advantages of a centralized strategy include a guarantee that best practices will be enforced and a common data architecture for all projects. Cons, however, include the loss of business proximity to the project, bureaucracy and an inflexible structure.

A decentralized data strategy, meanwhile, gives each department its own data team with those teams reporting to department heads rather than a chief data or chief analytics officer. Advantages are proximity to the business -- the data teams and data consumers work closely together -- and flexibility, but disadvantages include the absence of common standards and development of data silos.

Finally, a federated data strategy is a hybrid of centralized and decentralized, with departments maintaining their own data teams but working under the guidance of an overseeing data team with an executive-level presence.

A federated data strategy takes the best of both centralized and decentralized data strategies, including standardized governance measures and other best practices and closeness to the consumer side of the business.

"Typically, what we see over time is organizations go from heavily decentralized when they start with their data initiatives to trying the centralized model to then heading down to a federated approach," Dadoun said. "But something is still missing, and it's the fact that companies still think monolithically."

That monolithic thinking harks back to a single data warehouse or data lake, a single reporting platform and single teams building all the reports and feeding the data platform, he continued.

"That's not the best approach," Dadoun said. "It can be better if we start to take a domain-driven approach."

Data domains are groupings of specific data elements that can serve the needs of multiple departments or business teams, and domain federation builds a data strategy around the domains rather than the needs of individual departments, according to Dadoun.

The fundamental blocks of domain federation are the data domains themselves, a cloud-based data platform, a data catalog that makes data easily discoverable, and data interoperability that includes strong data governance and common standards and architecture.

Similar to a federated model, the establishment of those fundamental blocks is the responsibility of organizational data leaders.

But unlike a federated model, working under the organizational leaders are domain teams rather than data teams dedicated to the needs of single departments. They do the work of ingesting the data, transforming it and building the reports and dashboards that drive the decision-making process.

Knowledge workers can then access and use the products created by domain teams to do ad-hoc queries, create their own models and do their own analysis.

The result is a network effect, and the ability for end users to create their own data ecosystems using cleaned and governed data.

"Ultimately, we want to permeate the knowledge and the usage of data, and [knowledge workers] are going to come across those domains and access the data that is naturally interoperable across the different domain teams," Dadoun said.

None of that, he added, can be accomplished without a modern data platform.

"You can't accomplish this with your grandfather's data warehouse," Dadoun said. "This new platform needs to be a platform for data and not just a warehouse versus a lake. We need a domain-driven architecture. We do this because we want to drive innovation. This is different than how IT has managed data in the past."