A Familiar But ‘New’ Way of Analytics Development

Free photo by Markus Winkle from https://unsplash.com/

The Data, Solutions & Analytics (DSnA) team supports business teams within T-Mobile’s Procurement & Network Supply Chain (P&NSC) and Regional Network Engineering & Operations (RNE&O) organizations. These teams are responsible for billions of dollars in spend, thousands of units of material flow through the supply chain and thousands of successful network development projects executed every year. Organizations of such impact need critical, timely and reliable analytic insights to support business decisions. DSnA has transformed itself into a hybrid technology team with full stack development capabilities; from data engineering to software development to data science and analytics development. Centralized data across hundreds of sources is the foundation of our value proposition.

‘Analytics Development’ is the process used to create and refine business intelligence (BI) and advance analytics (machine learning & AI) products and solutions that support our functional teams. These activities are inherently business context specific. Unlike typical software development, analytics development requires engineers to have deep business process and logic understanding. DSnA has created a familiar but ‘new’ way of organizing our teams for effective and impactful analytics delivery.

Before we get into more details, let’s look at some reasons for this shift first.

• Vertically aligned (to business teams) analytics teams often find it difficult to eliminate redundancy and overlap, with similar products and functionality being developed across multiple teams.
• Engineering managers end up wearing more hats than should be acceptable for efficient delivery — for example, she has to manage the external stakeholders, hash out requirements, manage engineers and development activities, manage internal and external communications, enhance technical capabilities of her team, sustain existing products and manage delivery.
• Frequent external facing activities like meetings, brainstorming sessions, stakeholder walk-by and ad-hoc requests provide disruptive distraction to our engineers
• Technical competencies and best practices are hard to maintain across engineering teams that reside within the business unit.

Structure of Our Technology Team

There are multiple ways to organize a technology team and DSnA choose to adapt a ‘Federated or Hybrid’ model. In this model, DSnA has different engineering teams organized by competencies with a product team providing focus and alignment. Business units retain a team of analysts responsible for operational analytics. DSnA focuses on foundational high impact things like centralizing data, harvesting business logic to the core data model and building advanced analytics and solutions. The team’s goal centers around analytic enablement, knowing that insights will be most efficiently developed within the business unit

Traditionally, product management is highly efficient in the software solutions space. We applied this model to any development work happening in DSnA, be it software, analytics & BI, data science or data engineering — product team provides the vision and focus of investments; engineering teams execute on the strategy to provide our BUs the solutions they need for data driven business decisions.

Figure 1 — DSnA Federated Model

Execution Framework for Analytics Development

There are two key components of our execution framework:

1. Analytics Delivery Team Supported by the Product Team

• The product team provides the product vision and road-map to the Engineering (or delivery) team. Technical Product Managers (TPM) maintain close relationships with BU stakeholders (analysts and others), understand their pain points, have an eye on BU’s maturity for data driven decision making. These insights, coupled with the strategy provided by senior leadership, determine the right investment areas for DSnA’s resources. Each TPM supports a BU and maintains a rolling 12 months road-map including new and existing products (these could be web Apps, reports, dashboards, data products etc.).
• TPMs are supported by Functional Analysts (FA) who are also aligned to a BU. FAs understand the business process, including the systems used for day to day operations. They are critical in translating business requirements into meaningful work for our engineering teams.
• Engineers, with support from the Engineering Manager, execute against the road-map. They are critical to the quality and sustainability of the products we create. Engineering Managers ensure high technical standards and best practices within their teams.

2. Analytics Delivery Accelerated by Agile

• The development of the analytics products is done via agile. 2-week sprints with typical agile events like grooming and planning sessions (led by TPMs), daily stand ups (led by engineers) and retrospective (led by the Engineering team) help facilitate execution on the road-map.
• This framework is not atypical in the software development world but developing analytics (for example, Power BI dashboards, Analytics Web Apps and ML models) in this framework is unique. Analytics work is iterative by nature, and this agile framework really helps organize the delivery and provide focus to Analytics Engineers.

Here’s how the relationships play out across different roles in this framework:

Figure 2 — Relationships Map

