A Guide To Beginning Your Application Lifecycle Management (ALM)

In this post we'll explore the key areas you will want to consider if you are to create a location where your teams can be creative with the Power Platform but also avoid the likely sprawl and confusion that comes with poor or no control.  Consider this a primer. We won't go into detail but we will arm you with the building blocks you need for your first iteration. 

So in this post, I'm going to give you a 4-Step Guide to start you on the road. The great part is that none of this requires you to take overly complex admin steps or learn complex new skills. This all very much sits in the no-code domain in terms of execution. Ready? Let's go!

Why Not Just Develop in the Default Environment?

Doing nothing just means you leave the Power Platform setup to whatever Microsoft have set you up with for a new tenant deployment.

In terms of people creating Power Platform Products, the standard setup is that everyone who is licenced to make apps and flows get's granted permission to what is called the 'Default' Power Platform environment.

Here, anyone can create and delete flows or apps so long as they have either made them or have had them shared with them (Shared Flows and your own appear in your list for both Power Apps and Power Automate Flows).

Default Environments Let All Members Edit and Create

Anyone can edit someone else's app or flow if granted permission which is great. So from a development perspective, it's a collaboration tick to leave as-is. 

However, it gets more sticky when we want to make Apps and Flows 'operational' (to use them for an important business process). If anyone can edit, potentially anyone can change and break a flow that an important business process may rely upon. 

This is maybe fine in a small team where people talk lots but even then, mistakes can happen and fixing breakages might incur cost or a customer impact. 

Space Is Limited In the Default Environment

You may also limited in how many Power Platform apps or flows you can create. Default environments have a 3GB limit on storage (for data and files). This is fine if you are using SharePoint lists to store data for your products but if you build apps or flows that use the Dataverse capacity (this can be aligned to your Environments), you may run out of space really quickly thus limiting the volume of business applications you may be able to create. 

Not All Products Are Meant To Be Experiments

Another potential pitfall of the 'everything, everywhere all at once' method is simply the nature of people. We sometimes half create a product and leave it, moving onto another experiment or solution. Knowing what apps or flows are there because of an experiment, what is intended for a colleague to check and validate (maybe work on), what needs to be left alone because a critical business process relies upon it may not be that easy if you just default to having no process.

Naming conventions could solve this but in a list of dozens of Power Apps, do you really want to have to go hunting for that App which just failed when your customer is on the phone to you asking for help?

Separation of Concerns Is Hard When You All Create In 1 Location

There's a by-product of leaving processes to one side which happens when owners or makers for flows leave the team. How do you deal with support and maintenance if they have not shared their work with anyone else in this 'Default' environment?

Again, it is not difficult to solve in and of itself but when seen along with some of the other gotchas mentioned it starts to make having a process sound like a positive step. By process, we mean having a shared and common understanding around what gets built, for what reason, where it is located for quick access and who can change and update or change work that has become important.

Settings That Work For 1 App May Not Work For All 

In some cases, the app itself may require something in the settings relating to an Environment to allow it to function correctly. This may not be something you want to be available across all apps.

An example is when you perhaps want to enable Co-Authoring between 2 parties on a Power App (for a specific proof of concept purpose where collaboration is essential in tight timelines). There are various settings to work with both in the App itself but also at the Environment level. You can update these for the 1 app but they may conflict with something present in another app causing it to malfunction. 

An example is enabling the Power FX Formula bar in power apps for an environment. That may have a role in making the correct co-authoring features in your app behave poorly - leaving you thinking this isn't working - when in fact, it is an environment setting that is the issue, not the process you are working with. 

Step 1 - Begin With a Conversation With Your Team

It's tempting to believe an expert can give you THE solution to what to do to set up your Power Platform environment for success.  But this isn't realistic. Every organisation and every team are different. Finding YOUR way is important. 

However, there are some common elements you'll need to consider before putting fingers on keyboards. 

• Education: Ensures that every team member has a thorough understanding of the tools they can and should not use and the processes you want to foster in ALM. 
• Effective communication: Allows for the sharing of ideas, feedback, and concerns, fostering a collaborative environment where all voices are heard and respected.
• Collaboration: Leverages the diverse skills and perspectives within the team to create a more robust and adaptable ALM strategy. 

Without these elements, implementing a process in isolation can lead to misunderstandings, resistance, and inefficiencies, as team members may not fully understand or agree with the approach, leading to a lack of commitment and potential failure in execution.

