Microsoft Power Platform solution architects have functional and technical knowledge across the Microsoft cloud ecosystem and other third-party technologies. This chapter introduces the solution architect’s role, the Power Platform, and the broader Microsoft stack. You will be taken through a journey covering the hands-on approach used to apply best practices, solve problems, identify opportunities, and increase the value of the customer’s investment in Microsoft solutions.

In this chapter, we are going to cover the following main topics:

• Laying the foundations for great solution architecture
• Understanding the solution architect’s role
• Power Platform architecture overview
• The Microsoft cloud-based ecosystem
• A hands-on approach to solution architecture

By the end of this chapter, you will be equipped with the tools and context to propel you through the activities and scenarios in the chapters to come. You will also gain an awareness of the various components and moving parts that make up Power Platform implementations of varying sizes and complexity.

The advent of cloud-based solutions has brought forth the era of scalable, highly performant, and secure business applications. Planning, designing, and building great Power Platform solution architecture requires the consistent application of a set of principles. Each organization and solution is unique, and while a single solution design pattern does not exist, the following nine concepts will help you lay the foundations for a great Power Platform solution architecture:

Figure 1.1 – The pillars for great solution architecture

Now, let’s outline these nine key concepts for great Power Platform solution architecture.

The security concept

Data is the crown jewel of most organizations. The security concept encompasses every aspect of the implementation. You define the authentication strategies, identify network vulnerabilities, and management of secrets, certificates, and other credentials. These activities will result in effective perimeter control for your solution.

The definition of a solid security concept will do the following:

• Provide the client with confidence in their Power Platform investment.
• Expedite the implementation and configuration of the solution.
• Reduce the risk of data breaches in production environments.

Through access control, you will also define the level of access that the internal users will be granted. In the chapters that follow, you will learn how to define a security concept that ensures data is placed only in the hands of the right users.

Empowered users – the cloud citizen

The Power Platform provides a wealth of features, allowing users to extend the base implementation. A great architecture blueprint will be cognizant of these user-accessible features and plan for these to be used as part of the user’s daily activities. The Power Platform design will define guardrails to safely empower users to build their components, allowing them to achieve greater productivity through a synergy between the base implementation and user-created enhancements.

In the use case scenarios that follow, you will learn how to define Power Platform guardrails to safely empower users.

Compliance

Privacy and trust requirements vary greatly, depending on the industry, geographical location, scope, and nature of the implementation. Data retention policies and access request channels are defined to comply with local and international regulations.

In this book, you will explore the Microsoft Trust Center tools and capabilities to locate certifications for the components that make up the solution architecture.

Maintainability and supportability

Power Platform solution architects design solutions that leverage the inherent functionality available within each Microsoft component. Making use of the standard functionality within the various Power Apps, Dataverse, and the wider Microsoft ecosystem, configuring and customizing these components are the first implementation point of call. Custom development is considered only when all other options have been exhausted and implemented within the bounds of supported customizations.

Following the configure-first approach outlined and thorough documentation of the implementation build, a solution architect defines the implementation principles and best practices for the teams to follow.

Availability and recoverability

Organizations have expectations regarding the uptime and availability of their critical systems and business applications. As a part of the initial phases of the solution design, these requirements are identified and mapped to Power Platform product capabilities. Solution architects understand the availability and recoverability features within each component in the implementation, and design integrations with retry strategies and fallbacks to prevent the transient faults from impacting the solution.

In the following chapters, you will explore the features available within each Power Platform component, define recoverability strategies, and design integration patterns that benefit from a high level of fault tolerance.

Performant and scalable solutions

Users expect business applications and portals to respond within a specific amount of time. Successful Power Platform solutions take these expectations into account and are designed to perform within the customer’s requirements. Solution architects document these performance requirements and translate them into actionable implementation tasks. Considerations such as Dataverse capacity planning, integration response times, Power Automate throughput, and Power Apps portal user experience are considerations during the solution architecture process.

