Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Microsoft Power Platform Enterprise Architecture

You're reading from   Microsoft Power Platform Enterprise Architecture A guide for architects and decision makers to craft complex solutions tailored to meet business needs

Arrow left icon
Product type Paperback
Published in Sep 2020
Publisher Packt
ISBN-13 9781800204577
Length 452 pages
Edition 1st Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Robert Rybaric Robert Rybaric
Author Profile Icon Robert Rybaric
Robert Rybaric
Arrow right icon
View More author details
Toc

Table of Contents (15) Chapters Close

Preface 1. Section 1: The Basics
2. Chapter 1: Microsoft Power Platform and Microsoft Dynamics 365 Overview FREE CHAPTER 3. Chapter 2: Microsoft 365 and Microsoft Azure Overview 4. Section 2: The Architecture
5. Chapter 3: Understanding Microsoft's Power Platform Architecture 6. Chapter 4: Tools and Techniques 7. Chapter 5: Application Lifecycle Management 8. Section 3: Implementation
9. Chapter 6: Implementation Approach and Methodologies 10. Chapter 7: Microsoft Power Platform Security 11. Chapter 8: Microsoft Power Platform Extensibility 12. Chapter 9: Microsoft Power Platform Integration 13. Chapter 10: Microsoft Power Platform Data Migration 14. Other Books You May Enjoy

Introducing Microsoft Power Platform

In this section, you will learn the structure of the Microsoft Power Platform to understand the background technology on which Power Apps as well as all Microsoft Dynamics 365 applications run.

Microsoft made a big mind shift when it introduced the Power Platform. For seasoned Microsoft Dynamics CRM and, later, Dynamics 365 CE experts, the Dynamics product is no longer the centerpiece of this product line but rather a first-party app running on the Power Platform. The change can be illustrated in the following diagrams. The first diagram shows the Microsoft Dynamics 365 high-level architecture before the Power Platform was introduced (not all applications are included for brevity):

Figure 1.1 - Microsoft Dynamics 365 before the Power Platform

Figure 1.1 - Microsoft Dynamics 365 before the Power Platform

The second diagram presents the dramatic increase in complexity and the number of various new products and technologies that are part of the Power Platform today, as documented in this diagram (not all applications are included for brevity):

Figure 1.2 - Microsoft Power Platform

Figure 1.2 - Microsoft Power Platform

Microsoft Power Platform consists of the following components:

  • Common Data Service
  • Model-driven apps
  • Canvas apps
  • Power Automate
  • Power Virtual Agents
  • Power BI
  • On-Premises Data Gateway
  • AI Builder
  • Power Apps portals
  • Dynamics 365 Customer Voice

This new Microsoft Power Platform philosophy suggests that a potential user of a Microsoft-based business solution will need more evaluations and decision making to find the best solution for their business requirements. Some of the examples are as follows:

  • Will my workload be better covered by some of the Microsoft Dynamics 365 applications, or should I develop my own Power Apps application?
  • Do I need mobile applications at all and if so, can I use the standard Microsoft Dynamics 365 app for mobile, or do I need to develop my own apps using the canvas apps technology?
  • Do I need to integrate my business application using any costly legacy integration platform or another Microsoft/third-party integration solution or can I use Microsoft Power Automate?
  • Can I use some of the more than 350 public connectors for canvas apps and Power Automate or do I need to develop my own custom connector?
  • What are the most effective licensing options to cover my business requirements?

In the following sections and chapters, you will learn what Common Data Service is and what the new role of Microsoft Dynamics 365 apps is in the Power Platform. We will also explore how you can build mobile apps for an internal audience easily and with no code as well as looking at cross-platform automations and what the licensing options are for the various Power Platform components.

Introducing the Common Data Model and Common Data Service

Power Platform introduced the Common Data Model (CDM) and Common Data Service (CDS) and it is important to understand what these two concepts are and what the difference between them is.

Introducing Common Data Model

The CDM is a standardized data model consisting of a metadata system and data schemas. The CDM was developed with the goal of providing a common platform facilitating data integration and application development. It was also presented by Microsoft together with Adobe and SAP as part of the Open Data Initiative (ODI). The expectation is that the ODI will welcome more partners and that all contributing parties will work on extending and further standardizing the CDM.

The CDM consists of a relatively small set of core entities (equivalent to tables in relational databases), which are not directly related to any particular workload, together with a lot of additional entities grouped into typical workloads such as sales, service, and healthcare. An additional CDM extensibility option is the growing set of Microsoft industry accelerators. Currently, there are accelerators for banking, healthcare, education, non-profit, automotive, and media.

Introducing Common Data Service

