Power Apps ALM Accelerator for Advanced Makers with Marc Schweigert, Microsoft

Welcome to the Amazing Apps show for Microsoft business applications creators who want to build amazing applications that everyone will love. Hi, I'm your host, Neil Benson. My goal in this show is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Microsoft Dynamics 365 and Power platform applications. I took a break last week to go camping with my family during the Easter school holidays. So sorry I didn't have an episode scheduled in advance. I've been pretty busy recording presentations for Scottish Summit Dynamics Con, Worldwide Microsoft Technology User Group conferences recently but we're back this week with a great interview and a special bonus episode. I'm joined in this show by Marc Schweigert, he's a principal programme manager lead in the customer advisory team, I nearly said the Customery advisory team for power platform at Microsoft, also known as PowerCAT. PowerCAT builds the Centre of Excellence starter kit to help power platform customers, especially administrators and builders, manage their power platform environments and applications with patterns, practises and tools from the PowerCAT team. And new from PowerCAT is the ALM Toolkit for Makers that enables no code low code citizen developers who are new to application lifecycle management to follow a set of proven practices to deploy their Power Apps from Dev into production. There's also a new tool kit for advanced makers that offers professional developers with more control over the same patterns, practises and tools offered in the ALM Toolkit for Beginners.

It's available in GitHub under an open-source licencing model so that we, the power platform community, can suggest enhancements and even make enhancements to the toolkit. There are links to Mark's LinkedIn profile, his Twitter handle, the PowerCAT live playlist on YouTube, which I highly recommend the ALM Patterns and Practises page on the Microsoft Docs site. There's the ALM Toolkit for Makers, and the ALM Toolkit for Advanced Makers, all in the show notes for this episode, as well as a transcript of my interview with Mark. You'll find that at Customery dot com slash zero three zero that's the word customer with a Y on the end dot com slash zero three zero. Remember to subscribe to the Amazing Applications podcast on your favourite podcast player and you'll automatically receive special bonus episodes when they're available for episodes like this one. I put Marc through a rapid-fire round at the end of our chat to find out whether he prefers Scrum or SureStep, whether he calls it a table or an entity, whether he recommends one environment per developer or a shared developer environment, and whether he'd rather use azure dev ops or GitHub. And there's a few more. Besides, he's got some surprising answers. So make sure you subscribe and don't miss it. Here's my interview with Mark Schweigert from Microsoft. Marc, welcome to the Amazing Applications podcast. It's great to have you on. Thanks for joining me.

Thanks for having me. It's great to be here.

Do you want to just give yourself a quick introduction for the benefit of our listeners and then I'll get into some introductory questions and kick off the show from there.

Sure. I'm Marc Schweigert. I'm a programme manager on the Power Customer Advisory Team at Microsoft. We're a team that's part of the product group that works with some of Microsoft's largest, most complex, most demanding enterprise customers these days, typically, who are pushing the envelope of broad, low code adoption using power platform in enterprises.

Couple of questions I'd like to ask all my guests just to get to know them a little bit better, starting with what did you have for breakfast this morning?

So for breakfast, actually haven't had breakfast. I'm not doing breakfast right now. I just had a black coffee.

Oh, you're one of those intermittent fasting folks?

Actually, I have, actually. We my wife and I just started looking at it and I was looking at the the health benefits of it and, you know, you know, lower my blood pressure and some other things. And so giving it a shot.

Yeah. I listen to some of Tim Farriss is I'm actually reading listening to the audiobook version of Tools of Titans where one of the proponents, they're talking about the benefits of intermittent fasting. But I haven't got the I've got the appetite for it.

So far it's been actually really relatively tolerable. I generally do eat breakfast. I like the you know, the or at least in theory, I get my metabolism going in the morning. So, you know, based on some of the ideas behind this, that's not as necessary, apparently. But we'll find out that.

Good for you. Let me know how that goes and tell us, how did you get your first job?

First job. So I think my first. Very first job was telemarketing, it was in high school, and I honestly don't remember, I think it was through a friend and that's probably the less interesting one because I ran kicking and screaming very quickly because I didn't like people hanging up on me and I didn't like being rude to people. I would say my second job is probably more interesting when I was a big tennis player in high school. And so I worked at our local community centre, both working at the snack hut, but also helping teach tennis.

Oh, great stuff. And how did you land your current role at Microsoft?

Oh my current role in Microsoft. So I've been on the power customer advisory team a little over a year. I've done a number of things at Microsoft, both in the product group as well as in the field. And so it's kind of a long, circuitous path that I got to this role. I you know, my background is is app dev, you know, not not low code. You know, I started off at Microsoft as a sequel biz talk and dot net pre-sales engineer, what would folks call a technology specialist today? And I quickly learnt about this group called Developer and Platform Evangelism that no longer exists. And I said, that's what I want to do. I can get paid to go just talk to people about dot net like I'm in and the first half of my career at Microsoft. That's that's what I did. And I loved it. I was both a developer evangelist and what we called an architect evangelist back then. And I basically grew up with every version of the dot net framework. I was an Azure evangelist before anybody knew what Azure was. You know, we were just Web worlds, worker roles in this thing called Azure Storage and then Azure sequel, which, interestingly enough, looks like dataverse what Azure sequel was back then. It looks like what dataverse is now in terms of basically a rest API for relational data. And long story short, I learnt about this thing called XRM back in around Dynamics twenty eleven days or CRM twenty eleven days. Yeah. Ultimately ended up becoming effectively a early low code advocate at Microsoft and did a number of things along the way, but ended up actually being responsible for sales strategy for Power Apps in corporate Microsoft for almost almost two years and met all the folks on the PowerCAT team and really wanted to get back to my technical roots. And so long story short, I ended up being on the team and it's been a blast ever since.

