ABSTRACT: There are many models for bridging business and technical teams, but each requires careful consideration of team composition and company culture.

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

In the last article, I defined knowledge flows between blue (enterprise), purple (hybrid), and red (business) teams. These flows of information facilitate a federated operational model that delivers the benefits of both centralization (i.e., efficiency and standards) and decentralization (i.e., agility and flexibility) without any downsides. I also outlined six types of purple teams that build effective local solutions while adhering to enterprise standards and best practices.

In this article, I will drill into the composition and dynamics of blue and purple teams. Although there is no right way to organize teams, there are guiding principles that data leaders should follow to ensure proper alignment of data & analytics resources throughout an enterprise. Many data leaders discover that they need to implement multiple federated models to align development and deliver high levels of customer satisfaction.

Many data leaders … implement multiple federated models to align development and deliver high levels of customer satisfaction.

Blue Team Composition 

As I mentioned in the first article, the enterprise data & analytics team is responsible for managing shared data across the organization and delivering strategic or enterprise solutions. It is also a repository of technical experts who train and coach purple teams, establish standards, and help purple teams build technical solutions. As such, an enterprise data & analytics team is comprised of many departments and roles. (See figure 1.)

Figure 1. Composition of an Enterprise Data & Analytics Team

No two blue teams are organized in the same way. However, every data & analytics team needs to support the functions and roles defined above. In small or mid-size companies, some functions are rolled together, such as data architecture and data engineering or business intelligence and analytics. Likewise, a single individual might handle several roles. For instance, a data engineer might handle quality assurance, API development, and dataops monitoring.

At first blush, the enterprise data team is large, perhaps larger than most CEOs and CFOs would like. And the diagram doesn’t include optional departments, such as data governance, master data management, data innovation, and data security, which sometimes report to other areas of the business. It helps to remind business leaders that in a federated operating model many enterprise developers reside in or work exclusively for individual business domains, not a chief data officer intent on empire-building.

Analytics Team. There is always debate about whether data analysts and data scientists should reside centrally or in the business units. It can work either way, as long as there is a central analytics team that establishes best practices and standards and oversees individuals no matter where they’re located. In general, however, data scientists do better centrally, where it’s easier for them to share knowledge, receive training, and rotate domains. Most are academically trained and seek a collaborative environment in which to work. Conversely, data analysts do better in business units where they become steeped in business requirements, processes, and data and can work proactively to solve problems. The key is to federate the roles. If data scientists are centralized, they need to be assigned to a business unit for a minimum of two years; if data analysts are embedded, they need to be coached and managed by an enterprise director of analytics.

The key is to federate the roles.

Data Platform Team. In the last article, we discussed the importance of a data platform to simplify and accelerate the development of data solutions by purple teams. Given the importance of a data platform to federated development, it’s critical that organizations establish a team dedicated to continually improving the enterprise data platform to foster greater levels of self-service. Members of the data platform team should work exclusively on the data platform; they should not be assigned to business projects to help the enterprise team deal with a persistent backlog or a sudden crush of requests. Such a move would delay self-service improvements designed to eliminate the data bottleneck.

it’s critical that organizations establish a team that is dedicated to continually improving the enterprise data platform to foster greater levels of self-service.

Program Services. One department that most data leaders overlook is the program services team. This team’s mission is to coordinate, educate, and align development resources across the enterprise. It does this by overseeing purple teams, ensuring that each has sufficient resources, receives proper training, and builds data products and solutions that adhere to enterprise standards.

The team consists of program managers who oversee the purple teams and their relationships with business customers; one or two managers who help hire, evaluate, and manage embedded data analysts and data scientists; a coordinator who leads the data literacy program and communities of practice, and scrum masters and project managers who facilitate project work. Unfortunately, most organizations don’t have a program services department, which makes it almost impossible for a federated operating model to work effectively.

Most organizations don’t have a program services department, which makes it almost impossible for a federated operating model to work effectively.

Purple Team Configuration