In addition to performance, the solution architect plans for the dynamic allocation of resources to scale with changing demands on the system. In the following chapters, you will work through the planning of efficient resource allocation to maximize performance while optimizing costs.

Implementation and operation efficiency

A solid monitoring architecture provides a platform for the detection of faults in the solution before they happen. Monitoring strategies also provide visibility over the usage of resources. Administrators can visualize how efficiently the solution is performing and make adjustments where needed.

In the upcoming chapters, you will learn how to plan effective monitoring solutions to facilitate the efficient operation of the Power Platform systems.

Cloud delegation

The Power Platform and the wider Microsoft cloud-based ecosystem present the opportunity to delegate the responsibility for the setup and maintenance of the management of the underlying platform. Solution architects have greater freedom to focus on the implementation architecture, compared to on-premises solutions, which require careful consideration of hardware and software capabilities, constraints, and ongoing administration overheads.

In the chapters that follow, you will learn how to shift the responsibilities to the service provider, leveraging the Microsoft support infrastructure.

Balanced design decisions

Applying the aforementioned key solution architecture concepts will result in the creation of a scalable, performant, and secure Power Platform implementation. Adhering to these pillars of architecture attracts a cost, be it financial, increased project implementation timescales, or operational agility.

Throughout this book, you will learn how to balance the cost of employing these key concepts versus the benefits to the organization using the systems. You will learn how to initiate discussions with key stakeholders to agree on the goals that are most important to the organization and balance these with the cost/benefits associated with each pillar for great solution architecture.

Note

Look out for the Applying the pillars for great architecture sections, as these are hands-on applications of each of the nine pillars discussed previously throughout the activities covered in the upcoming chapters.

The Power Platform solution architect’s role is to harness their technical knowledge and functional expertise to chart a path for the implementation team, navigating risks, issues, and changes to make the implementation a success. The solution architect is in constant dialog with the project stakeholders, project managers, and development and implementation team members to ensure the project’s vision is achieved.

The following diagram illustrates the key activities a solution architect engages in on a typical Power Platform implementation:

Figure 1.2 – The solution architect’s role

Managing expectations and project scope

A solution architect is responsible for ensuring project requirements are actioned. When requirements inevitably change throughout a project, the solution architect manages the change in scope, assesses the risk and impact these changes would bring to the build, and sets the right expectations regarding timescales for implementation. When scope creep occurs, the solution architect reviews the change, breaks down the new requirements into tasks, and communicates an action plan to the project managers, stakeholders, and the development team, thus preventing unexpected impacts on the project budget and implementation timeline.

Managing expectations and project scope is one of the key activities performed by a Power Platform solution architect and ensures that nothing is over-promised or under-delivered. The chapters that follow provide practical examples for successfully managing project scope and customer expectations.

Defining standards and implementation guidelines

As a solution architect, you will be responsible for defining the development and implementation standards that will help Power Platform consultants and developers build high-quality supportable solutions. Development standards define the technical approach, conventions, and controls expected from the implementation team, and provide a template for the Power Platform solution.

Defining clear implementation standards helps boost the build teams’ output capacity by providing a foundation for the customization of each aspect of the Power Platform, from table and column-naming conventions to advanced integration patterns, peer reviews, and coding standards. In the chapters that follow, you will learn how to define implementation standards that bring new team members up to speed faster and propel your implementation.

Breaking down work into implementable tasks

Organizational requirements are captured in the early stages of a Power Platform project and throughout the various phases of implementation. For these requirements to be implemented in harmony with the overall solution, they are broken down into tasks that the various implementation team members can perform.

Through the use of task management and sprint planning tools, such as Azure DevOps, solution architects analyze these requirements and related user stories, design a blueprint for the implementation, and create tasks that are later assigned to the implementation team members. Having an awareness of the various technical skillsets that make up a Power Platform implementation team, tasks are created to address each aspect of the organizational requirement.

In the chapters that follow, you will work through sample scenarios, and learn how to divide implementation work into discrete pieces of work to match the technical and functional skillsets of a build team.

