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.
Laying the foundations for great solution architecture
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:
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.
- 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.
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.
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.
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.
Understanding the solution architect’s role
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:
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.
Power Platform architecture overview
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:
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.
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:
- 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):
- 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:
The diagram that follows presents a high-level architectural view of the component:
- 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:
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:
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
- 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:
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:
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 diagram that follows presents a high-level architectural view of the component:
- 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:
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:
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:
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.
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:
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:
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.
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
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
- 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:
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.
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.
- Azure AD
The cloud-based Active Directory solution. Users are configured for access to specific resources, assigned security groups, and authentication policies.
Assignment of licenses to Azure AD users grants them access to specific Power Platform applications, providing an additional access security layer.
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.
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.
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
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.
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)
Please visit https://docs.microsoft.com/en-us/dynamics365/ for full product documentation on all Dynamics 365 applications.
The key Microsoft 365 applications discussed in this book are as follows:
- Office applications (Word, Excel, Outlook, OneNote, Teams, OneDrive, and Microsoft Forms)
Please visit https://docs.microsoft.com/en-us/microsoft-365 to review the documentation on the Microsoft 365 suite of applications and services.
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.
Please visit https://appsource.microsoft.com/ to access the full range of AppSource business applications and extensions for Power Platform and Dynamics 365.
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
- 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.
Please visithttps://docs.microsoft.com/en-us/azure/?product=compute for detailed documentation on Azure components referenced in this book.
A hands-on approach to Power Platform solution architecture
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:
- 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.
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/