10-Step Methodology to Creating a Single View of your Business: Part 1

Organizations have long seen the value in aggregating data from multiple systems into a single, holistic, real-time representation of a business entity. That entity is often a customer. But the benefits of a single view in enhancing business visibility and operational intelligence can apply equally to other business contexts. Think products, supply chains, industrial machinery, cities, financial asset classes, and many more.

However, for many organizations, delivering a single view to the business has been elusive, impeded by a combination of technology and governance limitations. In this 3 part blog series, we will explore what it takes to successfully deliver a single view project:

• In Part 1 today, we will review the business drivers behind single view projects, introduce a proven and repeatable 10-step methodology to creating the single view, and discuss the initial “Discovery” stage of the project
• In Part 2, we dive deeper into the methodology by looking at the development and deployment phases of the project
• In Part 3, we wrap up with the single view maturity model, look at required database capabilities to support the single view, and present a selection of case studies.

If you want to get started right now, download the complete 10-Step Methodology to Creating a Single View whitepaper. MongoDB has been used in many single view projects across enterprises of all sizes and industries. This whitepaper shares the best practices we have observed and institutionalized over the years. It provides a step-by-step guide to the methodology, governance, and tools essential to successfully delivering a single view project.

Why Single View? Why Now?

Today’s modern enterprise is data-driven. How quickly an organization can access and act upon information is a key competitive advantage. So how does a single view of data help? Most organizations have a complicated process for managing their data. It usually involves multiple data sources of variable structure, ingestion and transformation, loading into an operational database, and supporting the business applications that need the data. Often there are also analytics, BI, and reporting that require access to the data, potentially from a separate data warehouse or data lake. Additionally, all of these layers need to comply with security protocols, information governance standards, and other operational requirements.

Inevitably, information ends up stranded in silos. Often systems are built to handle the requirements of the moment, rather than carefully designed to integrate into the existing application estate, or a particular service requires additional attributes to support new functionality. Additionally, new data sources are accumulated due to business mergers and acquisitions. All of a sudden information on a business entity, such as a customer, is in a dozen different and disconnected places.

Figure 1: Sample of single view use cases

Single view is relevant to any industry and domain as it addresses the generic problem of managing disconnected and duplicate data. Specifically, a single view solution does the following:

• Gathers and organizes data from multiple, disconnected sources;
• Aggregates information into a standardized format and joint information model;
• Provides holistic views for connected applications or services, across any digital channel;
• Serves as a foundation for analytics – for example, customer cross-sell, upsell, and churn risk.

Figure 2: High-level architecture of single view platform

Introducing the 10 Step Methodology to Delivering a Single View

From scoping to development to operationalization, a successful single view project is founded on a structured approach to solution delivery. In this section of the blog series, we identify a repeatable, 10-step methodology and tool chain that can move an enterprise from its current state of siloed data into a real-time single view that improves business visibility.

Figure 3: 10-step methodology to deliver a single view

The timescale for each step shown in the methodology is highly project-dependent, governed by such factors as:

• The number of data sources to merge;
• The number of consuming systems to modify;
• The complexity of access patterns querying the single view.

MongoDB’s consulting engineers can assist in estimating project timescales based on the factors above.

Step 1: Define Project Scope & Sponsorship

Building a single view can involve a multitude of different systems, stakeholders, and, business goals. For example, creating a single customer view potentially entails extracting data from numerous front and back office applications, operational processes, and partner systems. From here, it is aggregated to serve everyone from sales and marketing, to call centers and technical support, to finance, product development, and more. While it’s perfectly reasonable to define a future-state vision for all customer data to be presented in a single view, it is rarely practical in the first phase of the project.

Instead, the project scope should initially focus on addressing a specific business requirement, measured against clearly defined success metrics. For example, phase 1 of the customer single view might be concentrated on reducing call center time-to-resolution by consolidating the last three months of customer interactions across the organization’s web, mobile, and social channels. By limiting the initial scope of the single view project, precise system boundaries and business goals can be defined, and department stakeholders identified.

With the scope defined, project sponsors can be appointed. It is important that both the business and technical sides of the organization are represented, and that the appointees have the authority to allocate both resources and credibility to the project. Returning to our customer single view example above, the head of Customer Services should represent the business, partnered with the head of Customer Support Systems.

Step 2: Identify Data Consumers

This is the first in a series of iterative steps that will ultimately define the single view data model. In this stage, the future consumers of the single view need to share:

• How their current business processes operate, including the types of queries they execute as part of their day-to-day responsibilities, and the required Service Level Agreements (SLAs);
• The specific data (i.e., the attributes) they need to access;
• The sources from which the required data is currently extracted.

Step 3: Identify Data Producers

Using the outputs from Step 2, the project team needs to identify the applications that generate the source data, along with the business and technical owners of the applications, and their associated databases. It is important to understand whether the source application is serving operational or analytical applications. This information will be used later in the project design to guide selection of the appropriate data extract and load strategies.

Wrapping Up Part 1

That wraps up the first part of our 3-part blog series. In Part 2, we will dive deeper into the Develop and Deploy phases of the single view methodology. Remember, if you want to get started right now, download the complete 10-Step Methodology to Creating a Single View whitepaper

Download now