Leading by example

Having defined the project development standards and designed a blueprint for the Power Platform solution to be implemented, solution architects proceed to lay the foundations for the implementation, helping team members build the solution from the ground up. Junior team members requiring additional attention during the early stages of the project are guided by the solution architect, providing a cushion to handle development issues, and making sure the project timescales are achieved by boosting the overall output for the team.

Helping people reach the same conclusion

During the various phases of a Power Platform project, team members will have varying opinions on the best course of action when implementing customer requirements. The solution architect listens to the options proposed by team members, project managers, and stakeholders, to ascertain the value contribution to the project. It is the solution architect’s job to convey the best solution for the various problems and tasks that come up during the implementation.

Achieving harmony and the cooperation of the implementation team is achieved by creating an environment in which discussions can take place, weighing up the pros and cons, and clearly explaining why the solution blueprint put forth is the best way forward to achieve the current and future organizational requirements. Solution architects do not assume all team members have the same level of technical expertise. They aim to raise the team’s awareness of the benefits the solution design brings to the implementation by highlighting use cases where specific implementation strategies have been successful in the past.

In the coming chapters, you will work through several scenarios where these negotiating skills will come into play, helping the project become a success.

Giving good news and bad news

Everyone enjoys giving people good news. There will be times during the implementation of business applications and portals when unexpected complications arise. This may be in the shape of new technical constraints, changes to the licensing model resulting in additional costs, or the deprecation of product features. A solution architect is responsible for the timely management of these issues, researching solutions to mitigate risks, and communicating the best course of action to the customer or project stakeholders.

In the chapters that follow, you will work through a sample implementation scenario that requires just this type of intervention to ensure the successful completion of a Power Platform project.

This section described the general activities and responsibilities solution architects take on during a typical Power Platform implementation. In this book, you will work through these activities to help cement their understanding for application in future projects.

The Power Platform architecture comprises four key components, the environments and tenants that host these components, and the security capabilities used to control access.

Before delving into the Power Platform components, it is important to understand the data management framework that underpins the majority of Power Platform implementation. Dataverse is the foundation of most Power Platform implementations and is the first topic for our architecture overview.

Dataverse, the foundation of Power Platform data-based applications

Dataverse is a configurable business application data store with advanced processing capabilities and the foundation of most Power Apps-based solutions. Previously known as the Common Data Service, it consists of a relational database made up of tables and fields. Dataverse is configured using a graphical user interface (the Solution Explorer), and a wide range of processing capabilities, APIs, and security features. Dataverse includes a wide range of integration, security, and business process logic features.

The following diagram illustrates the key Dataverse components and interactions:

Figure 1.3 – Key Dataverse components and interactions

The flexible and configurable nature of Dataverse, combined with the wider Power Platform capabilities provides a unique opportunity to solve business problems for a virtually unlimited set of use cases. In the chapters that follow, you will learn how to design Power Platform solutions that make the most of Dataverse’s capabilities.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/powerapps/maker/data-platform) for further information on Dataverse capabilities and configuration options.

The four key Power Platform components

The Microsoft Power Platform is made of up four key components, each delivering powerful capabilities on its own; combined, they provide a compelling framework for the creation of advanced business applications. The four key Power Platform components are as follows:

• Power Apps
• Power Automate
• Power BI
• Power Virtual Agents

An overview of each of the four Power Platform components follows.

Power Platform component 1 – Power Apps

Power Apps makes up one of the five key components within the Power Platform architecture. Model-driven apps, Canvas apps, Power Pages, and Power Apps Portals are the four types of applications available via this low-code/no-code Power Apps framework. All Power Apps are managed via the https://make.powerapps.com portal, which is illustrated in the following screenshot:

Figure 1.4 – Screenshot listing Power Apps in a Power Platform environment

A summary of the three different types of Power Apps available is as follows:

• Model-driven apps are a key component of a Power Platform implementation. They are the user-facing portion of a Dataverse database. The following figure illustrates a simple model-driven app (top) and the corresponding model-driven app editor (bottom):

