We are experiencing a seismic, generational transition in the way that organizations buy, use, and enable their own success via technology. This transition is on par with its historical antecedents: the mass market availability of personnel computers in the workplace, the ubiquity of the internet, and the migration from “on-premise” to cloud.

A history lesson

But let’s first share a history lesson of a different sort.

The Commissioners’ Plan of 1811

Map of New York City — Note the winding streets on the southern end of Manhattan and the orderly, straight streets further north.

Dutch settlers began to settle the land at the mouth of the Hudson River around the year 1624. The settlement—New Amsterdam—became the capital of the New Netherland colony in 1625 and grew steadily under the Dutch until 1664 when the English seized the town and renamed it New York. From its founding, the southern end of Manhattan Island grew haphazardly with buildings erected and private streets aimed in every which direction, bending and doubling back on themselves, into buildings and across fields, a legacy which can today be seen in the labyrinth of roads winding through New York’s financial district. Later, the city’s population grew over 50% to nearly 120,000 people in the decade to 1810. The following year saw the introduction of the Commissioners’ Plan of 1811, which introduced the grid pattern of north-south avenues and east-west streets north of Houston Street and south of 155th Street that we know today. Thus it was that by the early 1800s there would have been a planned intersection of 34th Street and 5th Avenue—and thousands more intersections dotting the city’s grid—though it would be more than a century later before anyone knew that spot was to be the eventual site of the Empire State Building. The Commissioners’ Plan laid the foundations for one of the world’s preeminent global cities, a city that had grown to 120,000 people in the two centuries preceding the the plan yet followed by growth to 9 million people in the two centuries following, and a metropolitan area that would be the world’s eighth largest economy were it a sovereign state. Other innovations would follow, and though New York City’s design has evolved and expanded to meet new needs in the years since, its core platform—the Commissioners’ Plan—has endured.

So it has gone in the cloud…

You see, organizations have in the past implemented point solutions to solve for specific needs. Now these organizations are taking platform-first approaches upon which they deploy solutions to emerging challenges in less time at lower cost—better integrated with other business processes and data—than what was previously possible. They knit together services across the cloud that would have been the stuff of dreams just a couple of years ago.

Think of it like this…

In previous times that we’ll refer to as the Point Solution Era, organizations focused on specific solutions to meet specific requirements just as in New York’s early days when buildings were put up haphazardly and roads doubled back to connect them. In other words, when ABC Capital needed an accounting system, ABC Capital surveyed the market, acquired, and implemented an accounting system. They budgeted its implementation and its operations and maintenance (O&M) costs as a discreet line item. They deployed. They moved on. This approach was the best we had for a long time, but it was problematic because each new requirement incurred new costs, and because successive acquisitions of different point solutions often played poorly with what was already in place and what was to come in the future through acquisitions of yet more point solutions. This approach was slow. It was costly. And it continued to dominate conventional wisdom in IT deep into the cloud era.

The new world is platform-first, wherein ABC Capital invests in a platform that it believes will meet most of its needs now and into the future. Like the Commissioners’ Plan, it seeks not to predict the future but rather to lay the best foundations so that future requirements that are today unknown—a place for the Empire State Building—can be absorbed into the grid later on. Platform-first provides the capacity, connectivity, and services to enable growth. It transforms our pile of tech into an ecosystem. In the platform-first era, ABC Capital budgets for a combination of consumption and fixed cost per user. They establish the platform, manage and govern it, and empower their developers to make use of it to absorb as many current and future requirements as possible.

We can do this because we’re now living in the Cloud Application Platform Era. This approach will supersede the Point Solution Era because it allows organizations to plan more strategically, make technical choices today that reduce the risk of being painted into a corner tomorrow, absorb new requirements rapidly, better fix costs across their ecosystem, and buy down the risk of unknown future needs. That’s what the Cloud Application Platform is all about.

But we’ll get to that in a bit.

Generational Transition