The CDS can be understood as an implementation of the CDM for the purpose of hosting data for Power Platform applications. But the CDS is much more than just a database. It consists of the following main components:

  • Entities with the underlying structure of fields
  • Relationships between entities
  • User interface elements used in model-driven apps (views, forms, charts,and dashboards)
  • Global (entity-independent) option sets, which can be repeatedly used in several entities
  • Automations (business rules, business process flows, and workflows)
  • Security concept elements (for example, business units, security roles, and field security profiles)
  • Custom development capabilities (API, server-side, and client-side extensibility models)

The CDS is the foundation for building model-driven apps. The approach is to first configure the whole CDS data model, create all elements, and then configure a model-driven app using the necessary subset of the CDS elements. Depending on the purchased licenses, the CDS is either extended by a Microsoft first-party application from the Microsoft Dynamics 365 family of products, any third-party partner applications,or within a user's own configuration capacity.

Introducing model-driven apps

Model-driven apps are one of the two interactive end user application types that can be developed in the Power Platform. Historically, model-driven apps were the Microsoft Dynamics 365 applications themselves. The philosophy of model-driven apps has, however, changed compared to Microsoft Dynamics 365 and is based on the following capabilities:

  • A model-driven app can be either a first-party application (any of the Microsoft Dynamics 365 apps), a third-party ISV application purchased from a partner or on AppSource, or a self-developed application.
  • A model-driven app is based on the CDS.
  • There can be only one CDS database in a single environment but multiple model-driven apps of any of the mentioned types.
  • All model-driven apps share the same data or subsets of data in the CDS.
  • Model-driven apps run primarily on a PC in a browser but can also be used on mobile devices within platform-specific mobile apps.

    Important note

    You will learn details of the Power Platform environment in Chapter 3, Understanding Microsoft Power Platform Architecture.

A model-driven app is technically a very simple unit, consisting of only two components:

  • A model-driven app, specified with a few parameters, for example, name and URL
  • Model-driven app navigation called the Site Map

All other components in a model-driven app are stored within the CDS environment and should exist prior to creating a model-driven app. The end-to-end process of creating a model-driven app can be divided into the following steps:

  1. Provision a Power Apps environment with the CDS.
  2. Create the data model (entities with fields and relationships).
  3. Create the user interface (views, forms, charts, and dashboards).
  4. Create the automations (business rules, business process flows, and workflows).
  5. Create a new model-driven app.
  6. Create a site map.
  7. Select components for the model-driven app.
  8. Save, validate, publish, and play.

Introducing canvas apps

Canvas apps are a younger member of the Power Platform family and are primarily intended to be used on mobile devices rather than on PCs. Historically, canvas apps evolved from the Microsoft Siena project of 2014. The philosophy and capabilities of canvas apps are very different from model-driven apps:

  • Canvas apps do not need the CDS; they can be created in a Power Apps environment without the CDS.
  • Canvas apps are designed very much like apps for mobile devices with the user interface in focus.
  • The business logic in canvas apps is implemented using Excel-like expressions.
  • Canvas apps can be connected to various data sources using the concept of connectors. Right now, there are more than 350 publicly available connectors and there is a possibility to easily develop your own custom connector if no public connector is suitable for the required technology.
  • Canvas apps can run on a mobile device within a specific canvas apps player. They can run on a PC in a browser or can be embedded in websites, SharePoint sites, Power BI, Teams, or model-driven apps.

For the accelerated adoption of canvas apps, Microsoft offers a wide variety of canvas app templates within the canvas apps designer tool.

The end-to-end process of creating a canvas app can be divided into the following steps:

  1. Provision a Power Apps environment with or without the CDS.
  2. Create a canvas app.
  3. Optionally connect to data sources using connectors.
  4. Create the user interface (for example, screens, galleries, forms, and controls).
  5. Create the business logic using expressions.
  6. Save, validate, play, and share.

Introducing Power Automate

Power Automate (previously Flow) is the automation engine within Microsoft Power Platform. The purpose of Power Automate is to build automation flows across a wide variety of systems and technologies in a low-code style using a very intuitive graphical user interface. The underlying technology of Power Automate is Microsoft Azure Logic Apps and the use of connectors, as well as the graphical design of flows, are very similar. A Power Automate flow generally consists of a trigger and business logic, which in turn consists of flow control elements (conditions, switches, and loops) and actions, implemented using connectors, most likely as in canvas apps. The following types of flows are available:

  • Automated flows: These are triggered in the background by an event trigger usually coming from a connector.
  • Button flows: These are triggered manually by a button and can take manual data input. These flows can run on PCs and on mobile devices within a specific Power Automate player app.
  • Scheduled flows: These are triggered in the background by a timer or scheduler trigger.
  • UI flows: These are used for recording and automating manual steps on various legacy software.

