When Spending is Cheaper: The Value of Model Driven Apps & Dataverse

Intro

Are you a citizen developer, stuck in the muddy world of "free" office apps? Do you ever wonder how much of your budget is spent creating and caring for your internal apps and processes? Are you trying to figure out how to justify the cost associated with Power Apps licenses for your organization? Do you know if it's worth it?

When it comes to Dataverse and Model Driven Apps it can be hard to get past the license cost problem. If you want to find out how to get unstuck or if you want the ability to evaluate the investment the right way, keep on reading.

From Ordinary...

There are a bunch of tools and methods for building office apps. Tools like MS Access or Excel, SharePoint, InfoPath, and Workflow have been around for a long time and are commonly used in a wide range of use cases. Today, we have even more tools at our fingertips like Planner, Power Automate and Power Apps.

If you're like me, you may have experienced a progression through these tools over the years. Maybe you're still supporting some of the old ones. If you're going through this transition you're probably also attempting to migrate some of them to the newer tools. Replacing old patterns like InfoPath and Workflow with Canvas Apps, SharePoint, and Power Automate.

These tools are typically considered "free" options for innovating inside your organization or business. Many of the newer tools are better than what we used to have, but even these are not intended for higher levels of complexity, customization, or enterprise requirements. And so, we still need to contend with some of the same old challenges. Some, you may be familiar with:

Item level security configuration on a SharePoint list is not very useful beyond restricting access to creators, which is a very limited definition of ownership. Attempting to get past this limitation might mean applying a scheme in a Canvas App, but the back door (SP List UI) is still open.

SharePoint list data relationships (lookup columns) are not automatically incorporated in your datasets.

The extra work required to facilitate multiple versions of your app (DEV / TEST / PROD) because Application Lifecycle Management tooling for the "free" tools simply doesn't exist.

Business rules are difficult to apply and control when users have multiple different data entry points. For example, SharePoint list items can be modified in grid view, on a custom form, in the info panel, etc. This is also a security hole by the way.

You still have to put quite a bit of effort into managing basic CRUD functionality. Often you have to implement your own schemes for handling form validation, unsaved changes, dataset refresh, and delegation warnings.

...To Extraordinary

But if you're like me and enjoy learning, acquiring new skills, and just finding a better way, you've probably looked at Model Driven Apps.

If you are fortunate enough to spend some time in the world of Model Driven Apps, you will discover a new world full of wonderful features and skills that you get without even lifting a finger. I'm going to call out only a few of my most valuable picks, but the list is long.

Based on my experience, the biggest wins for this data first approach are:

Create, Read, Update, Delete (CRUD) - DONE! Everything for doing all the basic data operations is done for you.

The UX / UI is not a concern. Established modern UX and UI patterns are in place and there is no need for any UX or UI design. Both mobile and desktop layouts are supported in a responsive way and it just works. This is usually more than adequate for the majority of business apps.

Role based security allows you to easily define user permissions for CRUD operations, form access, and more based on assigned roles.

Record ownership lets you easily get down and dirty with row level security in ways far beyond the simple item level security features of SharePoint. Tables can be defined with Organization, Team, User ownership, granting specific permissions to individual records based on a user's relationship with or association to a given record.

Business Rules are baked in at the table and form levels and allow you to configure (not code) things like field visibility, field status, and even field values without making tweaks at the field control level.

There are numerous other "built-ins" like... record navigation, drag & drop navigation, configurable forms & views, personalization options, bulk edit, data import & export, support for common business scenarios like call tracking, email tracking, tasks, appointments, work queues, etc. but we can stop there.

As a developer, once you see these things in action, the trade-offs become readily apparent. In applications where you have multiple related data entities, even if you only need a few of these features, having them out of the box will save tons of time. And this time is what adds up in total cost of ownership over the long run.

😬 But You're Stuck

The challenge in this transition is most organizations fail to count the true cost of the "free" tools. We often don't realize how much we really spend in terms of real resources or opportunity cost. When you try to move from the old approach to one that requires some paid licenses, you get stuck. There is no budget for new licenses.

You're not alone. Many developers find themselves here, stuck between a rock and a hard place. Developers in this situation often are being asked to push the limits of the tools, bending, and twisting them to do things they are not designed to do and in turn creating a future full of extra maintenance and bug fixes.