All great stuff. I have to personal admission. I need to make I knew you on LinkedIn as Marc Schweigert for a long time. And it was this other character on Twitter called devkeydet and it's only probably the last 12 or 18 months that I've realised it's the same person. So where did the devkeydet alter ego come from?

Yeah, it's funny. So when I first started getting into social media, primarily blogging, I did it kicking and screaming like, you know, I was one of those people. I'm a private person. I don't want to have a public persona kind of thing. And so I always tried to anonymize as much as I could was kind of looking back now. It's kind of silly, right? But at least in those days, you know, being out in the open on on the Internet was an uncomfortable thing for me. And so I just came up with devkeydet that interestingly enough, I went to a military school in southern Virginia called the Virginia Military Institute. And the mascot of the school is a keydet that it's actually a kangaroo. So but the way that I should

Know that, but

The way that Southern people pronounce the word cadet it sounds like keydet. And so that's where the word keydet comes from. And then dev because my background is in development, I just kind of put the two together and that became my, my handle.

Oh there you go. I never knew that you talked a little bit about the PowerCAT team, customer advisory team helping mostly enterprise customers adopting the power platform. Can you help me understand, maybe our listeners understand the differences between this number of different groups at Microsoft? So there's fast track consulting services, there's customer success. There's a new role called customer engineers. I don't know if that's the new name for customer success where that fits in. Can you help enlighten us where they all fit in and how they help our customer?

I'll do my best so to connect the dots with fast track. We actually are in the same part of the product group that fast track is in. But we have a different mission in a different charter than FastTrack. Fast track is a very large organisation helping primarily customers with Dynamics 365. And given the fact that Dynamics 365 increasingly runs on top of the power platform, you know, there's a separate team arching the customer advisory team that focuses more instead of on single app use case or single project use case, go live type of scenarios, we work on much more broad adoption helping a customer from the beginning of their low code journey to ultimately trying to get them into a position of being self-sufficient and as you can imagine along the way, that includes everything from environment strategies, government, administration strategies, readiness and nurturing strategies, successfully taking some of their low code applications live, helping them with application lifecycle management. We really sort of get entrenched with a customer in a very deep level for an extended period of time. We really serve as their their customer advocates to feature teams and the liaison essentially between feature teams and customers, helping drive both improvement in the platform through those customers, as well as ensuring customers get unblocked, etc.. We're part of the same organisation as FastTrack in the product group. And then in the field, there's something called the Customer Success Unit, right? In the Customer Success Unit, we have customer success managers. We have in the Azure world, we have cloud solution architects and multiple worlds. We have customer engineers that used to be premier field engineers, that we're in a different part of Microsoft. They're actually in the the services part of Microsoft, and they've been moved out of the services part of Microsoft and into the customer success unit because as you can imagine, a role like that is critical to a customer's success. And so we're where we're trying to make customers successful post-sales in the field. Most roles are now in the customer success unit, whereas in consulting services, Microsoft still has MCS or Microsoft Consulting Services. Those are folks who effectively do project work.

Right. You going to hire them, pay them as a consulting engagement.

And then where we fit in is we're sort of the product group incarnation, if you will, of what the field does and the customer success unit we typically work through with a smaller group of customers where the customer success unit sort of does similar things. But at scale with with many more resources, typically aligned to specific customers as well. And for PowerCAT, in many ways you can kind of think that we incubate a lot of the customer success patterns and practises for the power platform that will ultimately then be scaled through the customer success unit. And so we think of them as part of that part of the same larger team. We just happen to sit in the product group working more closely with feature teams and certain customers. And then we try to scale our learnings, knowledge, patterns and practises in numerous ways, but in many ways through the customer success unit. So all Microsoft customers can have same similar levels of success.

That really helps me paint a picture because I've worked with all those teams more or less separately and never quite known how they all fit together. So thanks for helping fill in the gaps there. And more recently, you've become known or power platform customers adopt a more mature application lifecycle management strategy and some tools and practises there as well. Can you help maybe explain for our listeners what Microsoft's approach definition of application lifecycle management is? First of all,

