25 things to consider for great solutions

This article will be very simple, and tries to simplify all of the elements that go into designing solutions in the Power Platform. I have split these up into 5 different sections to try and organise my rational.

Let me know if you have any other items that are a must when designing a solution.

Prepare to succeed

As the saying goes preparation is the key to success and therefore it is good to be prepared when creating a Power Platform solution. So 5 items on how to prepare to succeed:

1. What are the outcomes that you are trying to achieve
   • Start of technology agnostic and just understand by talking to people what you are trying to achieve. I always think of this stage as do you understand it well enough to be able to play it back to a partner or parent that doesn’t do tech, if not then I’d say you may not understand it well enough!
2. Know the showstoppers
   • Are there any show stoppers that could stop you in your tracks. These can vary and you may not know the answer to all of them but some typical ones commonly encountered:
     • Is there the budget for the development, support and management of the solution?
     • Is there the budget for any licenses?
     • Does the customer or business have the capacity to engage in the project?
     • Is there any reason from legislation (i.e GDPR), compliance and legal reason as to why the solution is unlikely?
3. Initial Documentation or Requirements
   • Document what the outcomes are and how you plan to achieve them. Yes, this can be done in many different ways from Agile, Waterfall, Wagile (if you know, you know) or even an excel document. Just do something consistent and set out expectations to all involved.
   • Requirements will change – we humans love to change our mind and writing something done and getting everybody to interpret it in the same way is almost an impossible task. Therefore have a way to evolve requirements in an agreed way upfront. Personally, this is done via Agile and Azure DevOps!
4. Plan, beyond the development
   • A project doesn’t finish once the development is complete or start when you open make.powerapps.com, VS code or whatever service / tool you are using. You may have created the best application, automation or “thing” in the world but if nobody wants to use or knows how to use it then it’s pointless.
   • Think off all the elements of a project and make sure they are considered if any could be showstoppers.
5. Is it feasible?
   • Is there anything that would make the project just not feasible? Is the deadline just impossible, is there a technical challenge that isn’t possible with the technology available?
   • Obviously, try and find ways to mitigate challenges but make sure they are document and understood.

Lets Design

Once you’ve understood the outcomes, planned the entire project and life post the project and believe the project is feasible then it is time to design the project. For this article it will cover high level items that hopefully can guide you in ways to approach design.

1. Data is king
   • Start with data and finish with data it will be key. Ensure that you understand where data can be stored (if it is a Power Platform solution then please try and use dataverse)
   • What is the source of the data – is it going to be created in the solution, imported via an ETL process, created via automation or even via AI 😉
2. Security is queen
   • Design a security model of the least privilege – users of the solution should only be able to do what they need to do,
   • Irrespective of the data storage you are using do not do security through obscurity – i.e a Canvas App using a filter to restrict what a user sees is not security as the security is controlled at the data layer and not in the canvas app
3. Usability, how are we going to use this thing?!
   • What is the most appropriate interface for what you are trying to achieve. Not everything needs to be an app. Can it be a chatbot, could it be an adaptive card or should it be a report? Often the best solutions are the simplest ones.
   • Avoid gravity – it’s common that people will gravitate to the technology and services that they are familiar with, however that particular technology may not be the best fit for that particular outcome.
   • Accessibility – please, please make what you do useable for all people – at any one time research states that 1 in 5 people have an accessibility need from temporary disability such as a broke arm to permanent disability such as sight loss. In the UK all public sector applications must follow the WCAG 2.2 AA accessibility standard by October 2024
4. Automation rocks
   • Can you automate that activity, action or process? Automation has many benefits in lots of cases over human processing. So where possible always try to automate – the chances are people don’t like doing that action or activity anyway never mind the numerous other cost saving benefits.
5. Keep it greenfield
   • I do not hate professional code and customising solutions however, if you can do something that is 95% there using standard configuration and that 5% that is missing isn’t critical try and push that – it will give you less headaches in the future!

Let’s get technical

1. It’s a jigsaw
   • Creating a solution is like completing a 3D jigsaw. Lots of pieces fit together in certain ways to give you the end result with certain pieces needing to be the support for other pieces you’re after. Find the most appropriate way to fit the different services together and don’t be afraid to suggest radical ideas if they have sensible grounding.
   • Some solutions may require a combination of chatbots, apps and automation processes and others may just require a single Microsoft Form, often the simple solutions are the best.
