Manage Analytics Assets with Microsoft Azure DevOps

For the last 3 1/2 years, the Advanced Analytics and Emerging Technology team I work on has provided analytics solutions to our business units via Alteryx, Spotfire, PowerBI, PowerAutomate, and a handful of other applications. We’ve done such a great job building solutions that we needed a robust tool to manage them. Therefore, I’m kicking off a series of posts that explains how we manage analytics assets with Microsoft Azure DevOps.

When the organization was first formed, we wanted to provide business value quickly, and we did that with several successful products. But now, as the organization matures, we need to better manage those assets. We need to ask and answer questions like…

How many assets are we actually managing and where do they live?
Who owns those assets and are they still with the company?
Are we maintaining products that aren’t being used?
Which business units do we help the most?
Which business units might need us to reach out?
When do solutions need maintenance and how can we trigger that need?
How can we better maintain and manage these assets?

Microsoft Azure DevOps helps us do all of these things.

I imagine there are a number of other oil and gas companies out there in the exact same position because most companies now have analytics, BI, or ML/AI divisions. So, I thought I would give a high-level summary of how we use Azure DevOps to manage analytics assets. And to make a connection for my regular readers, some of you may have noticed that I added the job title of Analytics Asset Coordinator to my role last year. This is what that role is all about.

Because Azure, Agile, and DevOps are beefy topics, I’ll break the content up into multiple posts. I’m not sure how many it’ll work out to just yet. I’ll start with a brief explanation of how my team works.

How We Work

First, the AAET team is made up of 3 sub-teams. I am part of the BI team.

BI (Business Intelligence)
RPA (Robotic Process Automation)
ML/AI (Machine Learning/Artificial Intelligence)

My posts will be written from the BI team perspective. Each of these teams performs roughly 4 types of work.

Sprints (Architecture, Building/Development, Testing) for focused work on specific products
Support of said products
Maintenance of said product
Ad hoc work that’s too small for a sprint

Sprints

Sprints are an Agile way of working. A sprint lasts for 2 weeks and takes place with a dedicated team of developers and other roles doing focused, prioritized work. Interruptions and distractions are not allowed during that time (yay!). The only thing you work on is sprint work. Our business partners (drilling, completions, supply chain, etc) are also fully committed and engaged during this time. A lot of prework happens before the sprints to get base requirements and prioritize so we can hit the ground running. It’s very important to hit the ground running and not spend that 2 weeks waiting. Lastly, AAET usually owns and maintains the products that come out of sprints.

Support

Support is about helping users with their problems. We largely work in a self-service environment, and users are expected to attempt to solve their own problems. But, we can’t completely leave users to fend for themselves. For example, Spotfire has been wildly successful at our company because when users got stuck, they had someone to call. Without hands-on support, many would have given up and resorted back to what they knew. And, we’d still be using Excel for everything. Instead, we moved up the maturity curve, and I am very proud of our users.

Maintenance

Maintenance comes in a few different flavors. There is application admin and maintenance for PowerBI, Alteryx, and Spotfire. We also perform product or solution maintenance. A product we build breaks or needs a tweak or update. We do it. We also maintain Spotfire Scheduled Updates, Spotfire Automation Services jobs, and Alteryx scheduled jobs. Those need to keep running and humming along so analytics solutions function smoothly.

Ad Hoc

Ad hoc work encompasses anything else that isn’t part of the other three types of work. Sometimes ad hoc is just a small request or project that isn’t big enough for a sprint.

Conclusion

Now that you know a little bit more about the team and how we work, the next post will focus on how we physically manage analytics assets with Microsoft Azure DevOps.