A Common (project) Framework for Solution Development with Power Platform

My recent piece The Cloud Application Platform Era is a seismic, generational transition for cloud technology set forth a sweeping vision for Power Platform and its place in the next generation of cloud tech that I call the Cloud Application Platform. Key to this vision is the idea that the Power Platform specifically and the Cloud Application Platform more broadly are most valuable to organizations that employ the technology in service of their important and critical workloads. You can read more about how to drive that platform value here.

All this begs a question that I am often asked: “OK, great, so how do we actually develop these solutions?” I’d like to share some of that guidance and lessons learned in the essay below, which I’ve also now incorporated to the “Solution Development” track within the Power Platform Adoption Framework.

Here I’ll lay out a common framework (which we’ll refer to as “C-Frame”) for managing Power Platform solution development. This approach is best suited for solutions that classify as important or critical according to the Environmental Architecture Model found in the Power Platform Adoption Framework. It’s an approach built for mature teams of experienced technical members, and for fusion teams where more technically-focused developers join with “citizen developers” to build together. Productivity grade solutions often built by citizen developers alone will almost always follow a less involved development path, though serious (or serial?) citizen developers should certainly familiarize themselves with the approach to ensure they don’t miss anything in their own development efforts.

In keeping with the adoption frameworks’s usual pattern, C-Frame’s intent is not to teach the ins and outs of each activity, but rather to outline that common approach to solution development, to prescribe a shared model of team organization and to ensure each activity is accounted for. That is to say—for example—the approach below isn’t going to teach you how to wire up your solution-specific authentication using security groups in Azure Active Directory, but it certainly suggests you do so. Similarly, my goal here is not to teach a novice how to run an agile project in general, but again rather to suggest that Power Platform solution development be managed in an agile fashion yet guided by the broad activities I’m sharing here. Additionally, more formal organizations will find that C-Frame also provides a structured, proven way to satisfy project management requirements such as a “work breakdown structure” when required.

Anatomy of a Solution Development Project

First and foremost, let’s think of a “solution development project” as any effort undertaken by an individual developer or a team whose objective is to migrate, modernize, or build a new solution using Power Platform related technical components resident to the Cloud Application Platform. With that said, let’s think of projects as comprised of several child components:

• Project Members form the team possessing the necessary experience and skillsets to develop the solution (e.g. solution architect, developer(s), etc.). We’ll cover these roles in a bit of depth in a sub-section below.


• Project Activities are the buckets of tasks that will be undertaken in order to produce each deliverable individually and the overall solution as a whole. They are “how” we are developing, or put another way, they are to solution development what the pillars and dimensions are to enterprise management (discussed elsewhere in the Adoption Framework). We’ll cover each of the solution development project activities in depth in a sub-sections below.

• Deliverables are features or functionality that the team will deliver as they develop the solution. Deliverables will most often take the form of apps (or features within apps), automation components, business intelligence or data visualization components, chatbots, data integration components, etc. They might also include documentation or other artifacts that must be produced. Deliverables are “what” we are developing.
 In an agile context, we generally think of a deliverable as corresponding to an “epic” or “feature”. They are very specific to the solution being developed, i.e. a specific piece of functionality you’re building, so we’ll not break them out into a sub-section here.