Earlier I characterized the platform-first transition as generational, an assertion I don’t take lightly, though it is fashionable to describe any sort of innovation—however extraordinary—as a new “generation” of technology. But, to me, a generational transition requires fundamental shift in four areas:

Outcomes, use cases, and challenges that technology solves. As we’ll see in the notional examples I’ll share later, organizations are using Cloud Application Platform technology to tackle workloads (business challenges) in ways just a few short years ago would have been technically impractical or cost prohibitive.
Economics around how technology is acquired and maintained. Cloud Application Platform economics rely on a combination of consumption and fixed or declining-cost user licensing where the first workload is quite expensive, the next several workloads cost significantly less, and future ∞ workloads cost nearly nothing. The practical result is cost predictability and an incentive to migrate more and more to the organization’s Cloud Application Platform of choice. I wrote extensively on this “One Thousand Workloads” concept here.
Operation of that technology from an IT perspective (e.g. management and governance). The Cloud Application Platform is most effective when architected and governed holistically across the organization, rather than stashed in one-off instances strewn about the organization’s IT ecosystem. You can read more on that here.
Technology itself. Cloud Application Platform allows us to build applications rapidly, integrate them seamlessly with other workloads living on the platform, and utilize a web of interconnected cloud services for app development, data sources, ingestion, storage, analysis, and visualization that can be spun up and torn down as needs arise and costs allow.

Cloud Application Platform

So what is the Cloud Application Platform?

I speak from a Microsoft perspective because it is my expertise and—more importantly—Microsoft has, by far, the most complete story in the market. Nobody else even comes close. Regardless, we are at this point far enough into the cloud era that most large organizations have acquired an assortment of cloud technologies. These technologies are great, well intentioned, even useful. But in most organizations they are a pile, a tangled mass of great tech in search of harmony and alignment to actual business challenges. We begin to untangle this be maturing that cloud technology into an ecosystem whose organizing principles are cloud transformation and application modernization. That ecosystem is the opposite of the pile that preceded it, and it is the foundation upon which Cloud Application Platform rests.

But why?

A while back, Lee Baker and I outlined an approach to Power Platform in a Modern Data Platform Architecture wherein Microsoft Power Platform is one of the three principal components of the one Microsoft Cloud, alongside Azure and Microsoft 365 all living inside of an organization’s often quite complex data ecosystem. Put another way, it’s rare for us to encounter a large enterprise organization that isn’t to some degree constrained by previous technical decisions, siloed data, and third-party applications. In most cases we face a blending of the old and the new, a need for transformation that respects what’s already there, at least for a time. In other words, a fusion of lower Manhattan with New York City as it was later constructed north of Houston Street, enabled by transformative technology—like the New York City Subway—to connect the two.

The diagram above builds the next generation Cloud Application Platform atop the modern data platform architecture I discussed previously. Many organizations have built a pile of tech, a tangled mass of great capability in search of harmony and alignment to actual business challenges. We begin to untangle this be maturing that cloud technology into an ecosystem whose organizing principles are cloud transformation and application modernization. That ecosystem is the opposite of the pile that preceded it, and it is the foundation upon which Cloud Application Platform rests.

So let’s take the Cloud Application Platform—as envisioned here—one piece at a time…

The aforementioned modern data platform architecture sits at the foundation. Read more about that here.

Core Business Applications (Dynamics 365)

The Cloud Application Platform diagram above really expands the idea of “Data Collection” discussed in the data platform piece. Microsoft’s Dynamics 365 applications sit atop of and / or are extended by those Power Platform services. There is some architectural nuance there that I want to acknowledge but not dive into here, but the key takeaway here is that Microsoft has used its own Power Platform technology to build a collection of core business applications that it calls “Dynamics 365”. Some—like Sales (CRM) or Customer Service—are quite literally Power Apps. Others—like Finance or Supply Chain—are architecturally different but very much extended by Power Platform services. Together they represent Microsoft’s highly-configurable answer to common and critical business workloads across the spectrum of CRM and ERP requirements.

