ABSTRACT: Business domains have a range of data & analytics capabilities that enterprise data teams must support.

This is the fourth and final article in a multi-part series on data & analytics operating models. 

In the last article, I outlined the composition of blue and purple teams. Blue refers to the enterprise data team comprised of data & analytics specialists, while purple refers to hybrid teams that develop solutions on behalf of business domains.

This article focuses on the composition of red teams—that is, the data savvy businesspeople who reside in a business domain and who oversee, design, or build solutions for domain colleagues. These solutions are inherently “decentralized” and are likely to create data silos unless there is strong alignment with blue and purple teams. Ironically, red teams, which often form to circumvent backlogs at the enterprise level, often create their own backlogs and need enterprise training and tools to ameliorate them.

Red Team Models

Business domains adopt various approaches to data & analytics. Some domains employ a full-fledged data & analytics team (i.e., data domain team) complete with data engineers, BI developers, and data scientists. Others hire a team of data analysts and a manager to oversee them. A few rely on the enterprise data team to support all their data & analytics needs. (See figure 1.)

Figure 1. Red Team Composition

1. Data Domain Teams. The data mesh methodology has popularized the notion of data domain teams. These are teams of business-savvy technologists (or technically savvy business users) who reside permanently in the business and build data solutions for the business unit. Domain teams have total autonomy to build data products as they see fit. They are the flip side of tiger teams: whereas tiger teams are comprised of enterprise data specialists who report to the chief data officer, domain teams are staffed by local resources who report to business unit heads.

The danger with data domain teams is that they create data silos. This happens if the data domains are given too much autonomy, or the enterprise team fails to establish standards and best practices and educate domain teams about them. To succeed, data domain teams require a strong, enterprise data team that supports, trains, and coordinates data domain teams and builds standards into a centralized data platform that domains use. Domain teams must also participate in enterprise governance initiatives to define common set of metrics and terms used throughout the organization and resolve data quality and consistency issues.

2. Analyst Teams. Embedded data analysts are a tremendous resource for business domains. They are technical generalists and domain experts. They build data solutions that business leaders love and do so quickly and effectively. These leaders don’t have to wait in a queue for an enterprise group to answer their questions. Some departments, such as finance, marketing and sales, have teams of analysts and hire managers (i.e., analytics managers) to oversee them. 

The danger with embedded data analysts, like data domain teams, is that they build solutions willy-nilly without standards. The result is a proliferation of spreadmarts and fragmented data.

To fully harness the potential of embedded data analysts, the enterprise data team needs to establish a program services department (see prior article in this series) that works with domain leaders (or domain analyst managers) to hire, train, and evaluate embedded data analysts and coordinate their activity. This ensures that data analysts build standard, reusable solutions, receive proper training, and benefit from career advancement opportunities.

3. Empty Departments. Some departments, such as legal and human resources, have few if any data resources. Yet, this doesn’t mean they don’t have data needs and requirements. Here, the enterprise team needs to step in and provide all the analytics and development services the department needs until they are ready to establish and fund their own data & analytics capabilities.

The enterprise team needs to assess the requirements of each of these domains. If the need is great enough, the enterprise team might assign a tiger team to the domain to build out core capabilities, such as a departmental dashboard. Or if the need is continuous help answering questions, they might assign an enterprise data analyst to the department, either full-time or part-time or work with the department head to hire an embedded analyst. (Who pays for the analyst is up for discussion.)

Strategic Planning 

The enterprise program services team should work with each business leader to devise a data strategy for their respective business domains or departments. That strategy should document information challenges and requirements for each domain and outline how to address them through a combination of domain and enterprise resources. I’d recommend a three-year strategy.

For example, the strategy for an “empty department” might look something like this:

Year 1 – Create core content 

Desired Solution: Create a core departmental dashboard that consolidates operation data from multiple reports and sources. This will save our staff hundreds of man-hours collecting and preparing data to run the core operations of our unit.

Delivery Provider: Enterprise tiger team will build the solution in six months and train designated internal staff how to maintain and extend it. The tiger team will be on call to support the application for one year.

Year 2 – Develop ad hoc capabilities 

Desired Solution: Hire a data analyst with help from the enterprise data team to address a growing set of ad hoc questions from business managers. 

Delivery Provider: The enterprise team will work with the department head to assign or hire an appropriately skilled data analyst for a two-year rotation. The enterprise team will evaluate and manage the technical output of the analyst, while the department head will guide the analyst’s day-to-day activities. 

Year 3 – Increase departmental data literacy 

Desired Solution: Train interested department users in core analytical techniques and how to use the standard enterprise analytical tool to run simple queries. 

Delivery Provider: The enterprise data literacy team will provide evaluation and training and the department business analyst will provide ongoing coaching and support. 

Obviously, the strategic plan for each data domain team will vary from the plan above, which is tailored to a generic “empty” domain without data & analytics resources. The point is that the three-year plan provides a convenient opportunity for the enterprise data leader to reach out to domain leaders to coordinate activities and align resources. The enterprise data leader (or surrogates in the program services team) should meet annually to set or refresh the data strategy and every quarter to review progress towards achieving the goals. 

Conclusion 

An operating model aligns data & analytics resources across the enterprise. Its goal is to push development as close to the business as possible while maintaining standards that ensure data consistency and alignment throughout the enterprise. In essence, an operating model should provide the benefits of both decentralization (i.e., agility, speed, customization) and centralization (i.e., standards, reuse, efficiency). 

There is no one operating model that is better than another. In fact, every data organization will have its own unique operating model. And each model will incorporate multiple approaches for aligning enterprise and domain resources depending on the capabilities and interests of business domain teams.