Sure, I would I would actually take a step back and go a little bit more higher level. You know, the concept of application lifecycle management exists for a reason, because when you're building a simple application as a single individual, whether it's low code or code first, you arguably probably don't need a whole lot of application lifecycle management. Right. You you build something, you get it into a place where other people can use it, other people using it. You make changes to it in some way, shape or form, and you get those changes out to users. And it's sort of simplest concept. But as as more people use your application, the risk of introducing changes in a casual way becomes much higher. Because if you introduce changes in a way that impacts thousands of users, even if you're the only person building the application, there can be some problems there. Right. You're going to have unhappy users then as you kind of grow and you introduce more people building the application. Right. Whether it's two people or three people or 15 people, you introduce complexities there in terms of work coordination, in terms of, you know, reconciling each other's work in ways that you can all bring it into a single experience that people can then possibly test.

Right. And possibly use and production. The need for testing becomes more and more apparent. Right. As you have more users, more complex applications and more people building it. And so concepts around application lifecycle management have just been born out of necessity. Right. And so when it comes to ALM with the power platform, really it is about sort of following that similar pattern is of, you know, if you don't need ALM, then you don't need ALM. But you typically know you need ALM. And when. You need ALM, and that's what I always tell people, is like you start to feel pain points and so you have to start establishing practises and processes to to increase the quality of the applications you're building. Right. In a consistent fashion, to better coordinate work to, you know, to better manage the work that different people are doing in a way that you can all be consolidated and made available to users through, you know, development, testing, production environments. And so I think at a very high level, that's what application lifecycle management is about. And then if you kind of look at how how the discipline has evolved, you know, and it's interesting because, you know, people sometimes use ALM and dev ops synonymously.

I was going to ask you about that as well.

Actually, I've like I'm a big believer in in dev ops, the concept. But you know, what I've learnt, especially over the last few months, is that when people at Microsoft say dev ops, everybody just assumes they mean azure dev ops. Right. That the the service that allows you to do dev ops. And so I've kind of walked away from using the dev opps term because it just causes confusion. But the point is generally you need a place to put all of your work. Usually that's a source control system. You need a way to coordinate the work that you're doing and you need a way to then take that work and move it to different environments. And so automation becomes key because the more you can automate, the more you eliminate, you know, human error, the more you eliminate human error, the more you increase quality, then you can start to introduce all sorts of other things into that process. And so this is a sort of a well-proven practise in what I would call I'm not a big fan of the term procode so I use I use code first technologies. Right. People who are writing, you know, fundamentally starting with code and building applications. And so when it comes to the power platform, it's you know, it's it's an interesting dilemma because there's a an extreme of people who are building highly complex, multi-person developed mission-critical systems on low code technology. A lot of people think of of low code and power platforms for the citizen developer unit, without question is but there's a group of people who want to do the level of ALM they do with and and dev ops or, you know, build and deployment automation and source controlling that they do with C sharp, JS, you know, Azure, App Service, et cetera, but with power platform. And then there's this group of folks who really just want to get started and being able to take all the stuff that they did in a low code environment and move it from one environment to another. And so we in PowerCAT I guess there's a couple of dimensions here, right? First and foremost, that's a hard challenge, right? Helping people understand entry-level ALM and give them tools to help get them started and then tools to do that high-end sort of get out of my way. Let me do things the way I want to, but but make my ALM experience more productive. Right. And and so we in PowerCAT also build something called the Centre of Excellence Starter Kit. And it's a team of six, six to 10 people who build different aspects of the CoE starter kit. And as you can imagine, we need to do ALM of the power platform solutions that we're doing. And so we've been focussing more on that extreme side for some of the things that we've built in. We've been building and we've actually built a set of azure dev ops pipelines, some canvas app, and basically we've established an ALM process for the CoE starter kit that's a combination of using source control, right. Using build and deployment automation. We're going to start introducing testing and a number of other things so that we could get healthy with something we call the CoE starter kit. We could get our ALM healthy. And then what we want to do is essentially take everything we've built for ourselves because we've built it in a very generic way. Right. Our pipelines are highly variable driven, their componentized. So and their intelligence to an extent where if you you set variable X like certain things in the pipeline, but if you never even create variable X, certain things get ignored. And so we've built them in such a way to meet our own needs, but also meet the needs of other folks who are doing highly advanced ALM. And so that's all coming through something we call the CoE starter kit. And then we also have another set of applications. That's another reference application that's geared more towards sort of the entry-level ALM. And so why do we do all this? Well, if you go to Microsoft's patterns and practises guidance around ALM, sort of read it, you feel overwhelmed and you feel like you don't know where to start because there's so many options, etc.. And so what we wanted to do was build something that at least helped people get started, that they tried to embody the patterns and practises of ALM for the power platform and and save people time to build from a clean slate to a mature state, which for most people takes months, it takes months to kind of get from the beginning to some level of build source control, build deployment, automation, and again, for the Advanced Maker app. We're taking a philosophy where you hide nothing, right. For the entry-level maker app, it's still source control, build and deployment automation behind the scenes. But the the citizen developer knows nothing about that. That's more sort of a way to archive apps as they go from one environment to another to have history of apps, et cetera. But the citizen developer just kind of builds stuff in a power platform solution. When they're ready, they say, my stuff's ready to go to another environment. Flow approval happens behind the scenes. Now, behind the scenes, an administrator or somebody else can look at the source code. They can you know, they use things like pull requests etc that are more advanced concepts with source control technology specifically get and that's the approval process. But again, to the citizen developer knows nothing about it. And so we're trying to sort of start from these two different perspectives that are very diametrically opposed. Like one person doesn't want to know any of this stuff. The other person doesn't want any of this stuff hidden from them because they want full control over it.

