By now you might be thinking about really diving deep into expanding your reporting capabilities. We support that. But how do actually fit it into your development scheme? It can be hard to quantify the value of a proper reporting system, and it’s hard to prioritize internal features over customer-facing ones. Reporting tools don’t always fit into a typical build/deploy models either.
In this segment, you’ll learn how you can efficiently integrate Power BI into your regular software development tools and processes. Our speakers cover:
How to approach reports like you do your code, bringing together database and app deployment
- What a “composed microservices” approach to building the app and reports looks life
- The benefits of leveraging DevOps and CI/CD pipelines in both the app development and reporting modules
- How Power BI’s Azure DevOps integration allowed Workify to run “beta” programs that let them learn more from customers on hone their approach
When you bring multiple disciplines together (App dev, Cloud, DevOps, and Business Intelligence) you may actually be surprised by the advantages you can unlock.
As always, we’re here to help you activate those opportunities. Email us to talk: email@example.com.
Garo Yerizarian: Welcome back everybody. I’m Garo Yeriazarian and I’m here with Evan Brooks and Glenn Burnside, and we’re talking about Power BI. In this segment, we’re going to talk about some surprising and unintended synergies in reporting. When you bringing Power BI into your software development process, what are some of the surprising things you’ll get out of it? And hopefully they’re all good things.
So, Glenn, I know we’ve talked about this before a little bit: Power BI out of the box isn’t really a software development tool, right? It’s a lot of click click, it’s a lot of drag, it’s a lot of kind of interactive things.
Things we typically expect, like source control, issue tracking, like bill transitions, and like things that we do in software. We move software from a certain classification of readiness to a more kind of like, “okay, you can show this to a customer” versus “you can’t show this to a customer.” How did you integrate Power BI with your software development process and tools?
Glenn Burnside: Yeah, and you’re absolutely right. You know, from coming out of the gate, it’s more of a document-oriented platform.
You know, when you’re working in the Power BI desktop app, your final artifact is a PDIX file. I mean, it’s like making a Word doc or an Excel spreadsheet. But it’s got this button at the top of it labeled “Publish.” And that’s the danger button.
We’re all laughing cause we all know — we’ve all seen those demos of visual studio: right click, publish to Azure and you’re shipping straight to production from whatever you had on your sheets
Garo Yerizarian: Friends don’t let friends hit publish!
Glenn Burnside: That’s right, friends don’t friends hit publish. But you know, that’s kinda the model. And again, it’s both a blessing and a curse, right? Because it’s got such an easy onramp, it’s a great platform to start at the shallow end and work your way to deeper and deeper sophistication.
For us, especially working with embedded, and working with Evan and the team on that, you know, we very quickly realized we were going to have to bring a couple of different mental models to bear on this so that we didn’t end up in the position we actually got to pretty early on where, as we’re building out these unified embedded reports, we’re also making changes to the database underneath to make the schemas line up and work out. If you don’t get those timed right, you’re pushing things out to production and then they would be just completely broken. You know, “works on my machine, but it doesn’t work in production at all.”
So what we had to start thinking about is, what are the models that we’ve used in the past on that? One of the nearest models we had to this really was how do we do databases. How do you bring database migrations and deployments into your build and development pipeline in your app code? And we started thinking about, how can we do that? How can we start thinking about our Power BI files as artifacts, assets that need to be deployed the same way we would deploy like a new get package or our actual app code.
And so, we actually started laying down the same practices. So, okay, let’s start checking our Power BI file into source control. Let’s keep it in its own repo. Let’s put a branching structure in place so we’re branching out for features and then we’re merging it back. I mean, there’s caveats, right? Cause it’s not text based and the diffing’s harder and all that, but that’s okay. We can work through it; we can handle that. And I think Evan’s going to talk a little bit about some of the things we’ve been able to do because of that branching structure. But ultimately, we built the full application life cycle management around our Power BI assets. So it’s going through the same quality gates, we’re building on top of Azure DevOps, so we’re getting automated deployment triggers. We’re getting gated checks. Someone’s got to go in and expressly say, “I approve this to be deployed into my test environment and production.” It makes it really easy then to tie it into our ticketing system so we know if there’s a bug in the report, we’re tracking that as a defect. If there’s a new feature we want to add, we’re tracking that. But the beautiful thing is, is we’re still able to do that with our Client Success team being the primary stewards and shepherds and owners of that asset.
We talk about like Conway’s law and software systems: You know, companies make products that mirror the way that their companies are organized. And you can kind of flip that on its head and use it to your advantage too. So if you want your system to be structured a certain way, structure your teams that way. And in this case, we want our application and our reporting that’s embedded in that application to be able to evolve and grow and change at their own rates. So let’s have two different teams be in charge of those and have those two different teams have their own pipelines for development, work tracking, QA, publish, deploy, verify, all of that — which is what we’ve done.
On the Headspring side, we do a lot of legacy platform uplift. We do a lot of architecture re-imagining for our clients, and we’re doing a lot of work these days taking their big monolithic systems and breaking them down into microservices. This is kind of similar now. So we’ve got almost like a web app microservice that one team is able to own and build and deploy. And then we’ve got like a reporting microservice that another team is able to build and deploy. But they’re running at their own, their own pace, you know? And so we’re having to wear our DevOps hat, wear our architecture hat, wear our app dev hat, wearing our BI hat — all at the same time — that made it possible for us to get creative and come up with like a really sustainable, scalable way to not just get the first version of these reports out, but also keep the process going.
Garo Yerizarian: Interesting. It’s really great to see, because I feel like every time — and maybe this is a Microsoft thing — but sometimes the first tool that comes out, it doesn’t have a lot of integration and automation, and then as people start to use it and provide feedback on it, then you start to see how it’s going to really integrate into people’s processes and finding ways to do that.
What really resonates with me is, when you have a strong DevOps culture, with that tooling and the processes and the culture, you can do a lot of experimentation and you can try out a lot of interesting things, you know, whatever your customers are willing to accept.
So Evan, when you guys went and had your Power BI embedded, you’ve brought it into your DevOps process with Azure DevOps — what did this allow you to learn from your customers? U
Evan Brooks: Quite a bit actually. So Glenn kind of alluded to this earlier, but the way that we’re using DevOps, we’re having three different channels: We have an alpha channel, a beta channel, and a stable channel. And all of our customers are in one of those. We have a few alpha clients that we’re using kind of to keep them on the forefront, on the bleeding edge of what we’re doing. They accept all the innovation that we’re putting in front of them and they’re a great source of feedback, which kind of just drives that loop of feedback to further innovation.
So that’s how we’re doing three channels for our DevOps pipeline, and that’s all made possible through the Power BI API, which has been great to work with. They allow us to use those gates and also accomplish everything we need to accomplish with our pipeline and our multi-tenanted business model.
So, if you think about, you know, we have a workspace per client, which mirrors our multi-tenanted database per client. And in order to not only publish the first report to each one, but also publish all the updates, we’ve been able to use the API to make every step that we need to take in order to do that. Those steps are: first, you have to publish the report and the data set in to each client’s workspace, and then you have to grab that data set and point it to the right database so that it’s showing data for the right company, and then you need to refresh that data set. And then you need to make sure that that data set either maintained the refresh schedules that it already had, or we need to apply it programmatically. That’s another level of customization that we give to our clients. Some clients have their data sets refresh more often than others just based on their business and which type of surveys they’re sending. So that’s another step of the process. And then the final step is to remove any of the old versions of the file that are no longer necessary. So it’s a multistep process. It’s a multi-tenanted environment. The DevOps pipeline fits great. And the reason we were able to use it is because the Power BI APIs allow us to do everything on the infrastructure side that we need to do.
So it’s been a really great process. Much, much better than our Client Success team having to click publish and select the right person, the right client, and point to the right database 80 times in a day
Garo Yerizarian: And make no mistakes! Zero mistakes!
Evan Brooks: Yeah…I don’t know that things ever run THAT smoothly.
Garo Yerizarian: It’s really kind of timely, because I know that there’s a lot of discussions that people have around deployments into cloud environments and what customers’ expectations are on downtime these days. And they really expect zero. Like they say, “this service should always be running.”
And one of the ways that we as software development organizations can help that is that we make publishing to production a simple operation. Like it’s done so often that it’s not even a special occasion. Like “Oh, it’s three o’clock, it’s time to push everything to prod…In the world.”
This is a great example of how Power BI, a tool that’s traditionally seen as more document-centric — to use what Glenn was saying — how you can integrate it with your process. You can bring it into a really continuous deployment and development cycle and bring that value to your customers. As well as show them different channels, different engagement levels that you can do and how put it all together.
And what this is really example of is that when you combine your product team with your development team and your client success team, everyone’s really working on the same product, everyone’s working together, then you can make really interesting things happen. You get surprising advantages being able to show your clients different channels of the reports and to get that early feedback from them.
Even for something like, for Headspring, using it internally, there may be ways to try out. Like you’re depending on this to run your business, you need to make sure that when changes are made that every day, it works. Every day it’s successful. And these are great ways to bring it into your process.
So thank you very much for sharing that. I think this is a great example for businesses out there that are interested in Power BI or maybe not yet who are wondering, well, how would I actually integrate this? How would I make sure that this works? And really understand it better. Really, it’s a huge tool, it has a lot of things to it. How do we help our clients understand more about how this tool can be used effectively?
Thank you guys very much for your insights. And for talking with us today about Power BI, and about forbidden chart types and what we can do with Power BI with our clients going forward.
So, I’m Garo. I am with Evan Brooks and Glen Burnside, and, we’re very to happy to talk about Power BI.
Glenn Burnside: All right. Thanks a lot y’all. It’s great talking with you.
Garo Yerizarian: Okay, bye.