2. Document it, but not to much
   • Documentation is certainly the love and hate relationship of many people in the technology world. There isn’t anything worse than getting handed over a project with 0 documentation but at the same time a project that is one canvas app submitting records into one table probably doesn’t require a 100 page design document.
   • Comment code – where you can in the power platform add comments that explain blocks of code or what a logic is trying to achieve. The amount of times I’ve come back to something after 6 months and looked and thought wtf is that is scary.
3. Think longterm
   • What is the lifespan of the solution that you are putting together and are the services that you’re thinking of using going to be supported in the future. Are there services or features that are coming that could really enhance the solution you’re creating and can you create a plan to implement them in the future?
4. Collaborate with SMEs and peers
   • It is unlikely that you are going to know every single thing about the solution you are creating. Whether that is the exacting in business process or the best way to design a particular component of the solution so don’t be afraid to work with people that know that stuff.
   • Working with SMEs and peers can give you a different perspective and often enable you to bounce ideas off of. This collaborative approach is also a great sounding board for the solution you are creating to ensure that it makes logical sense.
5. Integration hell
   • If you have data that exists externally then seriously consider the way you need to integrate that data into the services your solution is going to leverage.
   • Focus on the best way to bring that data in based on the constraints of the data source, licenses, security and governance that is in place.
   • In my opinion integrations are both the most powerful part of a solution but also one of the most painful!

Migration

Now, migration doesn’t just mean the migration of data from one system to another. For me it bakes in a much larger piece that includes the migration of users, configuration of access, migration of data, migration of services and decommissioning of old services to name a few.

1. Plan for failure
   • If you plan for failure then all you can do is succeed. Ok, that is a little tongue in cheek but the concept here is plan for the worst eventuality and how you would get out of it.
2. Test it, more than once
   • Do trial migrations of smaller data batches to get an understanding of the process, challenges and performance of a migration approach.
3. Automate it
   • We make mistakes, however if you use tested automation for the release of services there is pretty good chance you’re going to reduce that error probability.
   • Use the most appropriate automation tool for the job. Many tools exist to support in the migration of different IT services from simple dataflows to 3rd party migration tools.
4. It ain’t all data
   • Don’t forget a migration isn’t just about the data. Make sure that the user accounts are provisioned in environments, security is configured, legacy systems have access disabled and communications are planned in line with the migration.
5. Don’t do it for the sake of it
   • Depending on the scale of the migration it may be prevalent to have success rates planned for the migration. Automation and reporting can be leveraged to confirm the success of migration activities.
   • There is a good chance that you don’t have to migrate every single user or record over from a legacy system. Work with the business to understand a set of migration rules so that you can try to reduce the quantity of data being migrated.

Leave no one behind

Change and adoption or ACM is by the must under appreciated concept when rolling out an IT solution. Here are 5 reasons to ensure you’ve planned how to make this awesome solution a success.

1. Leave no one behind
   • Making sure that everybody is informed, has a clear understanding of what the solution or system you have created is trying to achieve and how it impacts particular user groups is key.
2. Communication starts before that, probably
   • Having a communication strategy to the users of a new solution is key. This should plan out information based coms such as when the system is aiming to release, what the goals are, when demonstrations, feedback sessions and appropriate training is available.
   • The information doesn’t need to be contained in one mammoth email that goes out once but through a structured approach that offers progress updates while the project is ongoing.
3. Honest and transparent
   • When creating communications that are going out to the end user base be honest if delays or issues occur. People typically have more empathy if they know what is going on!
4. Engagement
   • Use interactive communication platforms where possible to obtain early feedback or generate discussion points. These engagement channels can be a good way to grasp the sentiment of a system based on size reel style demos.
5. Don’t stop once it is done
   • Once the system has been released and the initial development has been complete the communication to users shouldn’t stop. Communicate the roadmap of the system and when new releases are coming, how to get in touch to provide feedback and enhancements and please don’t forget to inform users of updates (I’m sure we’ve all seen patch notes on releases before).
   • Think about the creation of internal roadmaps that can sit on the intranet or through other means. We even created a solution to manage release notes with a report that was available to all users.

If you’ve got this far then thanks for reading, do you have any tips when designing a solution?