Welcome to the first post in my new PL-600 exam blog and video series! I had some great feedback from the recent series I did targeting the PL-400 Power Platform Developer exam, with lots of people asking me which exam I would do next. So I thought I’d canvas the community to see which one they were most keen for me to look at next:

Thanks to everyone who reached out to me about my recent blog/video series on the PL-400 #PowerPlatform exam. It was such a blast that I'm already planning the next series! Let me know what YOU think should be covered by completing the form below:https://t.co/lgOpc2khFI pic.twitter.com/mVGnuWivxJ

— Joe Griffin | #ProCodeNoCodeUnite (@joejgriffin) July 6, 2021

The results of this were overwhelmingly decisive…

So let’s kick off then by looking at Exam PL-600: Microsoft Power Platform Solution Architect. Passing this exam is a prerequisite to obtaining the Microsoft Certified: Power Platform Solution Architect Expert certification. PL-600 is the highest-level exam and certification that we can earn today within the Business Applications space. Microsoft expects candidates to demonstrate an excellent and broad knowledge of implementing an effective Microsoft Business Applications solution. In addition, candidates are expected to know and have experience leading adoption in the capacity of a solutions architect. We’ll dive into what this means as we get into the series proper, but, in short, I cannot understate the level of expertise and leadership required to adopt this role successfully. This series will aim to cover the essential topics you need to learn, and, where appropriate, I’ll provide some video-based content to help explain subjects and offer an additional revision tool you can refer back to.

As with all other exams, we need to evaluate a list of Skills Measured and demonstrate sufficient competency within these areas during the exam itself. The first area is titled Perform solution envisioning and requirement analyses and has a 35-40% weighting; therefore, we should expect to see plenty of questions come up that assess us in this area. The focus for today’s post will be to look at the first section within this group, Initiate solution planning, which covers the following topics:

Initiate solution planning

• evaluate business requirements
• identify Microsoft Power Platform solution components
• identify other components including existing apps, AppSource apps, third-party components, and components from independent software vendors (ISV)
• identify and estimate migration effort

Solution architects will play a leading role in planning out any adoption of the Power Platform within an organisation, and all of these are important considerations that we have to make. As part of this post, we’ll provide details on the concepts you’ll need to grasp to ensure you are successful in this area and prep you accordingly for the exam.

One final thing before we dive in…the aim with 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.

Evaluating Power Platform Components

If you’re reading this and planning to sit the exam, there is a general expectation that you already are very familiar with the Power Platform and what it can do. But it’s always good to get a quick refresher and validate our understanding. 😉

The Power Platform is Microsoft’s low-code, rapid business application development platform, which can help inspire organisations to do more with less, and often forego the need to develop a new software solution from scratch. Within the Power Platform, we have several different independent yet closely related products that we can leverage:

• Power Apps: These come in two flavours. Model-driven apps are designed for desktop-based scenarios, where your application needs to sit within the confines of a strict data model. In this respect, you may often hear these types of apps referred to as data-driven applications. If you’ve come from a Dynamics CRM / Dynamics 365 background, then you may recognise a lot of the functionality available within model-driven apps. In comparison, Canvas apps are geared towards mobile-first scenarios, providing app developers with a high degree of freedom in designing their apps and deploying them to a wide variety of different devices or alongside other applications within the Power Platform. Canvas apps also have the benefit of being interoperable with a wide variety of data sources. Whether you wish to connect to an on-premise SQL Server instance, other Microsoft solutions such as SharePoint or third-party apps, such as Twitter, connectors are available to perform common Create, Read, Update and Delete (CRUD) operations and more.
• Power BI: A next-generation Business Intelligence (BI) tool, Power BI provides impressive data modelling, visualisation, and deployment capabilities that enable organisations to understand data from their various business systems better. Despite having its own set of tools and languages, traditional Excel power users should have little difficulty getting to grips with Power BI, thereby allowing them to migrate existing Excel-based reports across with ease.
• Power Automate: As a tool designed to automate various business processes, Power Automate flows can trigger specific activities based on events from almost any application system. It is a modern and flexible tool that you can use to address various integration requirements.
• Power Virtual Agents: Many of us will be familiar with the various live chat solutions we see across different websites that are often operated by one or multiple individuals and help answer commonly asked queries. Power Virtual Agents takes this a step further by allowing for an automated, always-on bot to reside within your website or Microsoft Teams site that individuals can then engage with. Developers construct a chatbot using an interactive editor and can straightforwardly incorporate external integrations without writing any code.
• Microsoft Dataverse (formerly known as the Common Data Service): The Dataverse provides a “no-code” environment to create tables, relationships and business logic, to name but a few of its capabilities. Within the Dataverse, Microsoft has standardised the various tables to align with The Common Data Model. This open-source initiative seeks to provide a standard definition of commonly used business data constructs, such as Account or Contact.

The diagram below lazily stolen lovingly recycled from Microsoft illustrates all of these various applications and how they work together with other Microsoft services you may be familiar with:

Understanding how each separate Power Platform application can work in tandem is critical when building an all-encompassing business application. The examples below provide a flavour of how these applications can work together, but the complete list would likely cover several pages:

• Including a Power Automate flow as part of a Dataverse solution, allowing you then deploy this out to multiple environments with ease.
• Being able to embed a Power BI tile or Dashboard with a personal dashboard setup in a model-driven Power App.
• Embedding a canvas-driven Power App into Power BI, allowing users to update data in real-time.
• Call a Power Automate flow from a Power Virtual Agent to return information from an on-premise Oracle database.

As a solution architect, we are expected to be the resident Subject Matter Expert (SME) in the Power Platform and advise on the best mix of capabilities to leverage to meet a business requirement. Therefore, we must have a solid grasp of the above for our day-to-day role and the exam itself.

And the Rest…Dynamics 365, AppSource and more

One of the benefits of working with the Power Platform is that we can generally turn to various “off the shelf” capabilities to help meet our particular requirements. As a solution architect, we need to have a good awareness of what’s out there and available and, as much as possible, reduce our reliance on any custom development work and effort to help meet a particular requirement. The benefits of this are clear; we can reduce the time it takes to build our solution, avoid situations where we rely on complex/unwieldy functionality and reduce “cost”. And by “cost”, I’m not just referring to a monetary value. There will always be a hidden cost, in terms of time/effort, that a bespoke solution will bring to the equation. Our role is to evaluate this, compare it against the monetary cost of bringing in a pre-built solution instead and ensure we have achieved an effective balance. In short, we should try and take a leaf out of Thanos’ playbook here…😏

So what are the things we need to be aware of here? We can broadly fit this into four categories:

• 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.

Mapping Business Requirements into the Power Platform

Although we won’t be responsible for capturing these, the solution architect will be relied upon to evaluate a set of requirements and be expected to suggest a solution using their SME domain knowledge. The challenge emerges in sometimes choosing the “right” solution. We can typically solve the same kind of problem using multiple mechanisms in the Power Platform, but we often need to be guided towards preferring a functional and “out of the box” solution as our first preference. An excellent example of this could be using a Power Automate flow to contact an external API instead of a Microsoft Dataverse plug-in. Both of these options are viable from an implementation and workability standpoint, but it’d be best to choose a Power Automate flow in this situation. The primary reason? It reduces our reliance on custom code and will make our solution easier to maintain once it goes live. This represents one of the core elements we, as solution architects, must always be conscious of when recommending a solution to the business. To provide a more comprehensive flavour, the table below includes some example business requirements and an indicated approach on how we could map these across effectively into the Power Platform:

As we can see from the above, requirements are mapped as much as possible to an existing, available application within Dynamics 365. As discussed earlier, and for exam purposes, we need to be aware and leverage this functionality where feasible as part of our projects.

Individual requirements for a Power Platform project will typically vary, and, as a solution architect, we should expect the unexpected. However, there will be situations where a degree of commonality emerges. Therefore, you can be confident when suggesting a potential approach; if it worked well last time, chances are it will do again.

Estimating Migration Effort

In pretty much all cases, organisations will be looking to migrate into the Power Platform from some other kind of system. Whether this is a manual-based process, an existing, on-premise system, a solution from another vendor…the list is endless. Each new project that a solution architect will be involved in will throw up its own set of unique challenges and circumstances that can impact our migration and the assumed effort. To help us make the appropriate determinations here, here are some suggested questions that we can ask the organisation:

• How normalised are the datasets that need to be migrated across? Data that already maps well across into Dataverse tables will present little challenge from an import standpoint. In contrast, other datasets or an incomplete process will require additional consideration and time to fit within the Power Platform.
• What is the size of the organisation in question? As a good rule of thumb, smaller organisations will be a lot easier to work with and, therefore, any estimates can reflect accordingly.
• Is the organisation already using the Power Platform or equivalent cloud technologies, such as Microsoft 365 or Microsoft Azure? The organisation’s maturity in working in a cloud-first world can impact your project’s ease or difficulty. A relatively mature organisation should be prepared to introduce technologies such as the Power Platform with less overall fuss.
• What other system(s) need to integrate alongside the Power Platform solution? This will always present the most challenging aspect of any project and can significantly increase the effort involved as part of your migration.
• What dependencies does our project have on other teams, departments or external organisations? Projects split across a wide net can often suffer from frequent communication or collaboration issues. If the right person/team is not available at the right time, it could even severely impact your plans to go live. The solution architect should have a good grasp of all core individuals/teams required and support efforts to align each one at the right time.

Answering these and similar questions will allow a solution architect to understand how costly the migration will be in terms of resource and effort. From an estimation standpoint, you should also plan to add any appropriate buffers into anything you present to the business; things can, and will regularly, go wrong, so you want to account for that and avoid any awkward conversations down the road.

If you fail to plan, you plan to fail. This sentiment applies so well to the Power Platform, so understanding the topics covered here will be essential as you start to design your solution. Next time in the series, we’ll look at how we can evaluate an organisation’s existing systems, information, and core metrics to ensure we plan for success as a solution architect.