You've unleashed a whole bunch of questions in my head if I can work through a couple of them. Marc, so you said that ALM is a, it's not a necessary practise. If I'm the only application builder, then be working on a personal productivity application, whether it's just for me or a couple of people on my team. So small scale, low risk, I might even be developing in production, ALM doesn't really apply or there's more than one builder or where it becomes a mission-critical application or have got more than one environment in which that app has to be built and then deployed. I need to start thinking about ALM. So that's that's pretty clear. And it doesn't. I think what you're saying is it doesn't matter whether I'm a new to application building. There is a application lifecycle management approach and you're providing some tools for me. That's great. But if I'm a professional developer and I'm used to L.N. concepts, then there's also some patterns and practises and some apps available for me as well. Microsoft finally stepping into the ring here because for years I've been hearing at conferences from experts like Scott Durow and Wael Hamze  and even Sean MacArthur before he joined Microsoft. ALM is a good thing. You need to have healthy ALM to successfully build amazing applications. Here's how you can do it. But the more conferences I went to, the more divergent opinions I heard about. Here's how you can do it. And it might be an MVP with a lot of experience or it might be some solution architect who's just discovered how to do it first time on one project and sharing his or her experience, which I think is great, too. But it became very confusing for people to know. Is there a recommended practise of Microsoft, do you think? You're now telling the community, look, here's how Microsoft recommends you practise ALM is that what we are finally converging on.

So it's interesting. We've been very hesitant to actually take that hard stance because one size never fits all right. And I think our our philosophy on the ALM accelerator team and the CoE Starter Kit team is a little bit different. It was sort of we needed to do ALM. We needed to figure out how we were going to do ALM for the real-world solutions that are part of the CoE Starter Kit Power Platform Solutions right there for for for the listeners who aren't familiar there. I'll digress for a second. When we refer to Power Platform Solutions, it is the package and deployment mechanism and the engine where you take all your power platform stuff. You throw it into this thing called a solution, a container, if you will. And it is your unit of deployment of all the things that you've built. Right. And so all the investment in ALM, in the power platform for the last year and a half, if not longer, has all gone into making solutions. The ALM engine for all things power platform. So any thing that we now call a solution component, whether it be a dataflow or canvas app or Power Automate flow dataverse table a dataverse plugin, it's all packaged and deployed through solutions. And if you're if folks are familiar with Azure, always sort of equate what Azure resource manager is right. It's the engine that deploys all the stuff in Azure and then the Agile Resource Manager template, which is the definition of all the stuff that gets deployed.

Solutions are effectively the arm of power platform, right. There's the solution engine behind the service and then there's the way you you package, deploy and define all those things. And so back to the point. We've had to build these solutions. And so our point of view has always been we're going to figure out ALM for ourselves. Right. We're going to build a set of tools that show you how we do ALM. Now we're going to do certain things that are. Opinionated, in fact, we do some things that kind of, quote unquote, violate the rules, right? There are there are edge cases where we manually edit XML files that are unpacked into source control from solutions, but we do it in a very thoughtful and pragmatic way and we'll explain why we chose to do it in the pros and cons, et cetera. But what we really wanted to do was not say this is Microsoft's way of of saying how you must do things. This is a way that embodies as much as possible the patterns and practises that are published, but also takes pragmatic approaches to solving real-world problems and in some cases, to solve real problems. There's the theoretical and the practical. And we're we're unapologetic about the places where we're having to do things practically and pragmatically versus theoretically.

And there are things that we do like we don't treat our environments like cattle because there are known challenges with environment lifecycle management in the platform. And so we have to deal with those things. And so we do certain things to try to treat our environments like cattle. But but we don't actually do environment resets for environments. Often we take alternative approaches that accomplish the same end state. But again, back to the point. We're not trying to be like what we're going to have is is warts and all. And ultimately, in the next week or so, we will be launching it in public preview as an open source project. And in fact, every part of the CoE starter kit will be open-sourced. And so we're moving to a model. Well, as you can imagine, we had to get it again. We had to get ALM healthy and right. In order to open source everything that you're building, you have to have good practises in place, because if you want people to contribute right, you're going to have to explain to them how to contribute, how to submit poll requests, et cetera. And so it it's we've been on this journey to get to a place where we could open source the CoE starter kit. The ALM aspect of it was paramount then shipping the assets that we're using to do ALM was also paramount because then we can ask other people who want to contribute to use those same assets and then participate in the same process that we that we participate in internally.