Figure 1.5 – Screenshot of a model-driven app next to its editor page

Web and mobile users interact with model-driven apps through the web or dedicated mobile applications. The diagram that follows presents a high-level architectural view of the component:

Figure 1.6 – Model-driven apps architectural overview

• Power Pages are internet-facing websites that leverage Dataverse capabilities to present a rich and customizable web experience. The administration section includes default templates for typical requirements such as customer service, partner management, employee self-service, and community portals. These default templates may be extended, or complete custom portal applications may be created depending on the organization’s requirements. The following screenshot illustrates the Power Pages editor:

Figure 1.7 – Screenshot of the Power Pages editor

The diagram that follows presents a high-level architectural view of the component:

Figure 1.8 – Power Apps portal architectural overview

Power Pages are an evolution of Power Apps Portals, providing a superset of the Portals capabilities, including new low-code capabilities and out-of-the-box templates.

• Power Apps Portals are the predecessors to Power Pages, providing the same core functionality but lacking the additional templates and low-code editor capabilities afforded by Power Pages.
• Canvas apps are user interface (UI)-centered applications that can be used standalone or embedded into other Power Platform applications. They may be connected to a Dataverse database or other data sources to present a fully customizable UI for interacting with the underlying data. The screenshot that follows illustrates a sample canvas app and its editor:

Figure 1.9 – Screenshot of a canvas app editor

All three Power Apps use Dataverse as an underlying platform and data source. The administration of usage of Dataverse databases is discussed in detail in the following sections and chapters.

Note Regarding Canvas Apps

The usage of Dataverse is optional within canvas apps, as these applications may be solely connected to alternative data sources, such as OneDrive or SharePoint, without the need for a Dataverse database.

The diagram that follows presents a high-level architectural view of the component:

Figure 1.10 – Canvas Apps Architectural Overview

In the chapters that follow, you will learn how to design leading-edge business applications that benefit from the extensible and rapid development afforded by the three Power Apps.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/powerapps/) for full details on Power Apps capabilities.

Power Platform component 2 – Power Automate

Power Automate is another key component within the Power Platform architecture. It provides a no-code/low-code solution for business process automation.

• Cloud flows provide a graphical user interface to build advanced business logic to suit exacting organizational requirements. Integrations with other Power Platform applications and external third-party systems are achieved through an easy-to-use point-and-click editor.

The following screenshot shows a simple Power Automate cloud flow being edited:

Figure 1.11 – Screenshot of the Power Automate cloud flow editor

The two key components of a cloud flow are the trigger (the action that will initiate the process) and one or more actions that will be executed when the flow runs.

Cloud flows may be triggered manually (for example, a user presses a button) or automatically (a record is created). There is a wide range of cloud flow triggers available. The key Dataverse triggers are as follows:

Figure 1.12 – Cloud flow Dataverse triggers

The wide range of available cloud flow actions provides solution architects with a powerful toolset for the automation of business processes and rapid integration with several Microsoft services and third-party APIs. A full list of Power Automate connectors is documented on the Microsoft documentation page titled Connector reference overview ().

The screenshot that follows illustrates a subset of the actions available when using the Dataverse connector:

Figure 1.13 – A selection of cloud flow Dataverse actions

The diagram that follows presents a high-level architectural view of the component:

Figure 1.14 – Cloud flows architectural overvie

• Desktop flows are designed to automate rule-based tasks on a user’s workstation. They provide a wide range of conditions and actions that interact with UI elements, Excel files, web browsers, and various other systems typically available in a user’s workstation.

The following screenshot illustrates a simple desktop flow being edited:

Figure 1.15 – Screenshot of the desktop flow editor

Cloud flows and desktop flows provide a rich toolset for business process automation. In this book, you will learn how to create architectural blueprints that leverage this powerful toolset.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/power-automate/) for detailed instructions on the creation and administration of Power Automate flows.

Power Platform component 3 – Power BI