Step 2 - Agree and Implement An Environment Strategy

One of the first conversations you should have with a team regarding setting up an ALM is around how you want to transition your products from development to your customers. Typically, a central component of this discussion is whether you want to have Development environments, Test environment and Live or Production environments (or a host of other variations). 

Because the Power Platform offers none of these out of the box (you get the 'Default' environment only up front), it is an important step to take. Call the resulting decisions and agreements "having an Environment Strategy". 

Having a well-thought through and defined environment strategy is crucial when setting up Application Lifecycle Management (ALM) for the Power Platform, as it lays the foundation for a structured, efficient, and controlled development process.

The Power Platform offers various types of environments (such as development, sandbox testing, and production environments), each serving a specific purpose in the application development lifecycle. Here are several key reasons why an environment strategy is essential:

• Separation of Concerns: Different environments allow for the separation of development, testing, and production activities. This separation is vital to prevent untested or in-development features from impacting the live production environment. It ensures that any development or testing activities do not interfere with the ongoing operations of the business.
• Controlled Development and Testing: An environment strategy allows for a controlled and systematic approach to development and testing. Developers can work in a dedicated development environment without the risk of affecting the live system. Similarly, a separate testing environment enables thorough testing of new features and bug fixes under conditions that closely mimic the production environment, without any risk to the live system.
• Risk Mitigation: By segregating environments, you can significantly reduce the risk of accidental changes or data breaches in the production environment. It provides a safety net, ensuring that only fully tested and approved changes are deployed to production.
• Compliance and Governance: A well-defined environment strategy aids in meeting compliance requirements and maintaining governance standards. It allows for better tracking of changes, auditing of actions, and control over who has access to sensitive data and critical systems.
• Streamlined Deployment and Rollback: With distinct environments, deploying changes becomes more manageable and less risky. If any issues are detected in the testing or staging environments, they can be addressed before reaching production. Additionally, if something goes wrong in the production environment, the previous stable version can be quickly reinstated, minimizing downtime and impact on business operations.
• Scalability and Flexibility: An effective environment strategy is scalable, accommodating the growth of your applications and processes. It provides the flexibility to adapt to changing business requirements and integrate new features or technologies without disrupting existing operations.

An environment strategy is not just a component of ALM in the Power Platform; it is a fundamental aspect that ensures development processes are efficient, controlled, and aligned with business objectives. It enhances the quality of the end product, reduces risks, and ensures that the deployment of new features and updates is a smooth, well-governed process.

Step 3 - Use Solutions

Another tool you can consider encouraging is the use of Solutions. We've got a great workshop about the what, how and why here. In short, using solutions in the Power Platform, as opposed to creating separate apps and flows, offers several key benefits that enhance the efficiency, manageability, and scalability of your applications.

Solutions in Power Platform are like containers that hold and manage all the components of a business process, offering a more holistic and integrated approach. Here are five key benefits of using solutions:

• Streamlined Management: Solutions allow you to group related components such as apps, flows, entities, and more into a single package. This unified management makes it easier to oversee, update, and maintain these components as they are not scattered but organized under one umbrella.
• Easier Deployment and Transportability: With solutions, you can easily move a set of related components from one environment to another (such as from development to testing, or testing to production). This simplifies the deployment process and ensures consistency across environments, reducing the likelihood of errors or omissions that might occur when moving components individually.
• Version Control and Tracking: Solutions support versioning, enabling you to keep track of changes, updates, and the history of your application components. This feature is crucial for maintaining control over the development lifecycle and for auditing purposes.
• Dependency Management: When you use solutions, dependencies between components are automatically managed. This ensures that all necessary components are included when a solution is moved or deployed, preventing issues related to missing dependencies that can occur in standalone apps and flows.
• Enhanced Collaboration and Governance: Solutions facilitate better collaboration among team members working on different parts of the application. It also supports governance by allowing administrators to control who can add or modify components within the solution, thereby maintaining the integrity and security of the application.

By opting for solutions over separate apps and flows, you are essentially choosing a more structured, efficient, and risk-mitigated approach to building and managing your business applications on the Power Platform. This integrated approach not only streamlines development and deployment processes but also significantly enhances the manageability and scalability of your applications.

Step 4 - Control App Deployment Using Pipelines

As products and solutions mature, you may well opt to to promote them into 'higher' environments like ones dedicated to Test and Production. This creates separation for your efforts as mentioned in the environment strategy section. 