Now, all that was is about basically just sharing what we do, not saying it's right or wrong. Right, but sharing what we do and sharing it out in the open and then asking the community to participate. And so, yes, I think this year we started getting the ALM  accelerator work that we're doing started with a bunch of people inside Microsoft wanting to share what we're doing. But it's going to really go where we want it to go. It's going to require the community. And so we want all those people who have opinions about different things to participate and help us improve what we're doing, frankly, help us improve our own processes. We've got a lot to learn from the community in terms of how they've addressed some of these challenges. And so, again, your original question was, is this Microsoft saying this is the way to do things? I would say no. It's a way of saying this is how a team at Microsoft who's doing the same things you have to do is doing things. And here's everything that we've put together to help make our lives easier, to make your life easier. But give us feedback, tell us, like, how to do things better, how to improve our pipelines, how to improve our canvas apps like how to not be so opinionated and prescriptive, like, hey, I like to do things this way.

Give me the option to do it right. That's the kind of feedback we're hoping to get. Now, the reality is, in many cases, the person who submits the issue, we're going to say, hey, we may not have the the resources and the bandwidth to do this in our release cycle, which again, we're not again, but we're moving to a monthly release cycle. Right. Like much like VS code does and other open-source projects at Microsoft, we want to have these very short, high priority work. Don't kind of process where we get those things in new release, then we kind of do the next release, et cetera. And our philosophy is going to be everything gets put on the backlog out in the open, you know you know what's on the backlog? Community voting will drive features. I think most importantly, once we get our contribution plans right, the pattern will probably be user files, an issue for a feature enhancement. The first comment is, do you have the bandwidth to work on this feature? You know, go for the repo, do some work, submit a pull request and let's review the work that you're doing so we can get it into the next release or some future release.

So you mentioned there the iterative and incremental approach that you're taking. And I see think about agile approaches to software development. I see ALM as an absolutely critical piece of that. You cannot ship frequently into production unless you have healthy ALM Do you think that's true of more traditional plan based project approaches where, you know, you're not planning to ship into production for 18 months or a couple of years in a big ERP project, do you think ALM applies to practitioners executing a waterfall style project as much as it does an agile style?

So I think it does. I think this is a philosophical discussion. I, I think you just don't reap as many of the benefits because I don't think it's it's agile development or ALM right to reap the benefits of both. Its sort of the combination like you can do build and deployment, automation and source control. And there's all sorts of value and having that right. But you're not going to get the continuous improvement that that agile methodologies and sort of the the infinity dev ops sort of philosophy, you know, promotes if you're you're you're doing more traditional, you know, extended period, waterfall style project management. And, you know, it's always fun to see people who say they're doing agile development, but they're really doing waterfall and trying to say that it's agile. Right. You know, I think there's there's a culture change. There's a lot of changes that need to happen. But I think the intersection of build deployment automation and automate everything in general, coupled with small, discrete pieces of work done over and over again, getting those discrete pieces of work into an environment that users can actually use to provide feedback on iterate and then take into a release. I think it's the intersection of those two things in my mind that reaps the most benefit.

Thinking then about ERP projects in particular that seem to have at least the people who contacted me and asked me about agile ERP is they have a hard time thinking about short iterative cycles and frequent production releases. Microsoft has got the new ALM accelerators for the power platform, which I guess encompasses some of the Dynamics 365 products. If building sales, marketing, customer service, field service, project service, I can use your ALM patterns and practises, but if I'm using Dynamics 365 business, central or finance or operations or H.R., there's a different set of tools for both those teams. Do you think we'll ever get to a convergence of a single set of ALM patterns and practises right across the business application stack and even extend that to Power BI, which today seems to sit somewhere in between and Azure? So I've got a lot of Azure components. I've got logic apps and Azure functions as part of my application stack. Do I manage that as part of my release cycle as well? Yeah.

So there's a lot in there to unpack, so I'll kind of step back to where we were before the announcement. I don't know, three years ago now before the announcement was made that XRM was merging with our platform. One of the conscious yet frankly tough engineering challenge decisions was to say that solutions are the low code ALM engine of the platform moving forward. And it's taken us a long time to to get there. Right. There's been a long laundry list of known issues with like canvas apps and Power Automate flows and certain aspects of our platform that, you know, certain certain sort of happy past scenarios work. But second, you tried to introduce some more advanced scenarios. Certain things broke. And the good news is like the level of ALM health we have with solutions and the tooling coming from Microsoft is finally getting to the place, frankly, where we could build this ALM accelerator, a part of the reason we haven't had the accelerator sooner. And part of the reason we, the CoE starter kit, couldn't do the level of healthy ALM that we wanted to do was because the platform needed to catch up to enable us to do it. Right. And that's that's just a matter of reality of this this merging of these these technologies. Right. And so the question about like all these different things, as you mentioned.

Right. Right now, our focus is things that are grounded in solutions. Right. Which comes from Dynamics 365 customer engagement is now the ALM engine of the for the platform. But I think that's the key key statement. It is the engine of the platform moving forward. So anything that is part of the platform, whether it's first-party applications that leverages the platform or bespoke custom applications that you're building, all the other the lower-level aspects of it long term will be incorporated into solutions. As other aspects of Dynamics are brought into the solution system, then we'll have a consistent story until that point comes, there is an inconsistent story across, for example, solutions and how you do things with other Dynamics products that aren't based on sort of the what used to be called the CE platform or which is now a data verse and in model-driven apps. But having said that, you brought up Azure as an example. You know, whether we will get to a place where you can coordinate certain elements of Azure through solutions is to be determined.