The failure here is the assumption that all those apps you've been using are really free.

Why Does It Matter?

Unlocking this capability for your business apps is important for three big reasons.

1. Boost productivity and accelerate timelines. With so many built-in features, you will build more apps in shorter timelines. Instead of a prototype Canvas App in a day, how about a couple hours? Be ready for launch in 2 weeks instead of 3 months. Fix issues and adjust features in a matter of minutes or hours.
2. Better quality of life for developers. Let's face it, if you've had to twist SharePoint to do something it's not well designed to do, you felt a little icky about it. And every time you need to make a change, you are reminded of that workaround that didn't feel right. In addition to leaving that mess behind, you get time back to iterate on new ways you can innovate and use the technology to make a difference for your team.
3. Secure your data. Since security roles, record ownership, and permissions are central to the design of Dataverse and Model Driven Apps you can secure your data and processes in a way that is scalable for your organization and keeps the back doors closed.

Three Critical Practices for Your Journey

As stated previously, most organizations aren't good at figuring out what the "free" apps really cost. So then how do we get unstuck if we've been met with the license cost objection? We need to take a different approach and fix the math. As a developer, here are three things that you'll need to start doing to get past the roadblock.

1. Recognize that apps without licenses are not actually free.

You need to change your mindset, and the mindset of your leadership team and decision makers so that we first think about total cost of ownership and recognize that there is still cost, even though we don't pay for a license. We must shrug off the idea that building apps the old ways, or even with Canvas Apps is free. It's not. The reality is an employee is being paid to implement and maintain these things. Too often this cost is simply ignored because it's baked into a head count. Once you start estimating or tracking this, you have something real to use as a comparison in the next step.

2. Change your cost equation and use license cost + cost of implementation + cost to maintain.

Be real about budget and time spent on building apps and move beyond the dollar signs you see on a license fee. A lot of the pushback I see comes from people who say they "can't afford a $5 license for every user in my org, I have 1000 employees, that's 5k per month / 60k per year, that's too much". This is an easy objection because it identifies a specific and easily computable cost that didn't previously exist. The problem? It completely dismisses any cost associated with building and maintaining the app. And beyond that, it overlooks the opportunity cost associated with the resources tied up in delivering the app. If you factor those things in, is the new license really too expensive?  

3. Use an efficiency factor of 10x when assessing building with Dataverse (MDA)

Of course, this may go up or down based on complexity, but this is where we start. Don't believe me? Here are some specific examples where you will experience this improvement:

• Applications with multiple related data entities: In applications where you have multiple related data entities, having features like built-in record navigation, CRUD operations, role-based security, and record ownership out of the box will save lots of time.
• Applications that require security and permission management: The role-based security and record ownership features in Model Driven Apps can make managing permissions and security for an application much more efficient and streamlined. In short, you don't have to "roll your own".
• Applications that require a high level of customization: The drag and drop navigation, WSIWYG configurable forms, and views in Model Driven Apps make customization much easier and more efficient compared to implementing the same types of things in a Canvas App.
• Applications that require business rules: Business rules are baked in at the table and form levels in Model Driven Apps, allowing you to configure things like field visibility, field status, and even field values without having to write code. Implementing the same type of thing in a Canvas app requires you to do it at the field control level.

Lastly, there is one more flawed assumption (kind of hidden) that I need to talk about before I'm done. That assumption is in the "1k users = $60k per year equation".

When someone raises this objection, I can't help but think if you have 1,000 employees and business is good, that the objection to $60k isn't really an objection about it being too expensive. It's really an objection like, "I don't have that in my budget, and I'd have to go ask for that...".

I think that if we're using the right mindset, then we should be considering ALL apps that we build in terms of investment and the associated value. When we do that, then we can start to talk about real budgets and real value for All the things we build. After all, that's the right conversation to have.

In that respect, even ChatGPT will give you a range of revenue per employee, dependent on industry, and size that's $200k to $500k. I have to think that the $60k license objection melts away into a line item when we're talking about $100,000,000 on the low end.

Conclusion

If there's one thing you take away from this, it's that you shouldn't let a Model Driven Apps & Dataverse approach be dismissed simply based on license cost. If you're stuck here, peel one more layer and adjust your mindset. You can easily connect some dots that will reduce the cost of building apps, improve the developer experience, and accelerate your ability leverage technology in your organization.