This is where Power Platform "Pipelines" are a valuable tool in managing the controlled movement of Solutions between environments.

You COULD simply export and import Solutions as zip files in and out of environments but in doing so, you are missing out on some key benefits. In short, Pipelines offer a more sophisticated, reliable, and scalable approach to managing application lifecycles. Note: At the time of writing, there is a requirement for the use of Pipelines to have your target environment set up as a Managed Environment. This means there is additional control over that location. However, putting this in place is only possible with the right licence position also being in place. Find out more HERE. Put simply, if you are embarking on more formal ALM using the tools available, you will need Per User or Per App licences for your flows or Apps and to enable this feature. 

A pipeline, typically part of DevOps practices, automates the deployment process, ensuring consistency, efficiency, and error reduction. This automated process is crucial for complex or frequent deployments.

Here are 3 key limitations of manual importing and exporting that a pipeline addresses:

1. Lack of Continuous Integration and Continuous Deployment (CI/CD): Without a pipeline, you miss out on the benefits of CI/CD practices. Pipelines automate the integration of new products and resources. You don't have to manually select updates and re-apply them. Instead, the pipeline will move your changes to the chosen Environment without the need for much additional work. This automation not only speeds up the process but also reduces the risk of human error and ensures that changes are systematically implemented, and if you choose - tested - before deployment.
2. Inefficient Environment Management: Manually importing and exporting solutions do not provide an efficient way to manage different environments (development, testing, production). A pipeline allows for a seamless and controlled flow of changes across these environments. It creates an audit trail, enforces consistency and ensures that each environment is updated in a controlled manner, following your agreed ALM process.
3. Lack of Automated Testing and Quality Checks: When you manually import solutions, you bypass the opportunity for automated testing and quality checks that are part of a robust pipeline. Pipelines can be configured to automatically run tests and quality assurance checks, ensuring that only solutions that meet specific criteria are promoted to the next stage. This reduces the risk of deploying faulty or suboptimal solutions.

For point 3. It is important to say that at the time of writing, the automated Power Platform (Apps specifically) Test suit is far from perfect. However, as this matures or other options are found, having this capability can drastically reduce drag when pushing your developed products to Live and into the hands of keen customers. 

When To Move To A More Mature Governance

As adoption and solution complexity increases, you may look to implement more controls or checks and balances to help you monitor how your Environment Strategy is being used. You may begin to look for anomalies or challenges to help you talk about future enhancements.

Implementing tools to monitor and measure usage should ideally be considered an ongoing process rather than a one-time effort. There are lots of tools out there to help but one we hear a lot about at the Academy - and happens to be provided by Microsoft is the "The Center of Excellence (CoE) toolkit".

This advertises itself as a comprehensive set of tools designed to help organizations maximize the value of their Power Platform investment. It can provide insights into the environments you are using, what is going on in those environments and more. The idea being that it can enable better governance and unlock continous improvement. 

Being a small organisation, we have not implemented these tools ourselves but we do invite people to share their experiences and pitfalls in the Microsoft 365 Forum we offer.

Our belief however is that the CoE toolkit should be implemented once you have a basic understanding of the Power Platform environment and have started developing solutions.

It's not necessarily the first step, as initial efforts might focus more on setting up environments, basic governance, and understanding platform capabilities. However, it shouldn't be the last step either. As your organization’s use of the Power Platform matures, the CoE toolkit may become increasingly valuable so we'd recommend exploring alongside setting in motion all the other aspects we recommend in this post.

The reason being, in the middle stages of your Power Platform journey, it is likely that the number of apps and automations will grow fast. Something like the CoE toolkit could then become crucial for monitoring usage patterns, compliance, and performance metrics. It can help identify popular solutions, potential areas for optimization, and governance issues that might arise with increased usage via it's analytics.

Key Takeaways

The key lessons we wanted to share around Power Platform governance and ALM in general  are:

1. Start early before solutions become an intricate entanglement
2. Communicate early and often to foster engagement and collaboration
3. Have a Strategy for Your Environments and use Developer environments promote exploration
4. Use controlled Pipelines along with Solutions to facilitate movement across phases
5. Consider your more advanced oversight needs - possibly through the CoE

With the right foundation, Power Platform allows teams to build transformative solutions creatively. And innovative governance keeps things in line so you can sleep at night! Let me know if you have any other questions and get posting in the Academy with your wins!