I give lots of credit for the folks doing Power Platform videos on YouTube. I too sometimes grab them as a reference. However, Shane Young did a video a few days back that was just terrible. My comment in response to him was a little snarky (which he left up and responded to), but then I went into detail of why his delivery on this was wrong. That comment was deleted (not by me).
So here is my own version of his terrible take on: the best datasource for PowerApps.
To just jump to the answer, it is SharePoint.
I'm sorry.
Overview
Just to get this out of the way, this is the video, and here's the comment that was deleted w/ the original context:
 |
| Truth often hurts |
Shane's answer is Dataverse. Shane is wrong. Completely and utterly wrong. He (and Microsoft) want that to be the correct answer. It isn't. Yet. Potentially never will be.
His answer is bad and he should feel bad.
The Best Datasource for PowerApps is: SharePoint Lists
- It is free (well...included w/ your base licensing)
- It is reliable (as in it is Microsoft's problem to keep running and not yours)
- It is functional...enough (in fact, you should stop yourself from using most of its functionality)
- It is fast...enough (meaning there is a little work to do here for optimization, but it gets the job done in a reasonable fashion)
- It is free (worth mentioning twice)
SharePoint Lists are reasonably simple enough for some minimal training and review to allow anyone to spin up a secured datasource that is reasonably optimized in a few minutes. The knowledge gained even in this simple task also directly benefits people that same day in being able to better understand the Teams/SharePoint ecosystem.
Could it be better? I cannot capitalize/bold this word enough: DEFINITELY. However, this is the question of the "sweet spot" for knowledge and audience. Not padding Microsoft's quarterly revenue.
However, let me caution you, the criteria I use to assess the "best datasource" is tightly wrapped up in what PowerApps and "Low Code" is supposedly about (even if it is just marketing: The Democratization of Code.
I always follow the belief that the best solution is the one that gets us all aligned on core secured technology w/ minimal training so that we can start creating value today vs. tomorrow.
Given that I work in healthcare, I hope you all appreciate that I would rather my organization fix your broken leg today instead of 6 months from now. While I also would appreciate the counter-argument that one would rather their physician have years of training before operating on you, on that we agree. But as technology allows less trained staff to perform more common procedures for far lower costs...
Who is Doing the Work?
Democratization of Code means that everyday staff w/ minimal training will not necessarily turn into full-time developers. Also, that they should be able to assemble applications and datasources w/o the full engagement of purely technical staff. Finally, this is knowledge that shouldn't take a long period of time to acquire because people are still doing their day jobs.
This is the reality of Low Code, if believe the concept of code democratization to be true.
Democratization of Code isn't about doing one application "really well", it's about doing thousands of applications in a mediocre manner. Yay Democracy!
If we truly believe that we can flatten the curve of development in this way, then anything that causes our everyday developers to deviate from their day jobs without clear immediate benefits is suspect.
People need to keep doing their normal jobs AND do some occasional coding. This means that knowledge retention will be quite low unless the specific information they gain can in some way relate to their day job.
Getting from Excel -> SharePoint Lists
Someone might believe that my above section is actually arguing for Excel. After all, it is what virtually every department uses as some form of datasource. As well, it is the source that Leadership teams still cling to.
However, there are already numerous tools/reasons for moving data in/out of Excel/SharePoint. Even simply live-linking your Excel tables so they can be easily refreshed from SharePoint is something that anyone can set up in minutes (although it should definitely be simpler to manage after creation). It lets leadership keep their Excel files while giving a regular worker the ability of guiding them toward better datasources.
Leaders know they "shouldn't be doing this in Excel", but it is the tool they have. Slow-walking them to a linked Excel file they can update w/ data while not directly corrupting the data actually does make them feel safer and that they're on a journey to better practices. While of course, they still get to use Excel.
Therefore, the leap from Excel -> SharePoint is pretty small and something every organization needs to do across all departments.
The Day-To-Day Benefit of Understanding the Teams/SharePoint relationship
Teams and SharePoint are inseparable today. At its heart, Teams is a simplified way of utilizing SharePoint resources. Certainly it can do this for other resources, but SharePoint is the foundation.
Creating a Team creates a SharePoint site and adds Team Members to roles for that site as either Members or Owners. It cuts through most of the complex SharePoint security model to simply say: are these people who can do anything or people who can do some things? Then it also makes some assumptions about what those "some things" are.
Lists contain data, and data conversations cannot be had without discussing security. This simplified model helps solve for the #1 thing that an amateur part-time developer would screw up. Nobody can see these Lists and the data within it unless they're a member of the Team (by default - of course you can change that). So it solves the most common mistake for amateurs simply by building your datasources within the Team environment created by default.
Doing the same thing on SQL Server? Yeah. No. You're going to need a specialist. Dataverse? A higher paid specialist. Plus you get to pay Microsoft. Yay capitalism!
Teams is now in use in over 90 of the Fortune 100 companies as a core platform. Anything that helps you do your everyday job better by understanding the Teams/SharePoint relationship better will also play out w/ benefits across the board of people's day jobs.
So doing this pays off today, tomorrow, and forever as long as Teams/SharePoint remain a thing.
Bigger is Not Better
If there is anything I am known for within our organization on how to utilize SharePoint, it is for me telling people continuously to STOP USING SHAREPOINT'S FEATURES!!! Don't build out Choice columns. Avoid even Date/Time values unless you're 100% certain you definitely need to sort/filter based upon it. Change that Title column from Required and probably even just hide it.
NOTE: The one feature I do suggest using is setting indexes on the columns you know you'll use for sorting/filtering.
I am always trying to get people to dumb down their SharePoint datasource because for the most part, it:
- doesn't help people with their daily work
- is SharePoint specific
- makes it harder to build applications
Unless you are definitely planning for a large # of people to be managing their work by directly updating data within the SharePoint List in SharePoint or Teams, then you should seriously dumb that datasource down as far as you can manage.
Part of this is allowable because for most applications done in Low Code, the amount of data is smaller and/or less complex than we would normally encounter in a more traditional application. Therefore, our datasource should reflect that. Don't create work you do not need to do (yet...or possibly ever).
It is an assumption that relational database platforms like SQL, Oracle, etc. are required for any application. For Low Code, the best thing we can do is to simplify our data structures just like we do our code.
For most applications I think having an "active" list of data and an "Archive" list of data is the primary need. Everything we're doing now is in list #1 (active) and everything we're done with and is out of our window of generally caring/responding/reporting on for the day-to-day work is moved to list #2 (archive). That's it.
This isn't to say that of course you could still do more traditional apps w/ traditional datasources (like Shane's suggestion of using Dataverse). However, if you are embracing Low Code, then you are embracing Low Complexity and Low Training. Dataverse is neither of these and therefore, in some respects, an even worse choice than Excel.
Think about that for a moment.
No. I'm serious. Go back and read that paragraph and really consider that last sentence.
Anyone can understand Excel as a datasource (even if it is just completely terrible when used as such), however it requires lots of baseline knowledge of databases and product-specific training to understand Dataverse. As bad as Excel is as a datasource (and it is terrible), anyone can understand how to use/apply it properly in minutes. So what fits "Low Code" better?
I feel extra dirty just typing that last paragraph out. Again, the truth hurts.
The Compromise of Delivering Solutions Today vs. Tomorrow
If you invested a ton of time/energy/staff into training on and properly utilizing the complexities of Dataverse, you can get some notable benefits from it. From a data migration and reporting perspective, it is TECHNICALLY a better datasource than SharePoint. However, committing to the longer-term future benefit plan (that may or may not ever arrive) of a more managed platform , is arguing that future profits are better than current ones.
There is no doubt that we're creating a backlog of data that will...someday...perhaps...need to be optimized because it has grown unmanageable. That is definitely a FUTURE we can plan toward while we recognize profits and optimizations TODAY. In fact, recognizing those profits today does allow us to AFFORD TO DO THIS TOMORROW.
Traditional Development is done because we recognize before we start that we're going to need to optimize this data/application almost immediately. The risk for failure or down time to these kinds of applications is large, so pre-planning on this is required.
For Low Code, we're instead focusing on modest broad-scale optimizations using a common sub-optimal tool that can be optimized at a later date en masse, or more likely, simply exported out and archived. There is no need to optimize the data storage (beyond the basics) for an application that will run for a few weeks to gather information and then shut down. Almost anything beyond a CSV at that point becomes overkill.
But Why Did Shane Say This?
I don't know Shane personally. But I do know that YouTube rarely pays the bills. His work is good in that it promotes PowerApps and explains how to do some things. But let's be clear, Shane is selling the services of his organization. Full stop.
Choosing an overly complex data platform will require more specialized resources/staff. Staff that your organization is unlikely to have in-house. Staff that Shane's organization provides.
As well, Shane is a Microsoft MVP and his current income is tied to their good graces. If Microsoft says "here's $1000 for a video telling people to promote Dataverse", then I don't think that goes against the profit motives for Shane's team. In fact, it is completely in line with that.
However, again, I don't know Shane. Although I do know that my dog's cooler.
 |
| Maisy prefers her Beyer Dynamic's for PUG matches |
I do believe that this is just one of those situations where you get yourself all wrapped up in your own PoV. Shane's excited to be using Dataverse and wants to keep using it (because it is complex enough that you need to keep that knowledge fresh). Shane's excited to have Microsoft on his good side and Microsoft is excited to make me pay them more money. None of this expressly has to be nefarious.
Except for deleting my comment I guess. As I mentioned above, the truth sometimes REALLY hurts. Hard enough that you don't want to see it on your own video feed.
Final Thoughts
This is just my initial regurgitation of this since it's the weekend and I found some time to get this out. I will do a longer writeup on some basic design principals that include spinning up a Team, setting up the Team Members, configuring your List(s), optional securing of your lists, etc. However, I just needed to get this out.
The lack of context in what defines best is always a problem. Anyone who has done any purchasing in their life knows that at a minimum we are comparing:
- speed of delivery
- quality
- cost
These kinds of mistakes are made all over the place when we fail to recognize the cost/benefit of each choice on how we design solutions. We have to consider the people doing the work, the cost of their time, the value in training toward value creation tomorrow vs. the value of acting today. There is a balance here that we always have to strike.
Given that Low Code is about Democratization, about growing our base of semi-technologists who can deliver value at the edge, about these actors picking up skills that they can use in their day job, and about learning to deliver better overall business outcomes, SharePoint is a natural fit. It provides the correct balance of complexity, security, and reliability for delivery in this space for the vast majority of projects/citizen-developers.
Even if past me would absolutely hate admitting that.
Please give future me a better option. Pretty please? Anybody?
No comments:
Post a Comment
Because some d-bag is throwing 'bot posts at my blog I've turned on full Moderation. If your comment doesn't show up immediately then that's why.