The third Power Platform component discussed in this book, Power BI is an analytics and reporting framework that connects to various data sources, to present high-impact visuals. Advanced data visualizations can be quickly generated from multiple data sources and presented through a range of software services. The diagram that follows presents a high-level architectural view of the component:

Figure 1.16 – Power BI architectural overview

Power BI reports are edited using either the Power BI desktop app or the web version of the report editor. The following screenshot presents a Power BI report in the process of being edited:

Figure 1.17 – Screenshot of the Power BI report editor

Working through the implementation scenarios discussed in this book, you will learn how to plan and design Power BI-based solutions to solve an organization’s most complex reporting business requirements.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/power-bi/) for detailed information on Power BI capabilities, data modeling, development of Power BI reports, and best practice guidance.

Power Platform component 4 – Power Virtual Agents

Organizations streamline costs and provide their customers with a responsive user experience using Power Virtual Agents. Users interact with the platform through various channels, including web chat and SMS messaging, benefiting from advanced routing capabilities.

The following screenshot illustrates a Power Virtual Agents chatbot test facility:

Figure 1.18 – Screenshot of a Power Virtual Agent being tested

Power Virtual Agents can be embedded within websites and deployed to entities including Facebook, Slack, Twilio, email, and mobile apps. The following diagram provides an overview of the Power Virtual Agents architecture:

Figure 1.19 – Power Virtual Agents architectural overview

In this book, you will learn how to define customer interaction strategies that leverage the cost-saving and operational benefits of Power Virtual Agents.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/power-virtual-agents/) for step-by-step guidance on the creation of Power Virtual Agents.

Other Power Platform building blocks

The previous sections described the four key Power Platform components. These components are underpinned by two additional building blocks:

• Data connectors

Data connectors facilitate integrations between Power Platform components and external systems, solving previously complex integration problems with just a few clicks. Connections to Dataverse, SQL databases, SharePoint files, and various other sources of data are easily accessible through the use of data connectors.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/connectors/) for further information on available Power Platform connectors and their capabilities.

• AI Builder

A pivotal tool in the Power Platform arsenal. AI Builder provides a no-code solution for the creation of AI-powered automation processes.

Further Reading

Please visit https://docs.microsoft.com/en-us/ai-builder/ for full instructions on using the AI Builder for Power Automation, Power Apps, and other Microsoft services.

In the coming chapters, you will navigate through the use cases for these two building blocks, and design architectural blueprints to maximize an organization’s investment in the Power Platform and the wider Microsoft ecosystem.

Environments and tenants

Power Platform applications exist within an environment. In turn, environments are hosted within a Microsoft tenant. A Power Platform environment is made up of the following components:

• Name: A textual label for the environment
• Location: The geographical region where the data and configuration will be stored within Azure data centers
• Admins: The users that will administer and configure the environment
• Security groups: Controls that define who can access specific data records and application features
• Apps: Model-driven apps, portals, canvas apps, and other applications that exist within the environment
• Flows: Power Automate components that implement business process and integration routes
• Bots: Power Virtual Agents chatbots that are configured to interact with users
• Connectors: Identifies the connections that have been configured for Power Platform and external systems
• Gateways: Components that allow the integration with on-premise applications
• Dataverse: An optional Power Platform component and data store instance used by various Power Apps, such as model-driven apps

The following screenshot presents a typical set of development, test, and production Power Platform environments:

Figure 1.20 – Screenshot of a Power Platform environments list

Multiple environments may be created to support the development and release cycles. A typical Power Platform implementation includes development, test, and production environments. They may all be hosted within the same tenant or spread across a multi-tenant architecture. In this book, you will learn how to decide on the best environment and tenant strategy to achieve the organization’s goals.

Further Reading