Right. But you can imagine that there are certain elements of Azure, namely what historically would be called platform as a service. Right. Some people refer to and more often is now called Serverless Technologies and Azure that are really geared towards app dev. You know, there there's a lot of opportunity there to kind of bring solutions and some of those aspects together, because as you think about larger complex low code solutions are almost always developed with some extensibility, with code first technology. And in the Microsoft world, that's typically running an azure. But there are also cases where there's, you know, things running in other cloud services as well. And so I think both the the other Dynamics technologies in coordination with things like Azure is is a lot of room for opportunity in the future. But in the short term, you can do all that coordination through pipelines. Right. So say, for example, you have an azure function. Right. And you have a custom connector and you have a canvas app that calls, the custom connector through API management that ultimately talks to an azure function in an azure devolves pipelines or GitHub workflows. You can do that coordination work. Obviously there's dependencies there. So order matters. Right. And that's one of the things that will actually show in the accelerator.

One of the things that we are doing is building a reference application. The reference application is going to be kind of meaningless. It's really about exercising ALM and exercising build and deployment automation. But we will, in the fullness of time, show an example of some azure function code sitting in a source code control repository. Write that scenario I just described and what will we do? And the pipeline will build the Azure function. We will make sure that the Azure function app is deployed, will have an armed template in the source control system, will do it in the right order such that then the solution can be deployed because the solution depends on the interface of the API. Right. And then and so you'll be able to do this work across a fusion team where some people are writing Azure functions. Some people are writing dataverse plugins, some people are writing PCF components, some people are just building point and click configuration within the service and exporting it to source control. But the source control system will be the source of truth and will show pipelined examples of how you can coordinate all that work across an end to end system architecture that that isn't just low code, but spans, you know, multiple things which in the real world is how almost everything works. Right.

Right now, I have my last enterprise project. We had twenty-five people in the Dynamics 365 team and is really building stuff on top of the power platform. We probably had 50 people in the systems integration team, mostly building Azure services, and it was just a lot of work to coordinate everybody's releases and builds and all the functions and stuff. It was not easy. You must face this quite a bit with enterprise customers who maybe in this case it was their first ever power platform project, early adoption of Azure for this customer. Their existing dev opps tooling was not Microsoft based with a lot of Atlassian stuff like bamboo and puppet. I'm trying remember some of the other tools. Do you face that challenge with some of the other enterprise customers out there? Maybe not a GitHub or Azure dev opps shop and they're there having to learn the Microsoft tooling as well as the power platform, how to develop on at the same time?

Yeah, absolutely. And, you know, the the simple answer is, well, you know, everything's the API behind the scenes in any CICD platform that can call an API can do the same things that we do in azure dev opps and GitHub. Now, the level of effort to to achieve that is high because if you look at the various APIs across the platform, there's different API endpoints. Right. In some cases you can do things in Power Shell and Power Shell today is some of our Power Shell, some some of the things you can do, use our Power Shell Commandlets which are Windows only and some customers want to use, you know, other job runners like Linux, et cetera. And so the the the answer today is that it's still a lot of work to do CICD with a power platform when you're not using GitHub actions or Azure dev opps tasks. The good news is I'm always surprised when I talk to people of how how not so good of a job we've done on communicating this right. We do a lot of things at Microsoft, I think just because we did it and we released. And there's a dock's article on it like people know, but there's something called the Power Apps command line interface or often referred to as PAC CLI, it probably should be called the power platform command line interface because it's quickly growing to have, you know, basically everything that you want to do with the power platform around Dev and ALM all wrapped into a single command line interface. And so if you if you've heard of it and you haven't looked at it in a long time, you probably think it's the CLI that allows you to build PCF components.

Right. Because that's that's how it was introduced. But if you actually go look at it now, it's got actions for environment lifecycle management. You know, it's got Verves??? For Environment Lifecycle Management. It's got things for portals coming. It has things for solutions. And it's continuing to grow out to be both the CLI tool that developers use, but also the CLI tool that you can use for automation, of all things, power platform. And in fact, if you look at the GitHub actions, the source goes out on GitHub. Right. It's essentially. They're essentially wrappers around the Power Apps CLI. So everything that can be automated from GitHub actions today and everything that will be able to be automated from Azure Dev Opps tasks will all be backed by PAC CLI. That's the first place all the work goes. And so and PAC CLI is dot net full dot net framework today or dot net framework. Not dot net. Right. If you're following dot net terminology, but eventually it will be run on on dot net five. Right. And or dot net core and then eventually dot net five et cetera. Dot net six as time goes by. But it'll be a cross platform CLI that can be used from any OS that that dot net supports. And then from there the story becomes a lot easier for somebody who's using something other than azure dev ops or or GitHub. The short answer is everything that we do on our GitHub actions and Azure dev Ops tasks are embodied in the Power Apps CLI and so it's a will be a lot easier to use those things from from other platforms and not be operating system specific.