Custom Enterprise App Portfolio

Here we also have what I’ll call the Custom Enterprise App Portfolio, which accounts for the very vast number of custom applications that any large organization builds over time to meet its own needs. Just as Microsoft used its own platform services to build the suite of Dynamics 365 solutions, so too can we use those same services to build whatever custom applications the organization needs. Lower-end complexity “personal productivity” apps can be built by skilled power users we call citizen developers. Higher-end complexity “business important” and “business critical” solutions are built by skilled professional software developers; I’ve personally worked on teams that have built Power Platform solutions through which billions of dollars, pounds, and euros are driven each year. This portfolio is circled in red on our diagram because they are a central proposition—the middle word in fact—of our Cloud Application Platform. They are, in other words, the Empire State Building built atop our platform.

Azure and Microsoft 365

Icons representing a selection of Microsoft Azure services

They are also inextricably woven together by cloud services across Azure and Microsoft 365. I’ve shared a few of my favorites here for illustrative purposes (so don’t be a wise guy and leave comments about how I’ve missed one of your favorites 😉). Let’s think through some examples, and then expand on them in our “Cloud Application Platform in Practice” section a bit further down…

Azure Active Directory drives user authentication and security across the Microsoft Cloud. Authentication of the organization’s internal users to the various custom and core business applications happens via the same engine that does likewise for Microsoft 365 services such as Teams and SharePoint. Services such as AAD security groups and access packages streamline provisioning of resources and security roles across the platform, whilst AAD B2B and B2C facilitate access to externally facing applications built in—say—Power Portals.
Microsoft Teams serves as both a common user interface through which custom applications are served up to users, an orchestrator through which approvals of various business process transactions are routed for approval by individual users, and a means of delivering content such as files stored in SharePoint or intelligent bots served up by Power Virtual Agents.
Azure SQL provides a source of structured data atop which apps can be built either in conjunction with or without any migration to Dataverse. I could write pages more on this topic alone, but suffice it to say that a great strategy in your legacy app migration to the Cloud Application Platform is to rapidly build modern Power Apps atop data you already have (or plan to re-host) in Azure SQL, and then either leave the data there long-term or later migrate it to a different service such as Dataverse (both are perfectly acceptable depending on your particular circumstances). This approach allows for rapid app modernization with data left in place, without having to contend (at least immediately) with costly data migrations that a senior IT executive once described to me as the “long pole in the tent” of any app modernization effort.

…I could go on, and on, and on. But I’ll stop here.

Other Apps and Services ∞

Icons representing a selection of other non-Microsoft apps and services

Finally, we have our “Other Apps and Services” (“∞” represents the infinite number of these that you might choose to integrate), of which I’ve depicted three popular examples in SAP for ERP workloads, SalesForce for CRM workloads, and Workday for HR workloads. Notice that none are Microsoft, and that’s exactly the point. Earlier I said that “…it’s rare for us to encounter a large enterprise organization that isn’t at least somewhat constrained by previous technical decisions, siloed data, and third-party applications. In most cases we face a blending of the old and the new, a need for transformation that respects what’s already there.” We’ve built our metaphorical city atop a standards-based, well-governed platform capable of ingesting many data sources. Hence my placement of these third party services so close to the “data sources” and “ingestion” points on our data wheel.

Cloud Application Platform in Practice

I want to conclude this tome with some practical architectural examples of how this vision for the Cloud Application Platform can be used in practice. I’ve debated whether to include them here, where on the one hand I don’t want to get so far down in the weeds that I take us far afield of our big ideas, but on the other hand I want to make those ideas real. I’ve decided, though, that this is important so that we can make practical out of the theoretical, so we’ll use some workloads that I’ve actually built in industries I know pretty well (but use your imagination, because there’s room for many thousands more!).

Product Management in Regulated Industries (like Financial Services)

