Welcome to the third post in my series focused on providing revision notes for the PL-600: Microsoft Power Platform Solution Architect exam. Previously, we looked at the things we need to evaluate about the organisation adopting our Power Platform solution. In today’s post, we’ll round off our discussion of the first exam area (Perform solution envisioning and requirement analyses) by looking at the final two topics:

Capture requirements

• refine high-level requirements
• identify functional requirements
• identify non-functional requirements
• confirm that requirements meet an organization’s goals

Perform fit/gap analyses

• determine the feasibility of meeting specific requirements
• evaluate Dynamics 365 apps and AppSource options to solve requirements
• address functional gaps through alternate solutions
• determine the scope for a solution

Requirements form the cornerstone of any IT project and can make or break our implementation, depending on how accurately and well-articulated they are. In today’s post, we’ll look at the different types of requirements we will typically be faced with. Alongside this, we’ll dive a bit deeper on the subject of the Dynamics 365 Customer Engagement applications, AppSource, and how these provide our best mechanism to address gaps between what is available in the platform and what we may need to build to deliver the solution we need.

As a reminder, the aim of this post, and the entire series, is to provide a broad outline of the core areas to keep in mind when tackling the exam, linked to appropriate resources for more focused study. Ideally, your revision should involve a high degree of hands-on testing and familiarity with the platform if you want to do well. And, given the nature of this exam, it’s expected that you already have the necessary skills as a Power Platform Developer or Functional Consultant, with the certification to match.

What is a Requirement?

A requirement is a basic ask or request that the organisation expresses out of any IT solution we build. As solution architects, we won’t typically have much involvement as part of generating requirements; however, we will have an input (and stake) in reviewing and ensuring that requirements meet the four litmus tests outlined below:

• Clear: Anything we ask for in life needs to be expressed clearly. If I enter a restaurant, ask for a sandwich and then get annoyed when a Ham sandwich arrives, then it’s my fault. Requirements are much the same, and we should push back whenever the organisation comes to us with a poorly expressed or potentially confusing ask.
• Actionable: A well-defined requirement will clearly outline the steps needed to achieve a result.
• Feasible: A requirement needs to be achievable, in both practical and technical sense. A requirement to build a rocket in 2 weeks to fly to the moon is very clearly defined but hardly possible or achievable. For these situations, we can leverage our experience of previous projects/implementation to highlight requirements that will be challenging or near impossible to implement.
• Testable: We can only verify that we can meet a requirement by performing the action involved as part of a test - whether this is done manually or automated.

By ensuring our requirements meet the four objectives above and, as solution architects, by highlighting this early on, we can avoid potential problems down the road and less anguish for our development team when they are reviewing them for the first time. Challenge the organisation or requirement author as much as possible until you’re satisfied that what is being asked for is well understood and accurately captured.

Functional vs Technical Requirements

As solution architects, we will typically be faced with two kinds of requirements - functional and technical requirements. Functional requirements, as the name implies, will always express a desired function or capability that the solution needs to provide. Here’s an example of a functional requirement:

As a sales manager, I want to approve all quotations before they are sent to customers, so that I can ensure all pricing details, discounts, and products being sold are correct.

For a functional requirement, we will typically inhabit a persona within the organisation. By this, we don’t mean that you will become a new initiate of the Phantom Thieves; instead, a persona will always align to a particular role within a team or division. From there, we can then express the desired behaviour that the system needs to support before then describing the value of the solution. Notice that throughout this, we’re not making reference to a technology or a Power Platform feature. This is a common pitfall we must avoid when structuring our functional requirements by ensuring we leave them as agnostic as possible. A meaningful functional requirement will always be structured in the manner indicated above before being broken down further once development work begins.

Technical, or non-functional requirements, in comparison, will typically relate to a metric or specific feature that the solution must align to as part of its day-to-day usage. For example, a typical technical requirement for any Software as a Service (SaaS) solution is to ensure high uptime (availability) during core business hours. Another could relate to where data is stored, as our organisation may mandate that all data is held within a specific region. In most cases, these types of requirements may already be covered as part of what is built out already in the Power Platform, but there may be situations where we need to configure aspects of our solution (for example, by ensuring we align our Microsoft Dataverse environment to the correct geographic location) or build out a technical requirement entirely from scratch (e.g. based on compliance or regulatory non-functional requirements, we need to create and then secure specific columns in the application using column security profiles). We should always evaluate non-functional requirements closely so that we can adequately gauge any effort we need to direct towards “filling the gap”

Aligning Requirements to a Measurable Output

To help make your requirement more robust and, crucially, testable, we should take steps to attach a measurable output to a requirement. Let’s return to the example requirement we looked at earlier:

As a sales manager, I want to approve all quotations before they are sent out to customers, so that I can ensure all pricing details, discounts, and products being sold are correct.

One way we could improve this further is by adding a measurable output to the final portion:

As a sales manager, I want to approve all quotations before they are sent out to customers so that I can ensure at least 90% of quotations raised have the correct pricing details, discounts, and products applied when first generated.

