Shadow IT powered by Power Apps

It's been a few months since posting having been struck with the spicy flu and several other coughs and colds. But given the surge in celebration of Power Apps, I think it's time for an 'Old Man Yells At Cloud' rant.

Over the last 12 months or so, when I log into LinkedIn - I can be assured that every other week someone else is celebrating a certification in Power Apps or want to showcase how they built an awesome COVID-19 contact tracing portal / timesheet solution / seat booking tool / leave application form or any other simple to moderately-complex form - all thanks to the wonderful Low / No Code product known as Microsoft Power Apps. As a software developer who began his commercial career converting Bob's spreadsheets to C#, Jane's Microsoft Access databases to ASP.Net Web Forms and Joanne's Frontpage sites to <insert your favourite CMS here>, this really has me baffled.

Power Apps presents itself as "Macros and VBA" projects in the cloud. After all, it's attempting to solve the same problem that Excel and Access have served well for decades by creating exactly the same problem - enabling several "Shadow IT" departments to form within your organisation by empowering power users with the ability to rapidly write their own custom solutions to solve "complex business problems". During the 90's and 00's where rapid application development was a priority and software development practices for internal business solutions were still maturing, this might well have been an acceptable compromise. But as those who have been instrumental in converting those little golden nuggets of business continuity would know, having Jenny from accounting writing her own expense tracker or James from Asset writing their own inventory tracker opens you up to all sorts of data governance issues, clones of functionality producing differing results, impossible-to-solve help desk tickets and in some extreme cases - invalid answers from erroneous formulae. So then, if we have developed many best-practices for software development, building governance frameworks to prevent the sprawl of bad coding standards, having a much larger focus on building secure software workflows, why are various IT management-type roles convinced enough to encourage the business to pump out several 10s of magnitudes greater single-purpose and crazy UI experiences in this new world?

To understand how it's happening, you need only look at Microsoft's marketing for Power Apps. It's spot-on for convincing management types through promises low or no code solutions - all in the cloud with no infrastructure to worry about - so you can get on with your job of looking after... well, not quite sure what if you've just moved everything "to the cloud". You'll create visually beautiful* applications in substantially less time than it'd take to spin up a custom software development project (this is true!). You can use a bunch of pre-defined controls and templates to quickly produce applications that integrate with various connectors - usually SharePoint Lists, Dynamics 365 and / or SQL - but there's a couple of hundred premium connectors that probably do 50% of what you need it to do with any sense of performance. You'll be able to take advantage of the security provided in those platforms and get all your power users on board and best of all - you need not worry about it, it's all managed - right?. Whack a login page on your app and you're set. Sounds absolutely fantastic - no need to run complex development environments, pay for compute and data storage infrastructure and solve all problems as if it was an entire IDE designed for large complex enterprise applications.

What isn't mentioned until you start delving through licensing is that unlike your typical pay-per-developer seat or application license, you're paying per consumer. $5 USD per app to be specific (or $20 USD if you want your consumers to access any number of apps from your library). To be clear - each form you create, each dashboard you present - they're encouraged to be a single "App" that will appear on your Power Apps list. At $60-$240 USD per year, you'd want to hope the large majority of your user base is taking advantage of that large library of apps you're building.

And what about those promises? If low to no code is what you're after, then you'd hope that much of desired functionality is out of the box. To be clear, there's three ways of building apps and perhaps the most popular way is to use Canvas. As you go about your business of dragging and dropping the typical controls you'd expect to find in an IDE, you might come across a situation where you have some tricky show / hide business based on inputs from other fields. You can use natural language to help you out, you can write custom code to do it. Either way, you're encouraged to write spaghetti when a typical development language might allow you to use variables and other "SOLID" principals to achieve the same far more elegantly than those years of horrible SSRS hacks (remember those?). And let's say you've created one formatting function that you'd like to reuse in 10 of your other apps? Well, you can do that if you create a custom function component as described here and include them within centralised libraries - yet it all seems strangely over the top and requires your power users to be familiar with these concepts without being developers themselves. I'd nearly expect too that due to the lack of intuition in encouraging new users to compartmentalise their software and relying largely on business power users to build apps, that your Component Libraries section will be empty (or certainly close to it!).