But it sounds like that utopian future some distance away. So in the meantime, you better just to hop on the azure dev opps or github bandwagon. Yeah.

So it's not as far away as you may think. There is active work going on to get to that end state rather quickly. And so I can't give dates, but there's work going on right now that that we've accelerated internally to get to that end state. And so I don't think we're as far off. I'm being very wishy washy intentionally, but I don't think we're as far off as you think. Like if you need to do something right now azure dev ops and GitHub are your your best places to be productive. Right. If you need to use other automation technologies, you know, there's a lot more there's a higher level of effort to do so. But that level of effort will be greatly reduced in the coming months.

Probably thinking about, you know, broad adoption of these new ALM patterns and practises. It seems like quite a steep learning curve, particularly for citizen developers. Are there any training resources that I can go to and take part in a training course? I even had a quick look at the some of the Power Apps developer examination syllabuses and training courses. There's very little ALM content in there. And if I'm new to pull requests and repos and pipelines and builds, it's just there's a whole new world of terminology alongside all the power platform terminology that I'm learning just to build the apps. Where's a good place to go for particularly for citizen developers to learn all this jargon and how to put it into practise?

So I would say there's not a great single place to go today. That is that is something that we will try to help solve through the ALM accelerator documentation, because to do the advanced ALM stuff, you have to know solutions. You have to know Git you have to know, build and deployment automation just to simply use the advanced, you know, maker application. Right. Because like you do pull required. You submit code to Git yourself right. It's a gesture that you do through a canvas app. You submit, pull request yourself as a maker. Right. Again, this is the the app that doesn't attempt to hide any of this from people. Right. You need a branching and merging strategy. Right, where we're sort of we'll document ours and kind of give you some sense of what we do. But we're we're not forcing you down that strategy. Right. We're hopefully providing an accelerator that allows you to kind of take what we've built and adjust your strategies to it. So we are looking to help say, look, this is what. You need to know and here's some ideas of some things to go look at, right? So, for example, you have to know solutions and you have to know solutions, fundamentals. And frankly, for citizen developers, solutions are still challenging. There's work that we need to do. And as the platform teams need to do in the maker experience teams need to do to make solutions more approachable to the citizen developer.

We still in powerCAT run into a lot of customers where they've essentially broken themselves into jail using solutions because they didn't stop and learn solutions and some of the intricacies and nuances of solutions. And so they've created dependencies and their solutions and they have problems importing solutions into downstream environments and updating solutions because they've created across solution dependencies, et cetera. And so, for example, Phil on our team has done some work around some quick-hit videos to sort of learn solutions, fundamentals quickly. And so the way we think about it is we want to kind of point people to the fundamentals that they need to know. Very quick hit learning and then here's more detailed information and really sort of put together almost like a learning syllabus that says, hey, if you really want to be successful with this accelerator or that accelerator app, here's some things that you need to know. Go go pay attention to that stuff first and then start using it. And so we anticipate citizen developers will probably start with this app. It's geared more towards the citizen developer, but eventually want to do more advanced things. And sort of the statement is there's only so much so many advanced things that you can do when you're hiding all of the the what's going on under the hood.

At some point, you need to kind of learn what's going on under the hood and graduate, if you will. And so our goal is to create some documentation and guidance around helping people ramp up on those things. But that's one of the big problems today. Like when I work with customers, like I have to tell them, go watch this video, go watch that video, go, you know, take this Microsoft learn course on get fundamentals. And so the resources are growing, but there's no consolidated places to to kind of learn how to how to do it all. And so we're hoping in short order after we get our V1 release out to get documentation to help people with that. But candidly, as we go into public preview, our focus is really getting our V1 features out the door and then helping people. And so those V1 features will be for people who already know this stuff, like for for V1, it's really about catering to the audience of people who already know these technologies and just want to to use them in a more productive way and then hopefully in short order. One of the things that we will focus on is helping people who want to learn these technologies to get that to that more advanced ALM world faster.

So I think there's a great opportunity there for MVPs and there's a number of MVPs who produce online training content. Absolutely is an opportunity there. Phil could have done it, but he was only an MVP for 10 minutes before Microsoft hired him. So give us a bit of a gap there. There's even some Microsoft documentation on solutions that says you can just customise the default solution like, oh, my goodness, it's it's not that there's four options. And that's number one. I would get rid of that one

That you made a good point about, like existing content out there. Like one of the things that we want to do by making a public GitHub repo, sort of a rallying point around, you know, the work that we're doing is that we want other people to say, hey, I already have a walkthrough of fundamentals here. Go watch it. Right. Like we don't mind referring to when we want to refer to community work that's already been done. Right. So, like, literally, we're going to have guidance in docs that Microsoft dot com. But if that guidance includes pointing to a video that Scott Durow did or something that you did, or that's fine. Like we don't want to reinvent the wheel. We want to kind of pull things together in a way that, you know, existing assets can can be benefited from. Like certainly like if you think about power platform build tools versus the great community work that Wael Hamze has driven for years now. Right. I was a contributor to to that. At one point I wrote a couple of the tasks. At one point our goal is not to sort of compete. It's a recognition that customer Microsoft customers want things from Microsoft. Right. And so the work that that has been going on around ALM is to try to meet that that expectation of customers. Right. But ultimately, we want to embrace the community. So the ALM starter kit is the the first step.