The size of the edge between nodes shows the magnitude of engagement and edges are bi-directional. It could be viewed as relationship magnitude of 1 (thin edge) — stay connected & keep informed, 5 (medium width edge) — periodic touch points, and 10 (thick edge) — frequent touch points and work closely together. The following matrix further expands on this map.

Figure 3 — DSnA Analytics Development Relationship Matrix

Key Benefits

Everything Thing Goes Through the Product Lens

Product Manager is the primary point of contact for stakeholder engagements creating a simple customer experience that supports the long-term growth of the team. They drive prioritization for development activities through a high-level road-map translated into tactical user stories. This ensures minimal redundancy within the technical team and analytic work that follows a coherent narrative for each vertical. Every request doesn’t end up as a new dashboard and the team understands why this work is important before development commences. This product focus ensures that we go after the right problems, create meaningful solutions and keep those solutions relevant as business process changes.

Alignment with Other Products

Another key benefit of a Product Manager is the visibility they have across all existing and in-development products within the team. She can collaborate with other product managers to ensure the right home for a business problem (whichever product it resides in; not necessarily in her own products). For example, if a BI Development team is aligned with a vertical, every request will end up in a report or dashboard. A product team facilitating the engagement ensures that the right solution is considered, regardless of past technical work. BU stakeholders, at the end of the day, do not care how their problems are solved, they care for results.

Engineering Manager’s Responsibilities

This framework frees the Engineering Manager from a range of external facing responsibilities and allows her to focus on the development process and quality of delivery. Managing requirements gathering, external and internal communications, development process, product quality and people management responsibilities is daunting and not scalable as the team grows.

Engineer’s Enhanced Focus

Anyone who has been an engineer or has worked with one knows that development activities require undistracted focus. In a vertically aligned Engineering team, being part of the full cycle of activities takes up a lot of an engineer’s time. Our model puts the ‘problem definition’ responsibility on the product & analysis team and when the tasks come to the engineer, they are refined, and allowing her to focus on innovative ways to solve the problem at hand.

Example — Procurement Analytics Cube

Figure 4 — Overall Procurement Analytics Cube Solution

The best way to explain this model of analytics development is with an example. Spend, as with any Procurement organization, is foundational for sourcing, negotiation & category strategy work. In early 2019, state of our solution for spend analytics was bound within the confines of the eSourcing & Procurement-to-Pay (P2P) tool. Accessing spend reports (no visualizations, only raw data), was not intuitive. Once found in the tool, building the needed report was ‘mission impossible’. Data was loaded into this tool on a monthly basis manually using files downloaded from our ERP system (you heard that right — manual, file based and monthly refresh). For an organization managing billions of dollars in spend, this was not a workable solution.

An immediate response to this solution might have been to build a few pipelines that land this spend data in the data warehouse, throw a pretty Power BI dashboard on top and call it done! We did not limit ourselves in that way. The Product Manager was able to peel the layers of the problem and understand that dashboards will only answer first few layers of business questions even though Sourcing Managers had frequent need to build their own analysis and access transactional data. Furthermore, the raw spend data was missing some key attributes like spend categorization and supplier master normalization (multiple legit records for same supplier). Without these enrichments, the impact of making this data available would not be complete.

• After a year of product management and innovative development, our current spend solution looks much different: We have automated daily data extracts. A huge improvement from the manual monthly extracts of the past.
• The data engineers have leveraged a full domain model built a tabular format in Azure Analysis Service with all enrichments and key metrics baked in. This serves as the backbone of the self-service solution we offer our end users.
• A couple of Power BI dashboards provide answers to key business questions in under 5 clicks.
• Our data science team built models to classify spend transactions and normalize supplier names. This aligns our output with long-term procurement category strategy. And we’re actively building an automated way of collecting feedback on our models to better train them over time.
• A 3rd party self-service solution is currently being implemented to leverage Natural Language Query and let users ask any question from the spend data while at the same time, extract any transactional data they need.
• To bring it all together, the Power BI dashboards, Web Apps and Self-Service Solution will all be embedded within an existing Procurement Web App that already provides a lot of procurement insights in a single place.

This solution is miles away from what a single Analytics Team aligned directly to the BU might have been able to achieve. It exemplifies the strengths of all technical teams in DSnA (data engineering, data science and BI) and a product vision that not only solves the immediate business problems but takes it to the next level.