And there in-lies one of my critical problems with encouraging power users to build "applications" - who is Power Apps for? If it's for Stewart from Legal to track his clients, Stewart is very unlikely to realise that things like central libraries exist - so he'll go on to make some pretty horrible (by software development standards) apps that will become crucial to his own workflow, because he is not a developer nor should he be expected to understand the intricacies the rest of us learn by dedicated work. If he leaves, who picks it up and runs with his app? It doesn't follow any standards, probably has zero documentation (have you tried putting comments in a Power App?) and might well fall subject to "it's too hard, it'll be quicker for me to rebuild it". If it's your own IT team? Why would you want to add the burden of managing several small business applications in this manner over carefully planning and designing these processes as part of your larger CRM / ERP? Why would you want to run a project that has little to no documentation, very simple source control (if you're lucky!) and individually tailoring custom functionality for each of your users?

There's obviously a lot of assumptions about the kind of users you might have in your organisation above and there's definitely use cases I can see where it might work - especially small businesses to suggest these little forms might well be affordable and useful to solve minor problems. In large enterprise, it can help offset development tasks for those side activities and short-lived projects. There are several MVPs who showcase and empower users to look at the things they can create, so there's certainly a thriving user base to solve problems with - albeit usually simple imitations of commercial SaaS or COTS products. Need a Kanban board? Go and get yourself a community Azure DevOps, or sign up to Trello. Need a Help Desk solution with solid workflows? You'll typically pay per Agent for Zendesk and come in at under $100 USD per user per year. COVID-19 contact tracing forms? Sure there was definitely a use case in the early days yet there are several Github projects later and vendors selling or providing free SaaS solutions for that too - and you wonder whether that investment was genuinely worth it (in Power Apps, not the end result).

From a UX perspective, this is another area that requires years of experience to get right. It's fair to say a large majority of users wouldn't pick these up as concerns, but putting a designer hat on - my OCD goes off at nearly every Power App I see. Power Users by and large do not understand the reasons grid frameworks in web design have been the bread and butter of responsive design for some years. While the IDEs attempt to anchor controls in some sort of uniformity, it's also too easy to ignore what all those snaps and anchors do creating very offset controls, stupidly large textboxes on a 4k screen, inconsistent typography, inconsistent whitespace, lists that perform woefully without data virtualisation or pagination, and that dreaded Comic Sans use pops it's head up from time to time unironically. The list goes on... it's just too easy to produce these cardinal sins of the responsive web world.

Then there's perhaps the most important topic of this decade - security of your data. Specifically when using SharePoint Lists - because nearly every example uses it. It's not a new problem to see tickets about being able to see other user's data because the original author of the SharePoint List was unaware of the security controls within SharePoint Lists, but when your business users are empowered through those 'community of practice' type material and build data sensitive applications - they can't possibly be thinking about security in a Power Apps flow if they've never been taught anything about security in the first place. After all, they're using a Microsoft product so it must be secure by default? Yes, we put a login page through the Azure SSO connector - but that SharePoint List we use did not factor in the various user accounts that we tweaked along the way that meant literally everyone in the organisation can see sensitive information. In one extreme example, an 'app' configured a record to be openly available for Read / Write activities as part of an Automate workflow because the author was unaware of secure ways to achieve it otherwise. It makes sense as to how the author got there - hack about, make it work and publish. It wasn't until entire lists of personal data were visible before it became an issue.

Despite all the promise of empowering business users, corporations with ISVs willing to consult for large exorbitant fees - at the end of the day, it's your own IT Support team that will start fielding new types of queries about how custom unknown code isn't doing the thing that can't be explained very well. So you go and train your own team to learn about this new platform just so you know a little bit more than the author of the problem. We can all sit around and celebrate how none of us really know what's going on and that we can kind of make it work - all without bothering your software development team.

So why does it drive me insane? At some point, there are going to be hundreds of applications with dubious user bases and data criticality. At first, things will seem easy - until there's customisation required. Some of those applications will go on to contain interesting and useful business value data. Other users will start to manipulate that data and rely on it for their own particular business problems. In a world where strong data governance is at the forefront of most IT strategies, Power Apps seems like one of the biggest antipatterns to emerge from a company all about promoting data governance as a critical component of managing your Azure deployments. And before you say - "well, didn't Access and Excel do the same thing? At least it's all in the cloud now and not on some laptop HDD" - yes, you're absolutely right. But we also spent literal decades trying to discourage that sort of ad-hoc development. But here we are, chucking out Excel and Access, and encouraging power users to double down on building more complicated things using more complicated processes without training using whatever spaghetti they can cook up.

And - I guess that's why I can see my future of Continuous Employment by rebuilding (or suggesting how to rebuild) parts of these as fully-fledged and proper SDLC delivered projects in my future.