There are multiple ways to construct a purple team. If your organization leans toward a centralized model, then consider using tiger teams, an analytics center of excellence (CoE), or aligned business analysts. If it leans towards a decentralized approach, use data domain teams and embedded data analysts,which we'll discuss in the final article in this series. 

Federated (purple team) models are not exclusive; they usually coexist.

Multiple models. Most companies need to support multiple models to meet varying business needs. For instance, most companies have embedded data analysts no matter what other models they’re using. Many also employ multiple centralized models at the same time (i.e., tiger teams plus an analytics CoE). The same is true for decentralized models: companies with data domain teams also usually have embedded analysts. Federated (purple team) models are not exclusive; they usually coexist.

 Purple Models 

1.Tiger Teams. Also known as SWAT teams, tiger teams are small, cross-functional, cross-trained teams of technical specialists who are permanently assigned to a high-demand business domain and are backed up by a shared services center to fill in technical gaps where needed. (See figure 2.)

Figure 2. Tiger Team Composition

Tiger teams are usually comprised of three members of the enterprise data & analytics team who work full-time on the team and are cross-trained in each other’s area of expertise. Most teams have a data engineer, a BI developer, and a business or technical analyst. Each team works exclusively with a single domain. If the domain requires machine learning models, the team might have a full-time data scientist instead of a BI developer. The teams are supported by a shared services team consisting of data modelers, MLOps developers, and other specialists whose expertise is needed for a part of the project.

It's best if tiger developers spend one or two years in a business domain and then rotate to another domain.

It's best if tiger developers spend one or two years in a business domain and then rotate to another domain. Some may choose to stay in the domain to run data development permanently as part of a data domain team (see below) or assume a business role in the domain, such as product manager. In either case, tiger team members become valuable corporate citizens who develop a great understanding of how to apply technology to address business needs.

2. Analytics Centers of Excellence. Many companies have central teams of data analysts and data scientists who undertake analytics projects requested by business domains or departments. If the center assigns analysts and scientists to specific business domains or functional areas for extended periods, this model works well. If they are generalists responding to any request that comes in regardless of domain, it doesn’t. In the former case, data analysts and data scientists build solutions quickly and effectively and often proactively suggest solutions before the business asks for them. In the latter case, analysts function more as a shared service, which rarely provides high levels of business value or satisfaction.

An analytics center of excellence needs a strong analytics leader who meets regularly with business leaders to understand their strategy and goals and review projects that support those aims. The leader also works closely with data analysts and scientists, training them how to communicate with business managers, frame projects, and present results in a language that business leaders understand. The analytics leader also promotes sharing and collaboration among data analysts and data scientists so they continuously expand their knowledge and skills and become better partners with the business.

3. Aligned Business Analysts. A third way to federate development using centralized resources is to create a team of aligned business analysts. These individuals are intermediaries between business and IT resources who capture business requirements and translate them into technical specifications for a centralized team of developers to build. Although they report centrally, they are assigned to a business domain for a two-year rotation where they attend strategic, tactical, and technical meetings and gain intimate knowledge of the business, players, and processes. The best business analysts work strategically with business leaders in their domain and proactively suggest or prototype technical solutions. They are senior relationship managers, not entry-level people or order-takers.

The best business analysts work strategically with business leaders and proactively suggest or prototype technical solutions; they are not order-takers.

Although many data & analytics leaders profusely extol the benefits of good business analysts, there are limitations to this approach. First, business analysts are translators between business requirements and technical specifications, and something always gets lost in translation. Their existence also means developers are a step removed from the businesspeople they support. Without that direct domain knowledge, developers often don’t optimize solutions or accelerate delivery. And if a business analyst leaves, the domain’s connection to IT is cut, leaving them stranded without adequate support. A better approach is to create a tiger team that includes a business analyst (see option #1 above.)

Conclusion

It pays to think carefully about the composition of your blue (enterprise) and purple (hybrid) data teams. Since most organizations are not entirely centralized or decentralized, data leaders will need to embrace multiple operating models, including decentralized (red) models, which we'll describe in the next article in this series. The choice of models depends on the nature of the business domains and departments. In the next article in this series, I will examine the composition of red teams and how they interact with the purple and blue teams.