Exam PL-600 Revision Notes: Evaluating an Organisation, Metrics and Existing Systems

Welcome to my second post in my series focused on providing a set of revision notes for the PL-600: Microsoft Power Platform Solution Architect exam. Last time, we kicked off the series by looking at some of the concepts and considerations around planning for our Power Platform solution. We are now going to continue our focus on the first area of the exam, Perform solution envisioning and requirement analyses, by looking at the following two topics:

Identify organization information and metrics

identify desired high-level organizational business processes

identify business process automation opportunities

assess an organization’s risk factors

review key success criteria

Identify existing solutions and systems

evaluate an organization’s enterprise architecture

identify data sources needed for a solution

define use cases and quality standards for existing data

identify and document an organization’s business processes

Before we start a Power Platform or any IT project, it will be necessary to understand many factors relating to the organisation, which will have a significant impact on the approach, timescales, and shape of our implementation. A sufficient investment into this will pay dividends in the long term, ensure we can deploy our solution successfully and deliver value in the years ahead. Let’s dive into these areas to guide you on how we can best succeed in this endeavour and the types of things we need to understand to do well in the exam itself.

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 in this exam. 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.

Identifying and Capturing Business Processes

Organisations run on repeatable processes. It’s how we ensure things run properly and that our customers are provided with a consistent experience each time. A solution architect will be expected to understand the business processes we want to map across into the Power Platform. For example, we could have a manual data entry process involving a paper-based system that we wish to convert into a model-driven Power App / Dataverse solution. But, to do this, we need to have a good grasp of how this process works. So what’s the best way of addressing this knowledge gap? One of the first things we should do is see the process in action. We need to identify individuals in the organisation who know this process like the back of their hands and, consequently, carry it out very frequently. These are the most valuable people in our project; they bring an incredible depth of knowledge and experience relating to their chosen area. Typically, as well, they will have a substantial investment towards ensuring it is done correctly. Work collaboratively with these people, ask as many questions as possible (remember, there’s no such thing as a stupid question) and start to demonstrate the benefits that the new Power Platform solution will bring into the equation. The level of their interest and engagement towards your efforts will make or break your project, so you must get them on your side early on.

Once we have a good grasp of how the process works, we need to document them somehow. Arguably (and as you might expect, given we’re all about Microsoft here on the blog 😉), our most effective tool to capture down our business processes is Microsoft Visio. Within this, we can typically use a Basic Flowchart or a Cross-Functional Flowchart to map out each stage of a process, end-to-end. The latter is beneficial if our process covers multiple areas of the organisation, as we can very easily incorporate new swimlanes to indicate other teams, departments or divisions within our organisation. Depending on the complexity of the overall process, it may be prudent to create several different types of documents with an overarching process diagram that provides clear links to the lower-level processes. The (very) basic example below gives your a flavour of how this may look:

The Lead Generation Process and Sales Approval Process steps are sub-processes, which we can tell by their appearance. Therefore, we would want to have a separate process document that provides the lower-level detail on what occurs at these stages. What’s also valuable about our flowcharts is that we can indicate steps that result in a specific output occurring. For example, in this diagram, we can demonstrate when a physical document is generated via the shape for the Generate Sales Order step. As solution architects, we should understand deeply the organisation we’re working with. On occasions, we’ll have some input when compiling together these types of diagrams - either for an existing process we plan to map out into the Power Platform or for the new envisioned process after we deploy our solution. Therefore, familiarity with all of this and the various shapes available as part of our flow charts will be essential.

The Importance of Business Automation

As stated already, the majority of processes within an organisation will be repeatable. As such, these will be ripe areas of attention from an automation standpoint. Focusing our attention here can drive numerous benefits for the organisation, including:

Improved Efficiency: An automated process will typically become faster to execute, thereby increasing our agility as an organisation.
Time or Cost Saving: Manual process may require hours of actual human time to complete each week. Through automation, we can remove burdens on our time and (hopefully) free up our colleagues to do something more useful instead. We can also reduce costs due to the decreased risk of errors automation brings into the equation. With the best will in the world, we are all human and make mistaeks on occasion. 😇 These can sometimes cause a high financial or reputational cost if they occur.
Greater Assurance: An automated process can assure our stakeholders in the organisation, as they then know it will always occur and will not be subject to unexpected factors impacting it, such as a colleague’s illness.

Remember, though, that it will be impossible to automate an entire process fully; indeed, aiming for this and putting blind faith in the machine to do everything could be somewhat foolish. Because you never know when something like this may happen…

Therefore, we should ensure appropriate human touchpoints are included, where sensible and relevant, and accept that our automated processes may require a degree of ongoing observation once implemented.

Common Risk Factors for Power Platform / IT Projects

All projects, and especially those in the IT world, involve a degree of risk. And, contrary to one organisation I once dealt with who stated that all their IT projects must have “zero risks”, we must accept and account for the potential effect of a risk occurring during any stage of our IT project. Risks can take many different forms and can often manifest during the most unlikely timeframes within a project. Some examples include:

Ch-ch-ch-ch-changes: We change our minds all the time. Instead of being good and having a salad for tea, we ring up the takeaway and order a huge pizza instead 😁. Organisations are much the same and can often be borderline maddening to work alongside when unexpected changes land in our project, which may scupper our plans to go live with our solution. The project team should have documented and communicated change control procedures to help mitigate against this. We can also lessen the impact of a potential change if you work to Agile principles and reduce our horizon for delivering our product accordingly.
User Adoption: Our solution will only be effective if it becomes woven into the organisation’s fabric, and this is often the most overlooked and challenging element of any project. Collaboration, involvement and communication are essential with our stakeholders to get this right.
Communication: The most high-performing project teams are the ones where communication flows freely. If contact is lacking, restrained or hampered due to conflicts on the team, our project will invariably suffer.
Budget: The party can keep rolling until the check lands. Projects are much the same, and we will often have a fixed budget for our project that becomes impossible for us to exceed. Compromise and, where achievable and sensible, shortcuts may need to result to ensure we can still deliver what we hoped from the start.

Based on my own experience, these give you a flavour of the most common type of risks that can surface through the project. Your mileage may vary, and, therefore, you must look to document these early on. If your project is working towards PRINCE2 principles, you could put together a risk register to provide a clear history and status of each identified risk. Keep in mind as well (and this is particularly relevant for PRINCE2 - maybe I should blog on this too 🤪) that risks could be positive or negative in terms of their effect. Some risks we may want to allow to continue if the perceived benefit outweighs the cost. A solution architect’s role is to leverage their domain expertise in articulating or identifying risks as they emerge.

How to Measure Success?

We can measure success in multiple ways, and typically, this will differ based on the organisation we are working with. It may be that just going live with our solution is considered our single and only success criteria. I would, respectfully, suggest that this takes a very short-sighted view. Ideally, we should attempt to identify and implement several more success criteria that are ideally measurable to some degree. For example, we could have a success criterion based on the volume of feedback we receive or the number of high-priority “snagging” items received during our go-live period (where less is considered better). Ideally, the entire project team should sit down and commit to at least half a dozen methods to determine our project’s success following the go-live. The solution architect would play a role here in encouraging this to occur and suggesting relevant criteria based on what’s happened during previous projects.

Evaluating the Landscape: How Does Your Power Platform Solution Fit In?

Depending on the size, age and industry type of the organisation we are working with, our Power Platform project could be classed as either a “greenfield” or a “brownfield” project. These terms are borrowed from construction and indicate the state of the environment we plan to work within. Greenfield projects will have little (or no) existing constraints or environments to contend with. In contrast, our brownfield projects will need to factor in and, very often, co-mingle alongside an existing solution built out. As solution architects, we’ll need to do the appropriate analysis to determine what type of environment we are moving into and provide a definitive answer to the question above at the earliest possible opportunity. As part of this, having a good general awareness of Microsoft 365 or Microsoft Azure will be helpful and, even on occasion, older legacy environments involving Windows Server and all manner of tech you secretly prayed you’d never see the sight of again.

Data Sources, the Power Platform and Opportunity Leveraging

Given that, within the Power Platform, we will be building a business application solution of some description, understanding and, where possible, leveraging some of the various data connectivity options available to us will be essential. Broadly speaking, solution architects will need to consider and account for the following data sources in projects:

Microsoft Dataverse: For situations where the organisation has no formal database or system in place already, Dataverse becomes our first preference option to consider. This will also be true if we anticipate consuming one or several different Dynamics 365 Customer Engagement applications, which may already exist.
Flat-File: This is not a “source” in the sense that we would connect a Power App up to an Excel Spreadsheet (try it if you dare… 😨), but we will need to consider the amount of raw data that we potentially need to bring into our Power Platform solution and, as part of this, how we can use them alongside some of the other solutions listed here or how we can incorporate them as part of tools such as dataflows.
Relational Data Sources: These could be anything from SQL Server to more complex sources such as Azure Synapse Analytics (AKA Azure SQL Data Warehouse). Typically, data stored within these environments will be well-formed and, therefore, require little additional intervention on our part from a modelling standpoint.
Third-Party Systems: Often, we will not be in a perfect, 100% Microsoft world during our Power Platform projects, meaning we have to move out of our comfort zone a little bit. 😀 The precise mechanisms for incorporating these data sources will vary from project to project. Still, our typical trajectory from a consideration standpoint would be to leverage an existing connector first. If this is lacking, consider instead building a custom connector of some kind that will allow us to interface with our chosen third-party system.

While analysing the organisation’s current environment, the solution architect should carefully observe and identify opportunities to leverage a suitable connector, which could satisfy an integration challenge or speed the progress of our project by allowing us to leverage investments made into existing technology. Alongside this, tools such as the on-premises gateway will be invaluable tools in our arsenal, and we should exploit opportunities to actively put these kinds of solutions forward.

Detail is essential, particularly at the early stages of a Power Platform project. Therefore, prompt and due attention to everything we’ve discussed in today’s post will be essential if you plan to get to the finish line successfully. Next time, we’ll evaluate how we can capture requirements and perform a proper fit/gap analysis for our project.