Please follow the documentation link (https://docs.microsoft.com/en-us/power-platform/admin/environments-overview) to review the options available when managing Power Platform environments.

Security

The security of data hosted within a Power Platform environment is enforced through the following layers:

• Azure AD

The cloud-based Active Directory solution. Users are configured for access to specific resources, assigned security groups, and authentication policies.

• Licenses

Assignment of licenses to Azure AD users grants them access to specific Power Platform applications, providing an additional access security layer.

• Environments

Assigning security groups to Azure AD users sets them up for access to the applications within environments associated with those security groups. An additional security layer for Power Platform applications and data sources.

• Data loss prevention policies

Data loss prevention policies define the types of connectors and inbound/outbound data privileges afforded to users of Power Platform applications.

• Security roles

Security roles provide granular control over the data tables and columns stored in the Power Platform Dataverse. They further control access to specific features within Power Platform applications.

• Encryption

Power Platform applications benefit from the encryption of data both in transit and at rest.

The various security features and considerations will be discussed in more detail in the upcoming chapters, where you will learn how to define a security concept document to satisfy an organization’s strict requirements.

Power Platform application life cycle management

Application life cycle management (ALM) is a set of disciplines through which Power Platform projects can be defined, implemented, deployed, and operated through a controlled framework. It is a cyclical set of activities and processes through which Power Platform requirements are captured, broken down into tasks, developed, tested, and deployed. Once deployed, the operation of the system is managed and monitored, and the next cycle is optimized based on lessons learned.

Figure 1.21 – Power Platform ALM activities and key components

ALM is the key to the success of any Power Platform project. In the chapters that follow, you will work through a set of practical scenarios, configuring Azure DevOps to manage the life cycle of a Power Platform project, configuring task management, source control, build, unit test, and automated deployment pipelines, and monitoring capabilities.

The Microsoft cloud-based ecosystem caters to a wide range of business needs. Solution architects are aware of the capabilities afforded by this rich set of business applications and resources. In this chapter, we will review Dynamics 365 business applications, Microsoft 365, Azure, and AppSource.

Dynamics 365

Several Dynamics 365 applications are based on the same DNA as Power Platform model-driven apps. The following Dynamics 365 applications use Dataverse as the backbone for their data storage and business logic processing capabilities:

• Dataverse-based Dynamics 365 applications – Dataverse is the foundation for the following applications:
  • Dynamics 365 Sales
  • Dynamics 365 Marketing
  • Dynamics 365 Field Service
  • Dynamics 365 Project Operations
• Other Dynamics 365 applications – The following Dynamics 365 applications also provide a rich feature set outside the confines of the Dataverse framework:
  • Dynamics 365 Business Central
  • Dynamics 365 Human Resources
  • Dynamics 365 Finance
  • Dynamics 365 Supply Chain Management
  • Dynamics 365 Customer Insights
  • Dynamics 365 Commerce
  • Dynamics 365 Customer Voice (uses Dataverse to store configuration and operational data)

    Further Reading

    Please visit https://docs.microsoft.com/en-us/dynamics365/ for full product documentation on all Dynamics 365 applications.

Microsoft 365

Microsoft 365 is the ubiquitous office application platform. Power Platform solutions leverage the capabilities of Microsoft 365 to present a complete solution for most business needs.

The key Microsoft 365 applications discussed in this book are as follows:

• Exchange
• SharePoint
• Office applications (Word, Excel, Outlook, OneNote, Teams, OneDrive, and Microsoft Forms)

  Further Reading

  Please visit https://docs.microsoft.com/en-us/microsoft-365 to review the documentation on the Microsoft 365 suite of applications and services.

AppSource

AppSource is a vital resource for Power Platform and Dynamics 365 solutions beyond the standard Microsoft feature set. Solution architects leverage the applications and extensions found in AppSource to fill functionality gaps. Applications are available for instant download and installation onto your Power Platform environment.

In the use case scenarios discussed in this book, you will learn how to use this valuable resource.

Further Reading

Please visit https://appsource.microsoft.com/ to access the full range of AppSource business applications and extensions for Power Platform and Dynamics 365.

Azure

Microsoft Azure provides a wide range of cloud-based components that are used to extend the Power Platform beyond its functional boundaries. Solution architects analyze organizational requirements and map the implementation to Azure components when the Power Platform feature set does not fulfill the project goals. The key Azure components used in typical Power Platform implementations are listed here:

• Logic Apps
• Functions
• Azure SQL
• Web Apps
• Data Factory
• Application Proxy
• Data gateways

In the upcoming chapters, you will learn how to run a fit-gap analysis for business requirements, decide when to leverage Azure components, and define a secure architectural blueprint that combines Power Platform with Azure capabilities to build a successful Microsoft-based solution.

Further Reading

Please visithttps://docs.microsoft.com/en-us/azure/?product=compute for detailed documentation on Azure components referenced in this book.

By providing best practice guidance and laying the foundations for the implementation, solution architects lead by example. They complement and enhance the technical capabilities of the delivery team, resulting in team output that is greater than the sum of the individual members. The following diagram illustrates the support, documentation, and tools a solution architect may provide to the various project teams and individuals:

Figure 1.22 – Illustration of a Power Platform solution architect’s hands-on role and responsibilities

Solution architects interact with a wide variety of teams during a Power Platform implementation, and will typically provide hands-on support to the following individuals:

• Supporting technical consultants and developers

Technical consultants and developers working on a Power Platform implementation benefit from access to high-level technical blueprints and detailed designs. The blueprints provide a clear direction for the technical implementation. Standardized toolsets, source control strategies, development templates, and a continuous integration and deployment (CI/CD) framework will help guide the implementation using a common and consistent approach.

• Supporting functional consultants

Functional consultants benefit from design documentation in the same way as technical consultants. When provided with functional implementation templates (for example, Power Automate design patterns and Dataverse table best practices), consultants benefit from a consistent approach to Power Platform configuration and implementation, resulting in a maintainable and more closely aligned solution with published best practices.

• Supporting business analysts

Solution architects work hand-in-hand with business analysts to understand the product capabilities and licensing constraints, shaping the requirements and success criteria for the project. Solution architects provide a guide to Power Platform’s best practices to steer the requirements towards solutions that are supportable and suited to the platform’s capabilities.

• Supporting project managers

Solution architects facilitate the smooth running of a project by providing estimates and progress updates to project managers. Risks to the project are presented to project managers alongside solutions and options to mitigate those risks.

Using a hands-on approach, solution architects provide project team members and stakeholders with the toolsets and information required for a successful Power Platform implementation.

This chapter introduced the nine pillars for great solution architecture, described the architect’s role, and provided an overview of the capabilities and features available within Power Platform and the wider Microsoft cloud-based ecosystem. Understanding the capabilities and features available within the Power Platform framework and associated Microsoft services will help find the most optimal solution during the design process. The pillars for great architecture will, in turn, guide the decisions and actions taken throughout the project, resulting in a secure, cost-effective, supportable solution that solves the organization’s problem.

The next chapter introduces our sample case study used throughout this book’s Power Platform implementation case study.

OneDrive for Business is a data storage service and is not one of the channels that may interact with a Power Virtual Agent as standard.

For further information on the components discussed in this chapter, please visit the following documentation pages:

• Dataverse: https://docs.microsoft.com/en-us/powerapps/maker/data-platform/
• Overview of creating applications in Power Apps: https://docs.microsoft.com/en-us/powerapps/maker/
• Power Apps model-driven apps documentation: https://docs.microsoft.com/en-gb/powerapps/maker/model-driven-apps/
• What are Power Apps portals?: https://docs.microsoft.com/en-gb/powerapps/maker/portals/overview
• Powe Pages: https://powerpages.microsoft.com/
• Power Apps canvas apps documentation: https://docs.microsoft.com/en-gb/powerapps/maker/canvas-apps/
• Power Platform connector reference overview: https://docs.microsoft.com/en-us/connectors/connector-reference
• Power BI: https://docs.microsoft.com/en-us/power-bi/
• Power Virtual Agents: https://docs.microsoft.com/en-us/power-virtual-agents/