Our scenario here involves regulatory management; specifically, at least in this example, around product management in financial services institutions (FSI). Think insurance, banking, and capital markets, though it doesn’t take much imagination to extend the notion across a wide swathe of regulated industries. You see, these organizations have a huge regulatory burden when it comes to the the products they offer in the market. For example, a banking or insurance product offered in Minnesota is subject to a different set of regulatory processes than a similar product offered in Scotland. Financial services organizations expend huge amounts of effort and resource to manage this process of introducing new and updated products (e.g. rate revisions) into the jurisdictions they serve. Though the specifics of the process would differ, I could have easily built this example around other regulated industries, say healthcare: Payor (health insurance) would not have been a big stretch at all, and we could apply similar concepts in pharmaceutical and medical manufacturing as they shepherd products through their own regulatory burdens into the market.

Alright, so let’s go…

A practical example of Cloud Application Platform technologies and principles applied to a financial services workload. — The diagram above shows a Cloud Application Platform native solution through which **a highly regulated organization such as a financial services institution** navigate their regulatory burden around product management whilst then using that data as an asset in downstream analytical workloads.

This scenario begins (and ends) with our business analysts who are collectively responsible for identifying, modeling, productizing, and navigating the regulatory burden around financial products. The legacy approach to this across many FSIs has been a combination of spreadsheets, slides, email, InfoPath (which is in the final stages of its long sunset) for process enablement, and various other end-user computing (EUC) concoctions (EUCCs? 😉). The modernized scenario shown in the diagram has migrated most of this hodgepodge to a combination of Power Apps, Power Automate, and Power BI services with data stored in—you guessed it—Dataverse as our single source of truth.

Line of business (LOB) owners are responsible for the product portfolios across the FSI’s business, e.g. consumer banking or commercial insurance. These folks are consuming the output of our analysis via Power BI, managing the process via Power Apps, and taking audited decisions at various steps in the process using approval workflows orchestrated by Microsoft Teams to form a feedback loop that might repeat itself many times. Azure Blob Storage then stores the audit trail and artifacts (e.g. files and diagrams) generated by this process much more efficiently than were we to store this in the database itself, though its important to note that the platform itself makes the call on the most efficient way to store data rather than relying on it to be configured in the app itself.

Government regulators in different jurisdictions impose different filing requirements. Multiply this across countries, states, provinces, territories, counties, autonomies, you name the places you’re doing business and the burden grows rapidly. So We’ll automate as much of this as possible via Microsoft 365 to spit out the required artifacts in appropriate form, and then archive via SharePoint. I love this scenario because we’ve now used services spanning Power Platform, Azure, and Microsoft 365 in pretty short order.

A point solution might have stopped here, though we’ll press on because—as my colleague Doug McConchie would say—”data is an asset”. We want to make the most the product and analytical data we’ve generated upstream (above), so we’ll push it from from Dataverse (where we’ve performed all or most of our application transactions thus far) into a Data Lake where we’ll co-mingle it with other potentially enormous gold mines of information including industry data (which I am construing here to be third-party) and customer data including who is buying, who is leaving, what they’re buying, how they used the products we offered them, and… well the list goes on. Importantly, I’ve represented this node with Dynamics 365 for Sales (CRM) as the best option because it’s native to Microsoft’s Cloud Application Platform. As such, it is itself storing all of its data in Dataverse, though I’ve resisted the urge to make the direct link on the diagram here because it is entirely possible that the organization has opted to store its CRM data in a Dataverse environment separate from that used in our primary workload here. The Power Platform Adoption Framework recommends an entire best-practice approach to this environmental architecture, and I thought I’d use this as the moment to call that out.

In a callback to the modern data platform architecture:

Data Lake is unlimited cloud-based storage for data ingested from amongst all of our many data sources. This is important because it provides a storage platform from which our analyses may occur. It may not seem significant at a small scale where we are storing application data transacted by a narrow number of use cases, but we’re thinking really big here where storage and analysis of data living inside of Dataverse (or any other of our potential thousands of sources) is both inefficient and expensive. The commonality of this scenario is reflected in our ability to export from Dataverse directly a Data Lake from within Power Apps, though Data Lake is a storage destination for an essentially unlimited number of sources.

Further…

The entire goal of the modern data platform is to access the insights and decision making made possible through “Analysis”. So it is in this stage where we really achieve value through the application of cognition around what is seen, spoken, and read in our data, machine learning, and through analysis of stream and customer data. It is also in this stage that we really begin to close the loop around Power Platform in our data ecosystem as we feed data directly to Dynamics Customer Insights which sits within the native Microsoft business applications / Power Platform sphere as part of the Dynamics 365 family of applications.

In our scenario here, we’re running our trove of product, regulatory, industry, and customer data through Azure Synapse to generate insights to drive future product and product revisions, really closing the loop creating an ever-repeating loop where the efficiency gains we’ve realized around product product management and regulatory compliance are brought together with previously unrelated processes elsewhere in the business to create real value across the Cloud Application Platform.

Human Resources (in the Public Sector and beyond!)

Let’s take on an example to which nearly everyone in the working world can relate, though in order to make it a bit more specific we’ll look through the lens of a public sector organization. Think a large civilian agency, military command, law enforcement agency, and both public sector and private organizations with big field workforces such as public works or transport operators.

The diagram above shows a Cloud Application Platform native solution through which a **large public sector agency**, ministry, or military command might tie together previously disparate workloads around recruiting, HR management, operational planning, field activities, call center, payroll, and inter-agency integration.

We’ll begin with applicants, people who are seeking a role within the organization. They could be external to the organization seeking to join for the first time, or internal to some other part of the organization looking to make a move (sometimes referred to as “in-service recruiting”). In our scenario, these jobs are published via an “Applicant Portal” built using Power Portals with secure access facilitated via Azure Active Directory B2C. Applicants use the portal to prepare a profile of their past experience, education, credentials, and any other data points the organization requires. They then browse available jobs and submit their information against those jobs. The process can be rather straightforward—the well worn job application trope—but the highly customizable Cloud Application Platform approach works particularly well here for organizations with unique needs such as those whose application processes involve atypical requirements such as medical and psychological screening, security constraints, financial history, or conflict-of-interest concerns.

Applicant data is then spliced together with job posting and other HR data to be used by recruiters (and other HR personnel) responsible for sourcing, evaluating, hiring, and on-boarding applicants into the organization. In our diagram I’ve depicted two apps the recruiters might use, let’s say a tablet app when out and about at external events such as job fairs, as well as a browser-based application to be used back at their desk. These apps are responsive, so we can build for any form factor. The process should also be automated wherever possible, for example, a customized source-to-hire business process, or automation that eliminates the need for double entry by pushing applicants into the master HR database when hired (yes, even across security boundaries).

Operational planners are plugged into the mix when the time comes to assign, equip, and deploy our people. Some of my favorite scenarios here include:

Personnel status, also known as “burnout management”: Compiling and reconciling data about work assignments, leave, medical, family concerns, time spent away from home, etc. in order to produce a picture of how stretched our workforce is, and in particular who amongst us needs a break. This data is normally siloed into separate systems, but by weaving together our HR and and operational data we can quickly make data-driven decisions about the condition of our workforce and our individual colleagues that would have never before been possible.
Needle in a haystack: Using competency data (e.g. skills, certifications, qualifications, languages, etc.) submitted during the applicant process and then added to throughout the employee’s life in the organization to find just the person we’re looking for in just the situation we’re facing. Finding, for example, the qualified boat driver with emergency medical experience who just so happens to possess native proficiency in the language spoken in the place we’re sending her. Or a climate scientist under the age of 40 who is psychologically fit to endure months of darkness (my team once deployed Microsoft Dynamics at the South Pole, so this scenario is one of my favorites).
Exercise and deployment planning: In really what is a combination of the scenarios above, we can combine our personnel status and our talent data to identify the right people for the right assignment in large-scale planning scenarios. I’m no longer surprised when I encounter high operational tempo organizations that are still doing this in spreadsheets where a single move requires 60+ clicks of the mouse, because in reality almost everyone is still doing it that way for want of a better option.

