5 Questions to Ask and Answer Before Setting Up Azure DevOps

Welcome to Part 3 of my series on learning to manage analytics assets with Microsoft Azure DevOps (ADO). In Part 1, I explained how our analytics team works and why we needed an application to manage analytics assets. In Part 2, I talked ADO structure and terminology. This week, I’ll cover five questions to ask before setting up Azure DevOps to avoid rework. Read on to plan your ADO project.

Since writing part 2, I’ve moved from the Business Intelligence (BI) team to the Robotic Process Automation (RPA) team, which is still within our Advanced Analytics and Emerging Technology group (AAET). RPA was using Pipelines in ADO but wasn’t using Boards, Queries, or Dashboards. They didn’t have a catalog of assets, so one of my first tasks was to put that together. In doing so, I had to ask and answer the same five questions as when I set up the BI team. I expected answers to be the same, but they were not, so they serve as excellent examples.

Basic Setup

Below, I’ve listed the basic building blocks of ADO. These are the components we will use to organize all the things. I will walk thru five questions whose answers will help you figure out what you need to organize and how to configure these parts of ADO right the first time.

1. Project
2. Process
3. Area Paths
4. Iterations
5. Teams
6. Tags

Questions to Guide Setup Choices

1. What do you need to organize?
2. Which work items fit your purpose?
3. Should all content be in one project or multiple projects?
4. What is an analytics asset?
5. How do you want to view work items?

BI Answers

Question 1

What do you need to organize? The number 1 thing BI wants to track are analytics assets created by team developers. We need to know what we put out into the company and make sure it’s managed appropriately. However, BI doesn’t own every Spotfire project or Alteryx solution. The business actually owns and manages many solutions, but BI still has a hand in them. Users don’t schedule Alteryx workflows, PowerBI jobs, Spotfire Automation Services jobs, or Spotfire Scheduled Updates. These are created and controlled by the BI system administrators, so we need to keep track of these moving parts and the general system admin associated with PowerBI, Alteryx, and Spotfire.

We also work with a variety of data sources, and we want to know what data sources a given solution is touching. This is important when major changes happen, like application upgrades or schema changes, and someone in DB admin asks — how many people/solutions are using this? We need to have a quick and easy answer.

Finally, the BI team has done an outstanding job of creating a self-service analytics environment. However, users need support, and the BI team provides it. When users need help with Spotfire, PowerBI, or Alteryx, they can reach out for assistance. Those interactions must be tracked.

And there are a host of other small things that we’d like to know about, such as…

• Which Alteryx workflows use macros or CReW macros
• Do we have any active Alteryx apps
• Which Spotfire projects have IronPython, R, or JavaScript

All of these things can be tracked in ADO. We just have to know we want to track them upon setup.

Question 2 & 3

Now, one of the most basic setup questions to ask and answer is — What process do you want to use? To answer that question, you must first ask – What work items fit my purpose? This is because each project can use one and only one process. The process you choose dictates the work items available to you. You CANNOT mix and match whichever work item fits your fancy. They are determined by the process. And because you can only have one process per project, it often drives the decision of how many projects should be set up.

For the BI team, we set up one project to manage assets, admin, and support. This project uses the Basic process which allows Epics, Issues, Tasks, and Change Requests (as the work item types). Subsequently, BI adds projects in ADO for sprints. Sprint projects are set up with the Agile process using Epics, Features, User Stories, Bugs, and Tasks.

BI chose the Basic process for managing assets, admin, and support because they don’t need User Stories and Features to manage this work. However, when new assets are being built during sprints, they do want to be able to apply more detail with User Stories and Features. After an asset is complete, an Epic gets created in the assets, admin, and support project. The sprint project is retired. Any work happening after the initial asset build is recorded under the new Epic as an Issue or Change Request.

The next post will focus on showing you exactly how I use ADO structure (Teams, Area Paths, Iterations) to break up assets, admin, and support.

Question 4

What is an analytics asset? This is a really important question that must be answered before adding work items or else you’ll wind up with rework, which happened to me. I want to spare you that pain. For BI, the first delineator is the application. If a solution has a Spotfire component and an Alteryx component, those are two different assets, even if they are dependent upon each other. BI does this for a few reasons. First, we frequently have one person working on the Alteryx side of a solution and someone else handling PowerBI or Spotfire. Second, we use Alteryx to create data sets that are then delivered in either Spotfire or PowerBI. So, splitting them makes sense. Third, I’ve just found this easier to manage over time rather than combining into one. I originally set up assets based entirely on dependency and just didn’t like it. There were too many issues under a given epic, and ADO only lets you add one person in the Assigned To field. So, you could say some of it is personal or team preference.

However, dependency does play a role. If an analytics asset is made up of more than one Alteryx workflow, those workflows are grouped into one asset. The same is true with Spotfire. It happens that we duplicate Spotfire projects for different regions. Two projects with the same content equal one asset.

Question 5

How do you want to view work? Aaaannnndddd, I am going to put a pause on question 5 because there is a lot that goes into it. You need to understand what you can and can’t do in Work Items, Boards, Backlogs, and Sprints. So, this will get its own post.

Now let’s look at RPA.

RPA Answers

Question 1

What do you need to organize? Similar to BI, RPA also performs system admin for Power Automate Desktop, which we want to track in addition to our analytics assets. But, then the teams start to differ. RPA aspires to deploy self-service for Power Automate, but we aren’t there yet. So, we aren’t supporting users yet. Another difference is that RPA moves solutions thru several different environments (DEV, QA, UAT, and PROD), and we need to track what is happening in each of those environments at all times. RPA also has a backlog of use cases that we would like to manage differently and keep separate from assets. And finally, while reviewing our backlog of requested projects, I realized RPA touches all of the applications in the company, and it would be helpful to track which solutions touch which applications and the type of automation, such as PDF scraping, SAP scripting, document generation, email notifications, etc. The RPA team is still new with a steep learning curve, and there is value in being able to find example solutions quickly.

Question 2 & 3

Which work items fit your purpose? Should all content be in one project or multiple projects? The RPA team decided it wanted to have all work in one project. Because everything was going to be in one place, they wanted as much structure to work with as possible. The Basic process wasn’t enough, so they went with the Agile process using Epics, Features, User Stories, Bugs, and Tasks.

Question 4

What is an analytics asset? RPA answers this question differently from BI. In RPA, solutions can be made up of Alteryx workflows, Power Automate Desktop (PAD) flows, and Cloud flows. Most frequently we use cloud flows to trigger PAD flows. Unlike BI, one developer will do work in multiple applications and carry a single solution towards completion. So, we want to keep all the details of that work in one place, under one asset.

Question 5

Post forthcoming.

Wrap Up

Okay, that wraps up five questions you want to ask and answer before setting up Azure DevOps. When I started this series, I didn’t have an outline for it, which isn’t like me at all. I always have a plan. That’s why it’s taken a while to really get cranking. But, I got it figured out and the series will go like this.

• How My Analytics Org Works
• Microsoft Azure DevOps Terminology & Structure
• Questions to Ask and Answer Before Configuring ADO (THIS POST)
• Working With Azure DevOps Boards – coming soon!
• My Azure DevOps Configuration – coming soon!
• Building Azure DevOps Queries & Dashboards – coming soon!
• Using Azure DevOps for Analytic Asset Maintenance – coming soon!
• Working Build & Release Pipelines in Azure DevOps – coming soon!