With the additional, measurable element in our requirement, we’ve can then further refine the steps we need to follow to achieve the requirement. For example, we could start to determine the common factors that cause a quotation to be rejected and build these validation steps into the system before the quotation even appears in front of the sales manager. In addition, we can look to test this particular measure as part of a User Acceptance Testing (UAT) round by ensuring that this threshold is always exceeded. Consider the applicability of a measurable output when evaluating a requirement for the first time and, if prudent, suggest adding one in where there’s a good case to do so.

What if we can’t meet a requirement?

I get it - when the organisation is pressuring for a solution to be built and when we’re “in the trenches” with a particular project, trying to meet all the requirements is a noble ambition. But it can often be the downfall of many projects and means we ignore the critical rule we discussed earlier - the feasibility of a requirement. A non-feasible requirement could be due to various reasons and often for circumstances outside of our control. The solution architect needs to be adept at spotting problematic requirements early on and suggesting mechanisms through which a requirement can be adjusted or dropped entirely. The earlier, the better for this conversation, as we want to avoid sudden blockers emerging in our project due to a lack of foresight. The conversation may be a difficult one for the organisation to accept, so be prepared for pushback and, if at all possible, prepare for a Plan B. For situations where a requirement is impossible to achieve, due to the time, effort, and resources involved, there are two avenues a solution architect can stroll down to try and find this alternate approach - one of the Dynamics 365 Customer Engagement applications or AppSource.

Dynamics 365 Customer Engagement Apps Overview

A major benefit of using the Power Platform and Microsoft Dataverse, in particular, is that we can install core Dynamics 365 applications on top of these environments and leverage pre-built functionality addressing several common scenarios. These set of application, commonly referred to as the customer engagement apps, include the following:

• Dynamics 365 Sales: Designed for organisations selling to business (B2B) and consumers (B2C), the application provides a range of sales force automation capabilities. There are two versions of Dynamics 365 Sales available - Professional, aimed at smaller deployments, and Enterprise, which includes access to more advanced components, such as Competitors.
• Dynamics 365 Customer Service: For scenarios where you need to make cases/incidents for your customer base, this application will meet and exceed your needs. With a range of features allowing organisations to implement service level agreements, entitlements and basic/complex routing scenarios, there is plenty available here that we can implement quickly and easily.
• Dynamics 365 Field Service: The Customer Service application is well designed for when you are providing remote support to your customers. However, for situations where you need to deliver on-site services, the capabilities available as part of the Field Service application may be worth consideration. With advanced scheduling capabilities, the ability to process on-site jobs via work orders and a dedicated mobile application for field staff, the solution is ideal if your organisation delivers on-site services frequently.
• Dynamics 365 Marketing: The Sales application includes some basic marketing features “out of the box”. But, for situations where you need to manage events, execute complex customer journies or perform advanced segmentation of your customer base, the Dynamics 365 Marketing application is the best 1st party application to turn to.
• Dynamics 365 Project Operations: As the successor product to Project Service Automation, Project Operations provides capabilities for us to manage internal project delivery capability, from initial enquiry through to execution and final billing. Customers can choose from a range of deployment options for the product, such as the “lite”, Dataverse-only deployment or the stocked/production-based deployment that integrates alongside Dynamics 365 Finance.

A solution architect should have a good grasp of the core capabilities within each of the above applications. In addition, if there is an opportunity to leverage 50% or more of the functionality available natively within these apps, we are expected to then guide the organisation towards adopting these solutions as the first preference over any bespoke development work. The monetary cost may appear to be higher on paper, but the development and ongoing time maintenance cost may, in some cases, grossly exceed this. Note that there are other Dynamics 365 applications available, such as Dynamics 365 Finance; these applications don’t reside within Microsoft Dataverse and, for the exam, are not a major concern.

AppSource Overview

Microsoft AppSource is the official “marketplace” for finding 1st and 3rd party add-ons or solutions, targeting not only the Power Platform but also other services such as Microsoft 365 too. Using AppSource, administrators can browse the online catalog to find applications and consulting services from different Microsoft partners. Solutions on offer will typically have a free trial of some description, and a review/feedback system is available, therefore providing the assurance that you can trial and verify that a solution will meet your requirements before committing financially. Where possible, organisations should try and align towards preferred solutions, if one is available, as this provides additional assurance that Microsoft has vetted it and the partner’s expertise in addressing a particular requirement. AppSource is accessible via any web browser and requires that you sign in using the Microsoft 365 / Azure Active Directory Account where your Power Platform environment(s) exist.

Demo: Working with Dynamics 365 Applications and AppSource

To better understand how to work with AppSource and the Dynamics 365 Applications, take a look at the video below:

Bespoke Development: When and Why?

The key concern of a solution architect during a Power Platform project is to reduce the need for bespoke development and, as much as possible, ensure we align a solution towards “out of the box” functionality. There are a few important reasons why we do this:

• Components that have been bespoke developed, particularly involving programming languages such as C# / .NET, can become challenging and expensive to maintain in the long term.
• Typically, the individuals who build out bespoke components will have gone off into the sunset to another company or project, meaning we don’t always have the luxury of picking up the phone and parachuting them in when we encounter a problem.
• Given that Microsoft mandates we take two major releases every year, our testing cycles for each release become more difficult for us to complete, as we have to perform more in-depth testing each time. Our problems are then compounded further if our bespoke development relies on application features that have been altered or removed entirely.

I could go on with more reasons, so hopefully, you get the picture. However, there will be occasions where bespoke development is needed. And this is perfectly fine to consider for your project, provided you have exhausted all other avenues; namely, the following list that we talked about in a previous post:

• Dynamics 365 Customer Engagement Apps: As we should already know, all of these applications (also called the “customer data platform” apps) are built upon and leverage the Power Platform extensively. As part of this, we have a range of applications that are designed to meet a variety of standard business requirements, ranging from customer service to managing complex projects. All of these applications rely on the Microsoft Dataverse as the backend data source, meaning it’s incredibly straightforward to factor them in as part of your overall solution. We will look at all of these apps in detail later on in the series.
• AppSource: Within the Microsoft and partner eco-system, there are various additional solutions for organisations to explore and leverage alongside their Power Platform solution. AppSource will be our primary destination to find and install these into our environment(s). The added benefit is that all of these solutions will typically contain a free trial of some description, thereby allowing us to validate their suitability for our project fully. We’ll dive into AppSource in further detail later on in the series.
• Third-Party Solutions: The definition of this would appear to be somewhat unclear, but I would understand this to be any solution available that may sit external to the Power Platform or one that is not tied to any financial cost to obtain. For example, it could be that you need to include a non-Microsoft application or leverage a Power Apps Component Framework (PCF) control available as part of the PCF Gallery to meet your overall requirements. The exact solutions used will be particular to each project.
• ISV Solutions: Typically, most committed Independent Solution Vendors (ISV’s) will have their appropriate offerings available on AppSource. But there may be occasions where this is not practical due to their solution’s complexity, size, or deployment nature. It’s impossible to cover or, indeed, identify (unless any ISV wants to pay me 😁) where to find and locate these. Still, there will often be an occasion to engage one or several ISV’s to leverage a solution they have built.

The typical evaluation trajectory as Solution Architect will follow the list above (i.e. start with Dynamics 365 first and ISV solutions last). And, provided that we have gone through this and eliminated all options, we can then advise building a bespoke solution to meet our requirements.

A solution architects role will be to tell when a requirement needs bespoke development and, as part of this, to articulate why we can’t meet the requirement via one of the other avenues listed above. From there, we should drive efforts towards considering “low-code” solutions, involving components such as Power Automate flows, rather than “pro dev” solutions, such as ones involving C# plug-ins.

Evaluating the Scope of our Solution

Often, our Power Platform solution will majorly impact an organisation and affect many departments, divisions, or business areas. Alongside this, there will then be the need to consider other, existing IT components to bring into the equation as well - either as components that we will replace or that will happily co-exist alongside our Power Platform solution once it goes live. This “scope” can also have a significant influence on the overall architecture of our solution. Let’s consider the following scenarios:

• The organisation wishes to surface data from their on-premises SQL Server database into a canvas Power App. Moving the database to the cloud is not possible.
  • In this situation, involvement of the on-premise data gateway becomes necessary to address the requirement. We then need to consider factors, such as the deployment location, resiliency, and potential network configurations for the gateway to be deployed successfully.
• Our organisation, based globally, requires specific residency requirements for all data used in our solution. Data must reside strictly within the distinct geographies that the organisation and the users operating our solution reside in.
  • Based on this requirement, we would need to carefully review the list of available regions for our Power Platform environments and set up the required number, based on the above. This can have far-reaching impacts, ranging from our data migration to the Application Lifecycle Management (ALM) approaches we need to implement.
• Our solution needs to integrate alongside several bespoke API’s built by the organisation, using SOAP and other “legacy” technologies. We need to ensure that these endpoints can be leveraged straightforwardly from all core Power Platform components.
  • From a technical standpoint, several custom connectors will be necessary to meet this requirement. When evaluating this from the architecture side of things, we then need to consider documenting the various endpoints, their purpose, the data that flows between them and the potential risks involved in sharing data between the different endpoints.

Our base requirements, if well organised, will allow the solution architect to get a good grasp of the overall scope of our solution. A smaller “playing field” for our project will, obviously, make our lives easier…with the opposite being as we’d expect. 😉 As solution architects, having a keen understanding of this and, most crucially, of the potential challenges that may emerge will be vital.

Hopefully, after reading today’s and the two previous posts so far in the series, you have a good grasp of the vital early preparation activities a solution architect will typically need to be involved in. Tune in next time when we’ll move on to see how we can begin designing a Power Platform solution and dive into some detailed topics such as solution topology approaches and how to build an ALM process using Azure DevOps.