For the accelerated adoption of Power Automate, Microsoft offers a wide variety of Power Automate templates within the flow designer tool.

The end-to-end process of creating a Power Automate flow can be divided into the following steps:

  1. Provision a Power Apps environment with or without the CDS.
  2. Create a Power Automate flow.
  3. Define the trigger type and trigger parameters.
  4. Create the business logic using the graphical designer, and configure the actions appropriately.
  5. Save, validate, test, and share.

Introducing Power Virtual Agents

Power Virtual Agents is the latest member of the Microsoft Power Platform product family. The purpose of the Power Virtual Agents technology is to enable the creation of bots using a graphical interface and a no-code approach and so open the world of bots to everyday business users without specific programming skills. The following are the capabilities of Power Virtual Agents:

  • Bots are developed in a graphical designer with no code requirements.
  • The designer defines conversational topics, business logic, and actions for the conversation. The actions can be implemented using Power Automate.
  • The bot can be integrated with a variety of environments, including websites, mobile apps, Teams, Skype, and Cortana, as well as various non-Microsoft systems such as Facebook, Slack, Telegram, and Twilio.

The end-to-end process of creating a Power Virtual Agents bot can be divided into the following steps:

  1. Create a Power Virtual Agents bot.
  2. Create topics.
  3. Create the business logic using questions, messages, and actions.
  4. Specify the end of the conversation with either a survey or transfer to an agent.
  5. Save, validate, and test.
  6. Publish the bot on a required channel.

Introducing Power BI

Power BI is a collection of a data platform, cloud services, applications for PC and for mobile devices, and connectors to work together to provide an analytical and reporting solution. From a consumer point of view, Power BI provides Power BI apps, which consist of reports and dashboards . This content can be consumed in a browser on PCs as well as on Power BI mobile apps.

For designers and developers, Power BI offers the following capabilities:

  • Power BI cloud service, where the published content runs
  • Designer and developer tools to prepare the content, such as Power BI Desktop and Power BI Report Builder
  • Tools for advanced topics such as creating custom visuals or using the Power BI API

Key concepts of Power BI for Microsoft Power Platform solutions are as follows:

  • Power BI reports and dashboards can use data from the CDS alone as well as combined with data from various other sources.
  • Power BI reports and dashboards can be embedded in model-driven apps as well as canvas apps and Power Apps portals.
  • Canvas apps can be embedded in Power BI reports and dashboards.

Introducing On-Premises Data Gateway

On-Premises Data Gateway is a specific software solution, enabling the use of your own on-premise data sources within various cloud services such as Power Apps, Power Automate, and Power BI but also for some Microsoft Azure services. On-Premises Data Gateway needs to be installed on a local infrastructure and configured to expose the required on-premise data sources to the cloud. The benefit of this solution is that there is no inbound connection from the cloud to the user's own data center; the connection is always established outbound.

Introducing AI Builder

AI Builder is one of the latest members of the Microsoft Power Platform product family. The purpose of AI Builder's technology is to enable the creation of AI components using a graphical interface and a no-code approach and so to open the world of AI to everyday business users without specific scientific and programming skills.

Here are the characteristics of AI Builder:

  • AI solutions are developed in a graphical designer with no code requirements.
  • The user selects one of the ready-made AI models the platform offers, provides data for training the model, trains, and publishes the solution.
  • The AI solution can be used from Power Automate flows as well as from canvas apps to infuse AI-processed content into an automation or mobile application.

Introducing Power Apps portals

Power Apps portals historically evolved from Microsoft Dynamics 365 portals. The purpose of Power Apps portals is to provide external-facing websites connected with the CDS data for users outside of their own organization. Power Apps portals are the only Microsoft Power Platform technology that is really open to public and even anonymous access. Power Apps portals have the following capabilities:

  • The portals run on Microsoft Azure services, but the content of the portals is completely configured within model-driven apps.
  • Power Apps portals expose selected data from the CDS to anonymous or registered and authenticated users.
  • Power Apps portals offer a wide variety of authentication possibilities for external visitors.

Introducing Dynamics 365 Customer Voice

Dynamics 365 Customer Voice is a solution for creating and running surveys and is based on the Microsoft Office 365 Forms technology for the UI part and the CDS for the content and data part. Dynamics 365 Customer Voice has the following capabilities:

  • Design surveys in a graphical designer using different question types and branching logic.
  • Distribute surveys to participants in a variety of ways including email, Power Automate, by embedding in a web page, providing a survey link, or with a QR code.
  • Combine responses with CDS business data and analyze them using included Power BI analytics.
You have been reading a chapter from
Microsoft Power Platform Enterprise Architecture
Published in: Sep 2020
Publisher: Packt
ISBN-13: 9781800204577
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €18.99/month. Cancel anytime