Code First Futures
This week I will be going over one of the newer ways to build enterprise applications on top of Microsoft's Power Platform. But before I begin, I think it's helpful to recognize that there are some common misconceptions around "no code" or "low code" that hinder its adoption at most organizations. Let's start with a simple image of Microsoft's products in this space.
Dizzying, right? Getting up to speed on what fits where - on how these tools work well together, could take weeks or months. Of course, you could just read the website to learn about each item - or even peruse one of my earlier posts on Power Pages.
So what is, "Low-code", exactly? The easiest way I explain it to customers is that all of the infrastructure that developers took for granted when they wrote applications in the past is no longer necessary to develop an application that solves a business problem. From servers to security, computer languages to IDEs - much of the cruft required to write a proper application has simply disappeared as the cloud has matured. Within minutes, I can automate with Power Automate without needing to know anything other than how I'm logging into the system. I can get rich insights with Power BI by simply authenticating to my work CRM system and pulling the data out.
The challenge, of course, with low-code is two-fold: because writing an app is so easy, it can become equally easy to forget who is on the hook for maintaining an app once it has been written. The second issue: what happens when your app, which was deemed "frivolous" becomes "businesses critical" because of its use? Suddenly all the traditional software development questions that were irrelevant earlier (because if your app broke, folks could simply go back to using the manual method, right?) suddenly assume an air of great significance, including:
Inevitably, for all but the simplest of scenarios - these sort of questions surround every traditional app. Low-code is no different - which means that you still need developers and partners comfortable working with an application lifecycle management model (ALM).
领英推荐
Let's dive into the new experience that is using the Power Platform with GitHub Codespaces. This experience is a great reminder of the transformative power of the cloud: most developers begin their work by cloning a repository. It's been that way since distributed version control systems displaced their client/server based forebears. but with Codespaces - instead of cloning items one can simply fire up an IDE and begin to work.
The first steps for many developers are to log into GitHub, clone the repository, and start working. With Codespaces, one simply selects "New codespace" instead - and GitHub creates the appropriate area inside of your development environment in Visual Studio. From there, you can install extensions into the virtual version of Visual Studio Code just as if you were doing so on your normal desktop. Because we're talking about connecting to the Power Platform, we'd want to install the Power Platform Tools extension. It's smart enough to even detect that it is being used inside of Codespace.
Next, you will authenticate, likely using a device code in your web browser, and then sign into the Power Platform CLI. This trivial process can be repeated for your test environment and your production environments. At this stage, you'd have a dev, build and prod environment ready to work. From here, the standard development tasks of building out folders to contain the solutions takes place, just as it would when using a regular repository clone.
Now its time to write some code. Whether copying from another control or writing from scratch, this process doesn't differ from what most developers are used to. Once built, it's easy to run the control and validate it works properly. From there it is quick to build the up into a single zip file. Using the CLI, you can now simply run an import command to bring the zip file into the dev environment.
If you've made it this far - and you are not a developer, you are probably thinking "this process sounds quite complex". ALM isn't for the faint of heart. Yet for developers, this entire process is so much quicker and less brittle than the development environments of the past that it is almost revolutionary.
And that is the key distinction - if you're thinking of using low-code solutions in your organization - but you aren't thinking about ALM, then you need the help of a partner or your internal development team to take an outside role. Although Steve from accounting could make a PowerApp that shaves five minutes off of his daily tasks - if you want to turn that application into something that is used company-wide - you have to start thinking about the ALM questions above.
Your internal developers, or your partner, however, should already be comfortable working in this low-code environment. For them, it allows them to deliver value to you, the business, more quickly, at less cost, with less security challenges and resources used. The low-code of the future is far more impressive than it was even three years ago.