Data Product Mapping 2.0

Establishing the Necessary Connectivity and Detailed Design Across the Various Levels of Data Product Maps

A few weeks ago, my colleague, John Apathy, wrote a blog about mapping data products to business value that helps unlock the XponentL value of data. He described an approach for strategy mapping and its direct translation to data products, outlining the benefits of mapping data products to high-value business drivers and the profound effects it will have on an enterprise.

In addition to mapping to value drivers, he explained the importance of aligning data products to specific use cases and how it is critical for developing a widely utilized and useful data product. By doing so, businesses ensure their data products are serving users and consumers. If you have not had a chance to check out John’s article, I recommend you read it here.

Now that we have a general base of how and why we should map data products, I would like to introduce XponentL’s concept of Data Product Mapping Levels. We have established a framework outlining three levels: Level 0, Level 1, and Level 2 mapping. Each of these levels of data product mapping serves as a steppingstone in the creation of an effective data product. Conceptualizing these levels is to think of the Level 0 view as the ‘30,000-foot view’, where enterprise business value and goals are considered. The next level view, or the Level 1 view, is the ‘10,000-foot view’, where you focus on a specific business domain within the enterprise, the value drivers and use cases that are supported by the enterprise and domain-bounded data products. And finally, the Level 2 view as the ‘1,000- foot view – prepare for landing’, where an individual data product is mapped, readying it for design and build, and where its deployment plan is created.

Level 0 – The Enterprise View

The enterprise view is all about establishing a high-level view and context for value creation within the business. It starts by evaluating company goals and value-drivers that Data Products enable and help to achieve. From there, the business units or domains are aligned to the value-drivers. Furthermore, the use- cases within each domain that support the value drivers are identified and mapped to value-drivers, establishing the connected ecosystem that connect data use cases to higher-level business goals and objectives.

The target audience of a Level 0 map are strategic decision makers and senior executives within an enterprise. It is primarily used to gain consensus and common understanding across stakeholders during the strategy phase of data product planning and should align to the highest priorities of an organization. This allows the organization to have value anchors for data product planning and enterprise-wide leadership input.

Three swim lanes are present in the Level 0 view: Business Value Drivers, Business Domains, and Use Cases. An understanding of the relationship and dependencies between value drivers, business domains, and use cases are the key outputs from this level of mapping. From here, the next development is to outline a specific domain within the enterprise to focus on Level 1 Mapping.

Below is an example of a Level 0 map from a Cell and Gene Therapy data product.

Level 1 – The Business Domain View

Now that a business domain is chosen as a priority for business value creation from the result of the Level 0 map, it’s time to get domain specific. First, however, let’s note that it is important to recognize that many data products are cross- domain within an enterprise – and that is okay! We can quickly replicate the mapping of data products that are cross-domain in each of their respective business domain-specific Level 1 data product maps. This is where efficiency and yield come from the investment in enterprise-wide data products.

The Business Domain View is all about laying the foundation from Data Source(s) to Core Product(s), to Derived Product(s), and continuing to layer them into use cases and value drivers. This process goes one step deeper toward the connected ecosystem of the business domain’s collection of data products, but also initiates the planning of lineage and integration from sources and incremental data products that deliver data and insight for specific use cases.

Functional line business leaders, process owners, line managers, and functional data teams are all possible contributors and consumers of the Level 1 map. Generally, it is best to create these views early in the Project Brainstorming phase as it aligns the specific data products within the domain to both technical requirements (sources) and organizational support (data product ownership, governance, use cases and business value drivers). The data ecosystem within the domain is represented and will show the lineage between source to business needs. Business and technical stakeholders can take active part in the discussion around Level 1 mapping as it is sufficiently high-level within the respective business domain and its organizational context should be clear to all participants.

There are 5 swim lanes on the Level 1 Data Product map: Value Drivers, Use Cases, Derived Data Products, Core Data Products, and Transactional Data Sources. Upon completing this level of data product mapping there should be clear identification and prioritization of data products that need to be built, re- purposed, and used within each specific use case for a given business domain- bounded value driver.

Below is an example of a Level 1 map from a Cell and Gene Therapy data product.

Level 2 – The Data Product View

Level 2 mapping focuses the team on laying out the principles and design specifications for a data product, whether it is core or derived. It helps to answer detailed questions like:

• Why do we need it?

• What are the data/system sources?

• Who will it serve?

• Who will be the business champions?

• Who will be the data product owner?

Laying this knowledge about a data product out on a canvas facilitates collaboration between data product owners and technical data engineers. It should be used to paint the canvas for what must be done to build the Data Product, but also why it must be done. Throughout this mapping, maintaining connectivity to organizational goals and value drivers will be paramount, and despite Level 2 being a more technical step in the process, the over-arching goal is to support the build of a data product that will help to achieve a high-level business priority and/or value-driver.

With that, data product enablement teams are the core audience for Level 2 Maps, and these typically align to a Data Product Operating Model that involves: data product owners, data product managers, data stewards, data analysts, metadata leads, data engineers, data scientists, and business consumers of the data product. It is used during the design phase of the lifecycle, where in-depth business analysis, process optimization, and operational planning are considered before a Data Product is created. In following an agile lifecycle, it would be suitable to align to formal team ceremonies and backlog creation as this will facilitate moving from a typical project-oriented approach to a continuous lifecycle management approach to data products. Level 2 is the lowest level of granularity, so specific build out requirements and details for a given core or derived data product must be outlined for efficient product construction and use.

We have constructed eight sections within the Level 2 map:

• Problem Identification,

• Data Product Identification,

• Data Sources and Other Data Products,

• Hypothesis,

• Use Cases & Value Drivers,

• Solution Options,

• Key Actors within the Operating Model, and,

• Key Actions.

After going through the exercise of creating a Level 2 map, a Minimal Viable Data Product (MVDP) or prototype build of the data product should follow.

Below is a genericized template of a Level 2 map for a data product.

Still unsure as to why and how to Map Data Product Levels?

The creative process for an effective Data Product from ideation to Minimal Viable Data Product prototype can be a challenge. It involves a diverse set of inputs and brings together cross-disciplined groups of people from across the enterprise who may never collaborate in this fashion.

XponentL’s Data Product Mapping Framework kickstarts the process and outlines the necessary steps to achieving maturity with data products within the organization. We have demonstrated how this framework can help to address constraints and issues such as: the lack of business sponsorship, the lack of business funding, unclear connectivity to enterprise business goals, objectives, and priorities, or simply the unknown factor of “where to get started”.

We invite you to explore how XponentL’s Data Product Mapping Framework can enable your organization’s efforts to modernize your data architecture and set you on the path toward efficient Data Product creation.

I would love to hear from you on your success with Data Product mapping, or truly, any other topic. Contact me if you would like to talk about how our approach to Mapping Data Products can add value to your data driven organization (sean.fenoff@xponentl.ai).

A Note of Recognition and Thanks:

I would like to give a quick shout out to Kathryn Reda for her creativity and structured help surrounding the Data Product Mapping Framework. Kathryn is in England to study (and drink tea, I suppose) at Oxford this fall to complete her master’s degree in pharmacology... and we miss her already!