The GitHub actions being out on a public GitHub repo was the first step. The ALM starter kit is another at the right point. You can imagine the power platform build tools. Tasks will be in a public GitHub repo as well. Right. And then it creates this sort of snowball effect if you will. Right. We want to get to a place where. The community can contribute to the things in an open-source fashion as much as possible, including things like GitHub actions and power platform build tool task. I mean, if you go to the GitHub actions project today, you'll see a statement. They're not accepting contributions. That's not the long term goal. Right. The long term goal is to accept anything that we're doing in an open-source. Fashion is to accept contributions and such that like everything that's been done and all the lessons learnt and all the years of all the hard work that people have put into other community projects. Right. If people want to, they can bring that hard work into the Microsoft project that more and more customers will use because it's Microsoft branded. Right. Microsoft ensures the quality of it, et cetera. But you can contribute to those things. So you can imagine a day where we don't necessarily have all the tasks and actions coming from Microsoft. And they're still and, you know, there's some great task and action actions. And while this project. Right. Somebody chooses to take that what they've built over there and bring it into our public repo and before you know it, like everything that's it was over in that project, which required community tools are now shipped through Microsoft with community contribution.

And now that's going to take us time to get there. Really is the long term goal, right? Is is increasingly embrace the community, because here's the thing. We're never going to be able to produce and innovate. You know, all the things that people want with the resources we have internally. Microsoft, we run pretty lean, right, as a company. And so community contributions is is is one way to innovate rapidly. Like even with the accelerator, we think about it like this. We've we started something, right. We've had to build the foundation. We had to build it behind closed doors for a lot of reasons. We were dependent on tools that didn't exist, like we've been using canvas unpack forever ever since. Basically the first build of it existed internally. Right. That we couldn't talk about that publicly, so we couldn't be out in the open. There were some known platform issues like canvas calling flow that have just recently recently been fixed like that. known issues list has been shrinking and shrinking and shrinking. So we didn't want to have an accelerator in the open. That was a showcase for all the things that weren't working on the platform. We wanted to have an accelerator that was a showcase for things that work end to end.

And so we've been doing all that sort of behind closed doors. But now is the time to get it out in the open, get it in the public and really start to ask the community to contribute, to take the accelerator to where we want to go, which we'll never be able to do by ourselves. But here's the other interesting aspect of it. As we've been building the ALM accelerator, we've been working with all the different feature teams that own ALM related capabilities across the platform. And we've run into issues and then the issues that we've run into, because our goal is to be a reference of how you can successfully automate end to end real-world scenarios. We've then driven that feedback into those teams to help them round out their issues. Now, when we go out in the open, the community will help that. Right, because what's going to happen is somebody is going to inevitably file an issue for the ALM accelerator that says this isn't working. And our response is going to be, you're right, it's not working in the platform. So there's nothing we can do in the accelerator to address that. But vote this up. We're going to go talk to the PM, who owns the engineering team that owns the improvement that will enable this. You're uploading will be a data that they will use to help their prioritisation.

We'll work with them. You know, they'll pay attention to the GitHub issues once they're they fix the thing in the the platform. We will then, in short order in the ALM accelerator, make sure that we're showcasing the end to end automation of the scenario. And it creates this sort of a virtuous cycle where what we've been doing with a small group of people trying to help get ALM to Green on the platform, like play our part in helping get ALM  to green, the community will be able to do because the most important blockers will be up without question, will end up on the ALM accelerator issues list and then the influence back to the future teams to prioritise the right work. The most important work, which as a feature PM is the hardest thing to do. You want to solve all the problems, but you've got this long list of work and the question is which ones do you do? It's like any backlog prioritisation, right? Which are the most important ones to do. Sometimes it's a guess. Sometimes it's based on customer data. Sometimes it's because the loudest customers are screaming the most. Right. And it's a it's a challenge. But at least we hope as as a CoE starter kit team in the ALM accelerator team, we hope to make that those issues a rallying point not only for the community, but then for feature teams to understand the demand for the improvements necessary to enable the scenario.

Ok, thanks, Marc, I really appreciate you coming on the show and joining us. A healthy application lifecycle process is critical if you're going to build amazing, agile, Dynamics 365 and Power Apps platform applications. I think it's great that Microsoft is finally providing more prescriptive advice for how to achieve healthy ALM and providing tools to help us get there. Better still, the Power Platform Customer Advisory Team is publishing their tools as open-source project on GitHub allows us all to raise issues and make contributions to our true set of global best practises and tools that we can all use in our projects. I might finally even get on board with deploying managed solutions in production. Remember, you'll find show notes at Customery dot com slash zero three zero and don't forget to subscribe to the Amazing Applications podcast and hear my Rapid Fire round with Mark. You'll be shocked to hear that he doesn't use Scrum or SureStep for managing product development and there's lots more surprises as well. Until next time. Keep Sprinting.