Sometimes the very benefit of LowCode is its main weakness. Take Power Apps, you can create a fully fledged app in less then a day, but here's the problem, just because you can doesn't mean you should, and that's why Architecture Reviews are key.
Architecture reviews should happen straight after Intake and before Security. Intake shows that there is value in solving the problem, security review makes sure the solution is secure, so you need the Arch review to help decide what is the best solution.
There are 2 key Arch stages for when working with Power Apps, these can be combined or split into 2 different roles.
- Enterprise Arch Review
- Solution Arch Review
1. Enterprise Arch Review
The Enterprise Arch review should be from the enterprise view (the name gives it away), so this should not be focused on the Power Platform or Power Apps. The question should be, what is the right tech stack and system design to solve the problem. This can be from any angle, full procode to even a tactical MS form solution, the Enterprise Arch needs global understanding of all tech available in the organization.
Far to often the business teams solutionize the problem and then take it to Intake, and this is totally the wrong approach. The business team will focus on the skills they have, tech available and focus on generating value from those. When what we really should doing is focusing purely on the right solution, even if this means handing to another team to take the kudos.
This is where the Enterprise Arch review delivers value, the Architect has no skin in the game and are totally independent.
I've seen far to often a Power App dev team create an incredibly complex Power App to solve a problem they have, when one of the Out of the Box solutions they have has it available for free. Imagine a team spinning up their own CRM tool when the business has Service Now available. The real reason the business wanted a Power App solution was to prove the investment in the dev team and to have something to celebrate at the end of the year.
The Arch review will often end with a choice of solutions, each with pros and cons, they may also flag if something is simply not possible (e.g the API uses grant type client credentials so can't work with custom connector). The business teams Leadership team can then make their decision with full knowledge of costs to benefits.
The Enterprise Arch review should answer:
- What system models are available (SAAS,PAAS, custom)
- What systems can't be used
- What are the benefits to each model
- What new solutions will be available soon (is it tactical etc)
- What tech/skill sets will be needed
- Estimated timelines for implementation
- Any potential security exceptions needed
2. Solution Arch Review
The Solution Architect is the level above the Solution design, we now know the Power Apps is the right solution, but what parts and how are they integrated. Your Solution Arch should really be an expert on the tech stack recommend by the Enterprise Arch. This is where LowCode platforms like the Power Platform show their value, as the Solution Arch can have transferable knowledge across the platform.
For Power Apps the question should include:
- Data storage - Dataverse, SharePoint, Azure, SAAS solutions, etc
- App type - Model or Canvas (or even Chatbot instead)
- Hardware - mobile, desktop
- Data model - what tables, relationships
- Data retention - how long and how deleted
- Access - security roles (both in the Platform and real world)
- Authentication - types, how credentials secured
- Network - conditional access policies
As you can see there feels like a lot of overlap with the Security and Design review, but there are clear lines of separation.
The Arch Review provides the solution for the Security team to Review. It is not the job of the security review to propose a solution, just identify the risks in the solution chosen.
The design review should be a lot more granular, what actions and components while the Solution Architect would have chosen if it was Model or Canvas (as the Developer may only be skilled in either Model or Driven they could not make that decision in the design stage).
Arch Review Structure
Ideally there will be 2 different Architects and Reviews, as the 2 skill sets are different (High level vs Low level) and to ensure impartiality.
Another key reason is with large scale solutions, as these often require multiple systems which each requiring their own solution Architect. This way you have the single overarching view for the entire solution, then broken down to each areas expert.
Architecture, like all software delivery processes add immense value, and just because its LowCode doesn't mean these processes don't add any value, in fact they often add more. As LowCode brings development closer to business need, the view of current enterprise solutions is paramount to stop duplication and waste. Additionally citizen developers learning style means they often have gaps in the Platforms features, this where the Solution Architect can ensure that the solution is scalable and sustainable.
Top comments (0)