• Work Items are the task-level chunks of work into which deliverables and project activities are broken down. They are where deliverables and project activities intersect. So, for example, at the intersection of the deliverable for a “Skills Bank” app and the “Solution Data Model” project activity we might have a work item to “Create a table called ‘Skill’”. In an agile context, we generally think of a work item as either a “user story” or “product backlog item”, “task”, or “bug”. Work items are like deliverables in that they’re usually specific to the solution being developed (so they don’t get a sub-section here, either), but there are some work items you’ll need every time such as to “Create an entity relationship diagram (ERD)” (which I’d clearly place under your “Solution Data Model” activity as well").

• Sprints are the time-bound development periods—generally lasting two weeks each—in which work items are assigned out to project members and scheduled for work. We’re pretty committed to Agile development best practices, so we’ll leave further discussion of sprints to the agile experts and not cover them here.


Project Members

We size our teams to suit the needs of the organization we’re serving. We’ve learned over time that the model below is a good fit for Power Platform. I’m not absolutist about the terms here, though, as long as the team has accounted for what needs to be done. For example, Microsoft partner consultancies may refer to to a “Lead Power Platform Developer” as a “Lead Consultant”. I’ve also seen a bit of variation across countries and local work cultures. The goal is to cover the responsibilities, not be dogmatic about the nomenclature.

• Project Manager (PM) leads the overall project effort and may (or may not) possess some degree of technical expertise. Ideally the PM possesses at least some expertise in a combination of the technology involved and the best practices to manage its development, though we’d not call this a hard requirement given that the PM’s duties are managerial in nature, e.g. facilitating communication amongst the development team / sponsors / end users, managing the project’s schedule and risks, and keeping things on track. There’s loads of of project management guidance out there at varying levels of quality, so we’ll not restate it here.

• Solution Architect (SA) serves as the development effort’s technical leader overseeing solution design and development, facilitating co-design sessions with business stakeholders and end-users, provides technical leadership to the development team, and offers both technical and strategic guidance to business leadership and technical teams. Typical efforts require 50% to 75% of the SA’s time (so 20-30 hours in an average week) from start to finish. This commitment could be lower or higher depending on technical and functional complexity, and in more complex cases it may make sense to break out technical leadership to a “Technical Architect” (TA) whilst retaining the SA’s responsibilities for business function leadership, facilitation, etc.

• Lead Power Platform Developer (Dev Lead) serves as the effort’s principal “hands on keyboard” developer leading solution development based on the SA’s established design and patterns. Dev Leads are often responsible for DevOps and ALM, writing and assigning work items (user stories) based on the SA’s overall design, coaching and quality control for the efforts of other developers, and is directly developing the most complex functionality him or herself. Typical efforts require 50% to 100% of the Dev Lead’s time (so 20-40 hours in an average week) from start to finish. This commitment could be lower or higher depending on technical and functional complexity, and in more complex cases it may make sense to share Dev Lead responsibilities amongst several qualified individuals (e.g. breaking out responsibility for DevOps and ALM).

• Power Platform Developers possess experience in the platform services to be utilized in the solution (e.g. Dataverse, model or canvas Power Apps, Power Automate RPA, Power BI, etc.) in order to build the solution. Developers are assigned work items or responsibility for entire project activities or deliverables in order to progress development forward. Typical efforts require 100% of a developer's time (so ~40 hours in an average week) from start to finish. This commitment could be lower or higher depending on technical and functional complexity, and in cases where multiple Power Platform (or other cloud services) are used, it may make sense to share develper responsibilities amongst several qualified individuals (e.g. one person developing a canvas app and another developing Power BI components). This division of labor may result in developers with specific skills requiring less than 100% of their working time, which is fine. Remember that Power Platform is a complex, principal platform in the Microsoft Cloud, so it is unreasonable to expect a single developer to know everything.

• Power Platform Test Engineer works alongside the developers, building and executing solution testing using automation, the Power Apps Test Studio, and Power Apps Testing Framework where possible.We have found that 50% of a Test Engineer's time (so ~20 hours in an average week) is appropriate in a typical scenario involving (say) time for 50% SA, 100% Dev Lead, and 100% Developer (as described above.

It is also beneficial to involve project members with the following skillsets, particularly in development efforts moving up the criticality scale:

• User Experience Specialist (UX) are experts in user research, design thinking, and in the creation of actual user experiences to be used in the solution. Note that this expertise will often be spread between several members (e.g. those skilled in user research and those skilled in UX development).

• Data Integration Specialists are skilled in building data integrations with more sophisticated or legacy systems such that the Power Platform solution is able to exchange data with third party systems, particularly in cases where the third party system is not easily supported by Power Platform native data integration services (e.g. Dataflows).

• Azure and Microsoft 365 Cloud Specialists include a broad range of technical specialty outside of Power Platform but inside of the broader Microsoft cloud, e.g. Azure and Microsoft 365 services. A decision should be taken when assembling the project members as to whether additional expertise outside of Power Platform will be required.

Project Activities

Project activities will consume the bulk of our discussion here because they are the real substance of the C-Frame approach. Together they form the comprehensive list of what must be undertaken in order to get a development effort from concept to completion. They’re intended to be a guide, not a ritualistic set of “must-dos”. Like the enterprise management dimensions discussed elsewhere in the Power Platform Adoption Framework, there may be times when an activity doesn’t make sense in a particular effort, and there likewise may be times when additional activities should be added to an effort. Stay flexible, but be disciplined in what you do and in what you choose not to do.

Broadly speaking, project activities can be thought of in one of five “buckets”. We resist calling them “phases” because we want to encourage a more agile approach. That said, the buckets do happen in a somewhat linear order (e.g. you can’t go to production until you’ve accounted for enterprise management), so if phases fit within your organization’s model, feel free to plan your activities as such.

• Getting Started

• Solution Development

• User Engagement

• Enterprise Management

• Production

The diagram below illustrates the project activities in the context of the overall solution development effort.

C-Frame project activities are shown in the diagram above, but try to resist thinking of them as a very clear line. Solution development of important and critical workloads produces far better outcomes and is significantly easier to manage when your team has in its own way accounted for all of these project activities. You may decide to set an activity aside as just not applicable in your current situation, but that you’ve thought it through and planned for each will keep you on track every time.

Getting Started

The activities discussed below lay the foundation for a successful development effort. Put a bit of time into doing them correctly up front, before you get started. In many cases you can get all of this done in your “Sprint 0”, that is to say within the first 1-2 weeks of your development project.

• Solution Co-Design
  In the “old days” of software development we’d often avoid designing solutions with users and stakeholders in the room, so as to not over-promise. Those days are over. Now we avoid designing solutions without our users and stakeholders in the room. One of our first (and ongoing) activities must be assembling those who best know the given business activities to co-design (emphasis on “co”) your solution from the data model up. It’s important to start with the data model because so much of the power underpinning the ultimate solution comes from Dataverse. So, begin with data and connect it to your users, rather than beginning with the push button “app” experience and hoping that the data will fall into place. Your initial solution co-design session should produce a design (preferably in the form of an entity relationship diagram or “ERD” with copious notes) sufficient to start development.
  
  

• Process Analysis
  This ideally happens side-by-side your co-design activities, but in practice often slots in as a follow up activity. Co-design will nearly always bring to light existing assets, spreadsheets, legacy apps, forms, etc. that make up the business process at hand. Do review these things with your stakeholders to ensure that you’ve not missed anything. Do not become a victim of legacy process, though. This is your big chance to find a better way to do business.
  
  

• Development Planning
  Produce a development plan using what you’ve learned and produced during co-design and process analysis. This is fairly basic project management, but don’t kill the process with more process. In most cases a list of high-level features to be delivered (these become your “deliverables” in effect)—broken down into an initial backlog of work items kept in either Azure DevOps or GitHub—alongside a schedule ideally organized around agile sprints will suffice. Try to focus on getting one or a few features finished first before you move onto more, lest you wind up with a solution full of quasi-functioning, half baked features. Remember that you’re ideally using an agile approach here, so you’ll be iterating and building upon this plan as you go.
  
  

• Provision the Environments
  Create a Power Platform environment for the purpose of developing this solution. Avoid developing this solution in another solution’s DEV environment (i.e. one solution per DEV environment) as this can create unwanted dependencies in your data model. It’s also worth noting that it was common in the “old days” of software development to actually develop apps in a completely separate tenant, but Power Platform environments make that approach obsolete (and problematic for a number of reasons). Best to create your DEV (and TEST) environments in the same tenant as your eventual PROD environment and use the platform’s built in security and ALM tools to govern the pipeline from there.
  
  

• Solution Data Model
  First create a new Power Platform “solution” inside of your DEV environment. Then build the initial data model created during co-design. This will ideally be built in Dataverse and should include your first cut at the tables and columns that you expect to make up your solution. When in doubt, be conservative and avoid over-engineering your solution at this point. It is much easier to add something to your data model later than to back something out that you created prematurely. The goal here is to create the data-driven scaffolding upon which all else will be developed. It’s also a good idea at this point to create a model-driven app from this data model so that you can see the model in practice and quickly begin manipulating your sample data.
  
  

• Solution Security Model
  Like your data model, but for security. Here you’re creating the initial security roles aligned to your future user’s different job roles. Don’t expect this to be the end, rather the security scaffolding married to the tables you’ve just created as part of your data model.

  
  

• Deployment Pipeline
  Create a TEST (and any other pre-production environments you need) just as you did for DEV. Then use Azure DevOps or GitHub to establish an automated deployment pipeline to progress your solution from (e.g.) DEV to TEST to PROD. Automation here reduces time and risk. Note that the choice between Azure DevOps and GitHub may be in your control, though there should be an organizational standard for this if your organization has properly matured itself in the “Platform Tooling” dimension of enterprise management.

  
  

• Source Control
  Establish source control—again in either Azure DevOps or GitHub—for your solution whilst you are building your deployment pipeline. Again, automation reduces time and risk, so take the time to do this up front.

  
  

• Development Automation
  This activity may or may not be applicable, but when you’re developing multiple solutions in similar ways (e.g. an “app factory” approach) it’s wise to automate development as much as possible. For example, if you’re migrating many legacy InfoPath forms to Power Platform, there’s tooling that automates the inventory of InfoPath libraries, creation of metadata in your target data source (e.g. Dataverse or SharePoint), and migration of data from the InfoPath library to the new data source. Seek and use these tools where it makes sense in your particular situation.

Custom Development

Now we’re on to the iterative development activities that will take place sprint to sprint as you build the solution atop the data model you established earlier. These activities, for the most part, happen alongside one another throughout the course of your development effort.

• User Experience(s)
  These are the apps (canvas, model, portals)! Also the chatbots, and really anything that is part of the end-user experience as you package up like functionality into consumable chunks for your users to experience and consume. Truly excellent UX is a discipline all its own that we’ll not cover in this piece, but the goal of your UX activity is to build beautiful and highly usable experiences in the form of apps, chatbots, etc.
  
  

• Views and Visualizations
  Build the views of data, visualization and BI components, dashboards, etc. necessary to make your data usable and consumable to your users. Whereas UX is about how the users will get to and interact with the functionality they need, this activity is concerned with surfacing the data users need in ways that are useful and fit for purpose.
  
  

• Rules, Processes, Automation
  This activity is all about building the logic that is usually baked into an application but often imperceptible to users. In other words, this is the “under the covers” bit of development. Think here about business rules, business process flows, flows in Power Automate, use of robotic process automation (RPA) in Power Automate where necessary, etc.
  
  

• Data Integrations
  Most organizations have data strewn about across myriad different systems, apps, data stores, etc. From time to time we encounter new Power Platform solutions that are completely fresh from a data perspective, but more often we’ll need to create data integrations either to achieve (1) one-time migration of data into the production solution, (2) one-way push or pull of data to or from the solution on an ongoing basis, or (3) bi-directional synchronization of data on an ongoing basis. This activity is focused on mapping and building the data integration components necessary to meet whichever of these requirements apply to this solution.
  
  

• Solution Documentation
  It’s an immovable law of the universe that most development teams hate documentation, but useful documentation is among the most essential ingredients to a solution that is sustainable and maintainable over the long term. Try not to overdo it, though. Good Microsoft partner consultancies and in-house development shops will have standards and templates for how this should be done. We recommend a form of “Solution Design Document” organized around the project activities discussed here. In other words, an explanation of the solution you’ve co-designed, the processes you are addressing, the environments you’ve established, the data model you’ve created, etc. Be consistent in tying together your development process and your documentation. Don’t wait until the end to produce this, rather add information into your documentation as you go. We’ll add also that some solutions may carry requirements for training documentation. This is a discipline unto itself that we’ll not dig into here, but that type of documentation would be covered by this activity as well, where needed.

User Engagement

These activities discussed below relate to how we engage users throughout the development process. We recommend you undertake them often, alongside your custom development activities.

• Demos
  These should be conducted as part of your sprint cadence, but by all means feel free to demo often on an ad hoc basis. The key here is that user feedback is solicited and then incorporated into future development efforts. The best demos are often those that lead to a fresh co-design session and updates—however minor—to your backlog and your development plan.
  
  

• Training
  Training is a discipline (often under appreciated) unto itself, so we’ll not detail the myriad training methods and techniques one might employ. Suffice it to say that solution development efforts fail when training has not been adequately accounted for and properly executed. Plan those items as part of your “training” project activity.
  
  

• User Acceptance Testing (UAT)
  We’ve observed a tendency of some less disciplined organizations to neglect UAT when working with low-code. UAT is nothing new to seasoned development teams, but to demystify it for those without UAT experience, what we’re talking about here is the act of getting working functionality in front of your end users so that they can touch it, click it, play it, and break it in the spirit of providing feedback for the development team. Ultimately you are seeking the “thumbs up” from your end users saying “yes, this is great, it meets (or exceeds) our needs!” …But we’ve also successfully delivered enough projects—particularly as partners or consultants working as part of a contract for a customer—to understand that UAT often requires an affirmative customer sign-off on a specific list of requirements. Regardless of the formality required in your effort, we recommend that (a) functionality be turned over to users for testing and feedback on an ongoing, iterative basis rather than waiting for the last moment before production, and (b) UAT be an activity facilitated by the development team itself (so that feedback is dynamic and collaborative) rather than a self-paced activity that often results in users “throwing feedback over the fence” to their development partners.

Enterprise Management

The activities below will in mature organizations have been largely accounted for by an overarching program of Power Platform enterprise management, ideally run out of the organization’s Power Platform Center of Excellence (CoE) or other central IT function. That said, the development team ought not take anything for granted, and at any rate should ensure that certain enterprise management dimensions are accounted for in the context of this solution specifically.

• Authentication
  In this solution-specific context, here you should ensure that (1) your intended users have a path to log into the tenant and environment where the solution will live, and (2) those users are mapped to the Power Platform resources they need in order to use the solution. On the latter point, consider using Azure Active Directory (AAD) security groups mapped to teams in Dataverse (not “Microsoft Teams”, as the two are separate capabilities) which are in turn mapped to security roles. The more mature your organization’s overall authentication infrastructure, the better time you’ll have deploying and managing user access to the solution long-term.
  
  

• License Management
  Ensure that the intended users discussed above have sufficient licenses to use the solution you are deploying. In general this will mean that (1) users have been assigned licenses that cover all of their Power Platform use in a tenant or environment, (2) the production environment to which you are deploying the solution has sufficient license capacity to absorb the increase in app use that will come from your solution.
  
  

• Security Accreditation
  We recommend that organizations complete their own internal IT security processes necessary to accredit use across the platform. In other words, certify Power Platform and its component services once rather than impose the compliance overhead of forcing every individual app through an accreditation process. This approach most often leads to an audit process that solutions must go through in order for the CoE to confirm that they are compliant with development and IT security requirements. However, in some cases the data to be kept inside of a specific solution may require an additional accreditation process (e.g. when personally identifiable information or PII is in play). It’s important that you understand the organization’s security accreditation requirements, and that you include the work of meeting those requirements in your development plan.
  
  

• Platform Security
  Ensure that you have accounted for various security services that may enable or impede the functioning of your solution. Some of this will have been taken care of in the context of the “Authentication” activity, at least in organizations with a mature deployment of Azure Active Directory (AAD). Regardless, beyond the work of authentication, user administration, and license control it is important to ensure that you’ve accounted for users’ access to your target production environment, and that you’ve shared the appropriate apps with users and groups. This is ideally done using security roles and teams in Dataverse (itself a big advantage over developing with Dataverse rather than other data sources).
  
  

• Data Loss Prevention (DLP)
  Mature organizations will have implemented DLP policies in each of their Power Platform environments. The activity here from a solution development perspective is to ensure that (1) a DLP policy of some kind has been applied to the environments to which this solution will be deployed, and (2) the DLP policies—particularly if they are pre-existing—do not restrict any data connectors that your solution will require. Work with your CoE team to enact required DLP changes before deploying your solution for production use.
  
  

• Tiered Support
  Understand your organization’s approach to providing tiered or help desk support to Power Platform solutions of similar criticality to the one you are developing. Then work with those who will be handling support requests for your solution so that support personnel are not caught unawares and so that your users are able to access the support they need.

Production

Longer-term agile solution development efforts may push functionality to production on multiple occasions, potentially even weekly or more depending on the DevOps cadence you’ve established. The activities discussed below support that effort and the long-term sustainment of the solution that follows.

• Production Deployment
  This process should be automated via Azure DevOps or GitHub, and should follow well-established IT best practices concerning scheduling, user notification, release planning, data migration, etc.
  
  

• Post-Production Support
  It’s wise to build a period of time (potentially several sprints depending on the size and complexity of the solution) for the development team to provide post-production support to the solution once the actual development effort has ended.
  
  

• Transition to O&M
  Identify and transition ownership of the solution to your organization’s established operations and maintenance (O&M) team as the development team fully steps away from the effort. The solution documentation created as part of previous activities is essential here. It’s likely that the architects and developers that have produced a solution both beautiful and useful will not be inclined to spend the remainder of their career supporting this application, so put time into a proper handoff.

Getting it done

Regardless of how you “get it done”, though, if you take nothing else away from this approach, let it be this: Solution development of important and critical workloads produces far better outcomes and is significantly easier to manage when your team has in its own way accounted for all of the project activities I’ve discussed above. You may decide to set an activity aside as just not applicable in your current situation, but that you’ve thought it through and planned for each will keep you on track every time.