Data domains represent categorised collections of data that relate to specific business areas or functions. Suhas Jangoan MBCS explores them conceptually and provides concrete examples of where they can be deployed.

In today's data-driven world, effectively managing, utilising, and governing data is paramount for any organisation aspiring to leverage actionable insights and analytics. Data domains are essential building blocks that form the foundation of a clear data strategy, setting the limits and structure of how data is grouped and managed. In this article, I will explore the concept of data domains and provide a concrete example involving data from disparate data sources to show how one might define and utilize these domains for a successful data architecture.

What are data domains?

Data domains represent categorised collections of data that relate to specific business areas or functions. By defining data domains, organisations can:

  • Enhance data governance and quality
  • Streamline data management processes
  • Improve understanding and communication across business and IT stakeholders
  • Foster a common language within the entire data ecosystem

Within the article, diagrams illustrate data domain strategies:

  • Containers: these group related systems or domains
  • Arrows: represent the dataflow and integration

Acronyms explained

  • ETL: Extract, Transform, Load
  • SaaS: Software as a Service

Now let us look into an example involving sales and marketing data sources with three distinct approaches to creating data domains.

Use case: ecommerce ( customer journey analytics platform

In this scenario, an e-commerce company seeks to integrate disparate data sources to understand and optimise the customer journey comprehensively. The data originates from various systems, including the e-commerce platform ( , customer service software (Zendesk), marketing automation tools (Marketo, Acquia), SaaS systems (Salesforce) and web analytics (Google Search).

The objective is to create a customer journey analytics platform that delivers a holistic view of customer interactions across various touchpoints, from e-commerce activities, such as transaction history and cart management, to customer support engagements, marketing activities and website behaviors. The platform will also enable the reverse ETL process to repopulate operational systems with transformed data for refined marketing and enhanced customer support.

This use case emphasises high-level data domain definition and structuring considerations, rather than the specifics of data transformation or dashboard creation.

Approach one: separate data domains for each source and destination system

In this approach, the e-commerce company establishes individual data domains for each distinct system that contributes to the customer journey analytics. Data is ingested, transformed and exported within the company’s respective domains:

  • Zendesk: dedicated to support-related data such as tickets, chat logs and customer feedback
  • Marketo: handles data from marketing campaigns, email interactions, and other engagement metrics
  • Acquia: a separate domain for data generated by Acquia's marketing systems
  • Salesforce: focuses on customer relationship management data from Salesforce
  • Oracle: manages enterprise resource planning data, including financials, supply chain, and inventory data from NetSuite
  • Google analytics: tracks online behavior data, such as page views, and conversion funnels

Organisations adopting this strategy prioritise data governance, enforcing strict control and specialised domains, especially in regulated industries or where distinct data separation is critical. This ensures high-quality, well-managed data but can complicate integration and slow adaptability as data sources proliferate, potentially escalating costs and delays in new data projects.

Approach two: centralized customer journey platform domain with source subdomains, analytical and reverse ETL domains

In this approach, the e-commerce company establishes a central platform that aggregates customer data from various touchpoints, with focused domains for analysis and operational use. Data is ingested into a single central domain, where it is standardised, transformed and then integrated with target systems for analytics and export across distinct domains:

  • Central customer journey: this main domain serves as the hub for all customer interaction data, integrating data from all sources to create a comprehensive view of the customer journey
  • Analytics: combines the roles of deriving deep insights and producing actionable reports. It is equipped with tools for data analysis, visualisation, and reporting to support data driven decision making across the company
  • Reverse ETL: responsible for the flow of processed data back into the operational systems. It manages the reverse ETL tasks, ensuring that the enriched data is effectively utilised to refine marketing campaigns

Organisations that adopt this approach typically prioritise a holistic view of customer data and seek to streamline their data management processes. By centralising data from various systems into a single platform, these organisations aim to break down silos and foster a comprehensive understanding of the customer journey.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

This unified approach facilitates integrated data governance and consistent application of quality standards, making it easier to manage and derive insights from customer interactions across different touchpoints. While this approach simplifies the data architecture and enhances operational efficiency, it may require robust data integration capabilities and a strong commitment to maintaining a centralied data repository. The centralisation of data can also necessitate careful planning to ensure scalability and performance as data volumes grow.

Approach three: business-centric domains based on functional areas

In this approach, the e-commerce company creates separate data domains that align with key business functions such as sales, marketing, customer and finance. Each domain is tailored to the specific data needs and operational processes of its respective business area. The data is ingested into the corresponding business domains, where it is transformed and integrated with target systems for analytics and export within those same business areas:

  • Sales: manages sales-related data, potentially from systems like Salesforce and NetSuite, focusing on lead management, customer acquisition, and revenue tracking
  • Reverse ETL: handles marketing data from tools like Marketo and Acquia, concentrating on campaign performance, customer engagement, and lead nurturing
  • Customer: dedicated to customer support data from platforms like Zendesk, emphasising issue resolution, customer satisfaction, and service analytics
  • Finance: oversees financial data, which may include transactional information from the e-commerce platform and financial reporting from NetSuite, addressing billing, cost analysis, and financial health

Organisations that implement this approach often have a decentralised structure with distinct business units that operate independently. This model supports a high degree of specialisation, allowing each department to manage and utilise data in a way that directly supports its specific goals and activities.

It can empower business units to react quickly to changes and tailor their data practices to their unique requirements. However, this approach may lead to challenges in achieving a unified view of the customer journey and require additional efforts to ensure data consistency and integration across the organisation. While it promotes agility and responsiveness within individual units, approach three can also necessitate sophisticated coordination to align data-driven strategies at the enterprise level.

Governance and structuring decisions

The responsibility for defining data domains generally falls upon a cross-functional team, involving:

  • Data architects who provide the blueprint for the overall data structure
  • A data governance team who enforce policies and standards for data usage and quality
  • Data engineers who implement and maintain the technical infrastructure
  • Business analysts and stakeholders who contribute an understanding of business needs and operational context

Conclusion: finding the best way to organise data

To wrap up, how an organisation sets up its data domains is a big choice that can really change how well it understands and uses data. We've looked at different ways to do this, and each one works well for different kinds of companies. Some companies might keep their data in separate domains because it gives them more control. Others might put all their data together in one place to make things simpler and to get a full picture of what their data provides. The best plan is the one that fits what your company needs and what you want to do in the future.

Remember, as your company grows and changes, the way you handle your data might need to change too. The goal is to always have a data setup that helps your company understand your data better and react to new chances in the market.