A look at fusion teams with Microsoft Azure and Power Platform

A look at fusion teams with Microsoft Azure and Power Platform

I’ve had a chance to work with several exciting projects involving Microsoft Azure and Power Platform. Usually, Azure is already utilized for plenty of things, and Power Platform is starting to gain in usage. I wanted to write this post to reflect and think about the intersection of these two platforms in project work.

Introducing fusion teams

Microsoft talks about fusion teams and also of fusion development. In short, fusion development is combining two vastly different worlds – the world of professional developers and business users. The latter is also affectionately often called a citizen developer.

Then, a fusion team is an amalgamation of these two – a team with business users and technology and developer experts. This isn’t a widely adopted approach yet, but we’re progressively moving toward this sort of working model.

In an ideal world, a fusion team has business stakeholders and users who understand the business needs and requirements. They might be intimately familiar with the industry and perhaps understand what the respective end-users or customers need. The other core role for a fusion team is, thus, the developers. People who can get a pre-digested set of requirements and then design and implement a custom functionality or capability in Azure. Finally, and this is my take, a fusion team requires someone who is neither. Someone who can oversee and help decide whether which approach will implement a specific feature.

But I’m a pro developer and I know how to code anything!

That’s great! I have very high respect for developers. And what I usually see is that the best and most capable developers do a lot of things that are is not the act of producing lines of code. Architecture, scalability, deployment, testing, usability, performance, and so on. Yet, it’s imperative to understand not everything should be custom developed. This is painfully true in Power Platform-related projects.

I’ve initially reduced my thinking for pro developers in fusion teams to focus on two things:

  • Custom APIs, exposed through Azure API Management
  • Deployment, versioning and architecture

Let me clarify these two a bit. The first, custom API implementation, is the bread and butter of most Azure-experienced developers. You have so many ways to implement an API, and for Power Platform, you usually need multiple custom APIs. Then, the APIs are exposed through Azure API Management – some specifics are typically included in this, such as authorization and error and exception handling.

The second focus area, covering all things deployment, is then a trickier one to tackle. Why, though?

Most developers (and architects) usually buy into the idea of doing Infrastructure as Code – for Azure. This is especially relevant now with Azure Bicep. But consider that all things in Power Platform might need to be deployed, duplicated, versioned, and deployed. It’s slightly different for developers to manage, and I feel the business users shouldn’t start a deep dive on this topic at all. Therefore, developers have a learning curve to understand a bit more about the Power Platform. Especially how to manage environments, drive solutions, and the ALM process for Power Platform looks like.

We don’t need developers where we are going

Let’s look at the big picture from the other end. The viewpoint of the business user is that they (usually) don’t need or want to understand the technology any more deeply than what is currently necessary to achieve their goals.

Herein lies the challenge. When you don’t know what you don’t know, every practical problem or obstacle can only be resolved with the tools at your current disposal. Thus, sometimes business users start circumventing or fixing a problem within their Power Platform solution by going through numerous hurdles – which the pro developer could have perhaps resolved with one line of JavaScript.

I’ve playfully – and somewhat seriously at the same time – introduced a culture in my companies for years, that if you’re stuck for longer than 15 minutes, you HAVE to ask for help or a second opinion. In pandemic times, this is sometimes easier, as you can utilize whatever instant messaging platform to get help from a peer. At the same time, it’s more challenging, as junior professionals especially might have difficulty “bothering” a more experienced user with their little problem.

Who then makes the call when and how the pro dev should implement a particular feature? That would be the third role I outlined above – someone who understands enough of both worlds and can make an educated call.

In closing

The more I get to work in such diverse teams, and I’m becoming more fond of the fusion team approach. It certainly isn’t a brand new concept, as the same model we’ve had for years with UX/UI designers and developers, of course. Yet, for Power Platform, it’s a valuable concept – as you typically gather together people who understand business, and they usually lack the tools to implement custom features beyond what the platform offers by default.

I wouldn’t over-engineer this approach but instead keep it simple. Allow ample freedom while providing clear guardrails for the team. “Where to implement what?” would be a good question to get clarified at the beginning of a project.