Most of these high operational tempo organizations have big work forces of what I’ll refer to as field personnel. They’re the cops, medics, bus drivers, pilots, crew, mechanics, soldiers, marines, sailers, airmen, coast guardsmen, etc. who get the job done. My dear friend and colleague Keith Whatling—who himself has spent a lot of time getting London bus service to the cloud—talks about “an app for Terry” (a friend of his from the busses), in other words, apps placed in the hands of “operators” that enable them to do their jobs. Our diagram depicts multiples of these to illustrate the near boundless possibilities from access to your own competency data and assignments to field safety checkins to maintenance checklists.

Decision Makers are our final user persona. In our example here they are consuming real-time reporting via Power BI. To some extent this means consumption of the same data used by our operational planners above, though I’ve seen organizations reach a point of maturity where they star to throw away their slides. In a callback to our original premise, we grew accustomed during the Point Solution Era to executive briefings that took days to prepare for because data from disparate point solutions had to be manually reconciled into briefings that were instantly stale on delivery, whereas the Cloud Application Platform Era allows us to report on real-time data and answer many questions instantly. Fewer data calls. Less “I don’t know, but I’ll find out”. Better decisions made.

The bottom third of our diagram integrates our hybrid HR and operational scenario with a variety of other workloads sitting atop and adjacent to the organization’s Cloud Application Platform.

Organizations operating call centers might do so via Dynamics 365 for Customer Service—which itself sits directly atop Dataverse as our “single source of truth” for data—or a third party solution. Case and incident management might inform our “burnout management” scenario, or might be enabled by our “needle in a haystack” scenario in cases where we need to quickly turn up with the right person for the job.
We’re using a combination of Event Grid, Azure Functions, API Management to orchestrate the integration of data with partner organizations, in this case with other (military) commands or sister agencies with overlapping jurisdiction, NATO partners (in the case of military cooperation), civilian agencies, and inter-agency reporting such as a real-time crime reporting database (in law enforcement scenarios), etc.
Many organizations—particularly in public sector—have requirements to integrate with Big HR say from a parent agency, ministry, or service, so the scenario here is doing so via Azure Data Factory as the primary integration service. The final node in our diagram shows a potential modernization path, wherein an organization that may have begun its transformation by relying on a legacy payroll solution has since modernized via Dynamics 365 for Finance.

The Road Ahead

I tell my team all the time: “This isn’t easy. If it were easy, then anybody could do it”.

Truth, but that’s only part of the story. The real truth is that everybody must do it. I opened this essay with the proposition that we are experiencing a seismic, generational transition in the way that organizations buy, use, and enable their own success via technology. This transition is on par with its historical antecedents: the mass market availability of personnel computers in the workplace, the ubiquity of the internet, and the migration from “on-premise” to cloud. We’re living in the Cloud Application Platform Era.

Though it offers revolutionary opportunity, cloud transformation is an evolutionary process, not a single big bang. Its achieved through a combination of solutions built atop the modern data platform architecture, data kept in place, integration with legacy applications, re-hosting, true application modernization, and more. In other words, we need not—nor often can we—modernize everything today. It requires an organizational commitment to the discipline of platform-first over the urgency of today’s point solution, to strategic versus tactical decision making, to building an ecosystem instead of a pile of tech, and to the creation long-term value in the cloud.

Remember: The road ahead is a long journey up to 220th Street. Midtown Manhattan wasn’t built in a day.

The Cloud Application Platform Era is a seismic, generational transition for cloud technology