Going From Low to Pro: Applying Key Software Design Principles in the Power Platform

Intro

The rapid rise of citizen development is transforming business users into app developers overnight with no code or low code platforms like the Power Platform. But beware: skipping essential software design principles can lead to chaos and frustration! Discover how the mindset behind the Single Responsibility Principle (SRP) can save your apps and boost efficiency in this must-read post.

Why This Matters

The software developer workforce is not the same as it used to be. Today, almost anyone can create an app. For years business users have used tools like SharePoint, Access, and Excel to build functionality that easily qualifies as a business app. Today's citizen developers have even more powerful tools at their fingertips. But still, citizen developers tend to be subject matter experts (SMEs) rather than formally trained software developers or "pro-devs".

Having "pro-dev" skills is not solely about languages and frameworks like C#, .NET, JavaScript, React, T-SQL, etc. There are a bunch of principles that can be applied to make software easier to build, more manageable, and more reliable. When we build no code solutions, we don't have to think about the code. But the ideas and mindset behind these principles are every bit as applicable in a no code solution as they are in a "pro-code" solution. The problem we face right now is the no code / low code movement has caught like a wildfire and these guidelines are not being talked about or applied.

In this post I'm going to take a first step to change this by talking about just one core principle. I'm going to talk about why it's important and how it maps to features in the Power Platform.

Today's Principle Is...

In this post I am going to focus on the first of the S.O.L.I.D. principles, the Single Repository Principle (SRP).

For those not familiar with the S.O.L.I.D. principles, they were introduced in the early 2000s by Robert Martin (Uncle Bob) SOLID - Wikipedia and were created as one of several sets of guidelines and practices intended to improve Object Oriented Programming.

Ready to geek out? Here are some examples of what this principle is applied in the "pro-code" world.

• Single Responsibility Principle in Java with Examples - GeeksforGeeks
• Single Responsibility Principle - explained with examples - Mienxiu

If you want to know more about these principles and others, I've included some links at the bottom of this post.

The S in S.O.L.I.D. stands for Single-Responsibility Principle. It states that each class or object should only have one reason to change. Otherwise stated it should only have one responsibility or purpose. The stated benefits of applying this principle are a more modular and easier to maintain solution because changes to a class or function are less likely to impact unrelated parts of the solution.

In the no code world, we don't have classes or objects which makes it somewhat difficult to map the principle to actual application. So, when it comes to applying a principle like this, the most important thing is the mindset. The key thing to take away is that this principle encourages breaking down complexity into simple, single-purpose, components or modules, and that this will promote clean, understandable, and maintainable solutions.

Application

Within the Power Platform this mindset can be applied in several ways.

Power Automate - Flows

First, Power Automate flows can be implemented with a single purpose in mind. Microsoft provides a pattern for use of Solutions and Child Flows. Child Flows, which we talk about in another post, allow you to create logic within a flow that can be reused by other components in the Power Platform. For example, if you need to send email notifications as a feature of your application, you can implement the email notification logic in a single flow. This "Send Notification" flow can then be invoked as a result of any number of triggers or actions in your solution. Just pass in all of the needed parameters and you're done. Not only do you get a consistent notification output from your application, but you now only need to update your notification functionality in one place, and you don't have to worry about other unexpected results. With this in mind you can then think of your automation or process in terms of single units of work and to the extent it is reasonable, break them up into child flows.

‍

Power Apps

Second, Power Apps components can be made responsible for a singular purpose. At the highest level, Applications themselves should be concerned with accomplishing tasks for either a single user persona or multiple user personas who participate in the same processes. An example of this would be creating separate Model Driven Applications for administrators of a solution and the end users of the same solution. You can of course secure the data and components according to security roles, but separating these things reduces security risk if something gets missed in the security configuration and reduces the impact to end users when an update is needed to an element that doesn't need to exist for both user personas.

Model Driven Apps - Forms & Views

We can take this deeper still when considering components of a Model Driven App. Every table / entity will have a set of forms and views that are automatically created. For example, you start with a Main form and an Active Records view. But this is not where you should stop. Dataverse tables are designed to allow you to create additional forms and views for specific use cases or functions. Don't use the same form for all applications / personas. You can create specific forms for specific purposes and include those within your application, giving the user what they need and not distracting them with unnecessary information.

Conclusion

I want to get these principles out there to help equip people and businesses to make better design decisions in the Power Platform. People new to this world often never learn these principles or they stumble onto them after suffering for some time without the knowledge. I plan on creating more content like this for each of the S.O.L.I.D. principles. Let me know if want to see more examples where we apply design principles to elements in the Power Platform.

Links & References

SOLID - Wikipedia

GRASP (object-oriented design) - Wikipedia

Don't repeat yourself - Wikipedia

Object-oriented programming - Wikipedia

6 Software design principles used by successful engineers - Swimm

The SOLID Principles of Object-Oriented Programming Explained in Plain English (freecodecamp.org)