02/18/2021

Innovation Insight for Packaged Business Capabilities and

Their Role in the Future Composable Enterprise
Published 11 December 2019 - ID G00441575 - 21 min read

By Analysts Yefim Natis, Dennis Gaughan, Mark O'Neill, Benoit Lheureux, Massimo Pezzini

Initiatives: Applications and Software Engineering Leaders; Enterprise Architecture; Software

Engineering Technologies

Fixed application experiences no longer meet business and customer requirements.

Application leaders managing their organization’s digital transformation must
prioritize the architecture of the composable enterprise and packaged business
capabilities to succeed.

Overview
Key Findings
■ Leading organizations are empowering business units to directly and actively participate in the design
of their application experiences.

■ The “composable enterprise” is the innovation strategy of leading digital business organizations.
Here, application experiences are uniquely composed from packaged business capabilities (PBCs) to
represent current and changing business practices.

■ Democratized development, integration and governance tools enable business units, in partnership
with central IT, to take an increasingly hands-on role in forming their application experiences.

■ API-centric SaaS, API products, product-centric application delivery and digital twins are some of the
current precursors to PBCs and the architecture of the composable enterprise.

Recommendations
Application leaders, in concert with CIOs, responsible for strategic business change in their organizations
should:

■ Create operational preparedness for the composable enterprise experience by developing mastery in
API management, integration, business-IT collaboration and democratized tooling.

■ Develop a prioritized roadmap to renovate or replace critical legacy systems to accelerate the move to
composable application experiences and reject any new monolithic solutions proposed by vendors or
in-house developers.

Gartner, Inc. | 3976170 Page 1 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

■ Accelerate product-style delivery of application capabilities packaged as building blocks for

application assembly by prioritizing agile and DevOps techniques over traditional methods.

■ Transform the culture toward business-led technology innovation by shifting the IT organization from
the nearly exclusive focus on strategic software development to the role of partner and source of
strategic guidance, support, service and some software development.

Strategic Planning Assumptions

By 2023, 60% of mainstream organizations will list composable enterprise as a strategic objective and
will use an increasing number of packaged business capabilities.

By 2023, the now-leading SaaS will offer 20% of their functionality as self-contained packaged business
capabilities.

By 2023, 50% of new SaaS will incorporate independently packaged business capabilities available as
API-centric (“headless”) services.

Analysis
Organizations have become burdened by full-scale applications, like today’s ERP and CRM offerings.
Their size, complexity, inflexible user experience and internal entanglement create a monolithic effect:
high costs, difficult-to-maintain customizations and slow innovation all act as barriers on the roadmap
to digital transformation and the composable enterprise.

Some leading-edge technology vendors like Mambu, Contentful, eBaoTech, commercetools and Elastic
Path offer prepackaged business capabilities today — in that they support, and anticipate for their
customers, the high-agility model of composable enterprise. Organizations like city government of
Antwerp, 1 T-Mobile, 2 Merchants Fleet 3 and Alibaba (Terminus) 4 are some of the early business
visionaries adopting it.

Definition
Packaged business capabilities (PBCs) are software components that represent a well-defined business
capability, functionally recognizable as such by a business user. Technically, a PBC is a bounded
collection of a data schema and a set of services, APIs and event channels. The well-implemented PBCs
are functionally complete to ensure autonomy (no critical external dependencies, no need for direct
external access to its data). PBCs are meant to be used as building blocks for application product suites
and custom-assembled application experiences.

PBCs typically encapsulate a business entity — like account, asset, product or order — and are exclusive
owners of the entity’s data. They provide the complete set of APIs to facilitate its entire life cycle.

Gartner, Inc. | 3976170 Page 2 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

Progressive vendor applications are delivered as collections of preassembled PBCs, ready for custom
reassembly and recomposition. For older applications, PBCs can be simulated by clusters of related APIs
and event channels that represent a business capability but are not backed by a dedicated autonomous
implementation. Simulated PBCs lose much of the dynamics of true PBCs but enable older applications
to participate in the process of the organization’s digital transformation.

Description
PBC Architecture
Business capabilities — identified, isolated and packaged as application design building blocks — form
the foundation of a continuously composable enterprise (see Figure 1). To deliver on this challenge,
PBCs must be sufficiently autonomous (self-contained) and opaque; they also must be scoped and
defined in well-established business terms.

The principles of encapsulation, exclusive data ownership and domain-driven design are familiar to
designers of microservices. One can say that a PBC model applies the microdesign principles at
macrodesign level (and carries over some of the same challenges requiring design and management
discipline). In fact, some organizations, such as Adobe, 5 may refer to the PBC-style components as
microservices, indicating their autonomy and exclusive ownership of data. Note also that the hexagonal
representations are not a reference to a hexagonal architecture model. 6

Figure 1. Packaged Business Capabilities Form Application Suites and PBC Portfolios

Well-designed PBCs encapsulate the operation and the complete life cycle of an entity (asset). For
example, an inventory management capability would own exclusively all data in the inventory and offer

Gartner, Inc. | 3976170 Page 3 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

all APIs necessary to create, update, maintain and analyze the inventory. Some designs might isolate a
named-product inventory management capability in a separate PBC. Other designs may include
inventory of a product in the product PBC.

Some PBCs may be delivered with optional user interface (UI) apps. These may be used as startup user
experiences and are particularly helpful for business users who wish to apply robotic process
automation (RPA) for assembly of their custom application experiences. Still, the primary design
objective of PBCs is integration/assembly of application experiences by way of APIs and event
channels. With time, the low code and other tools that today support integration via APIs well, will
advance to manage the larger scope business capabilities directly.

API-centric design thinking may produce PBCs for smaller responsibilities, while the application-centric
thinking may do the same for larger ones. The right granularity of PBCs is defined in context by the
nature of the business need and the required rate of change. PBCs that are too big will have limited
agility and will begin to present some unwanted characteristics of a monolithic design. Those that are
too small will have limited autonomy and will make business self-service participation in application life
cycle more difficult.

A PBC encapsulates data, logic and processes that implement a well-defined, stand-alone business
capability. They are opaque, in that their internal design, including internal data schemas and services, is
not published and not accessible directly by any means. Interaction in and out of PBCs is via the
authorized and published APIs and event channels. That includes both business interactions and
governance.

Internal architecture of PBCs is encapsulated and likely services-based; external architecture that
interconnects the PBCs into application experiences is a mix of event-driven and request-based design.

Some PBCs may exist stand-alone, but most are delivered as part of application suites created and
managed by application vendors or in-house development teams. For example, an HR application may
include PBCs for interview management, employee onboarding, employee records management, etc.

The collection of PBC-centric applications and the stand-alone PBCs form the enterprise PBC portfolio.
This portfolio serves as the source for organizations’ active assembly of application experiences that
reflect the role’s responsibilities and individual best practices, as they change. Some such assembled
experiences will source the PBCs from one application; others will mix multiple applications. Some will
require custom development of additional PBCs specific to the customer’s practices.

Older, pre-PBC, systems also participate through registering their APIs in the same portfolio directory.
Some will be modernized to isolate the key business capabilities to fully participate in the opportunities
of business innovation.

The Essential PBC/Composable Enterprise Tools

Gartner, Inc. | 3976170 Page 4 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

Application development, integration and governance tools that facilitate the PBC-based applications,
are essential to successful implementation of the composable enterprise experience (see Figure 2).

Figure 2. Essential Tools for PBC-Composed Custom Application Experiences

The primary tools that enable the full life cycle of the composed application experiences and form the
composable enterprise technology platform are listed as follows:

■ Application assembly tools, including support for integration, process orchestration, composition, API
management and event processing. These tools are the fundamental enabling engine of the
composable enterprise.

■ Development tools for custom design of multiexperience apps, including UIs, microapps, processes
and other components.

■ Development tools for custom development of PBCs, including externalized APIs and event channels,
internal “owned” state and historic data, metadata, services, processes and other internal
components.

■ Intelligent security, governance and administration tools for development and runtime
environments, including technology and business semantics.

The formation of composable application experiences engages all stakeholders in the organization,
including professional IT, business unit IT and business users. The stakeholders outside of the

Gartner, Inc. | 3976170 Page 5 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

organization, including system integrators, software vendors, cloud service providers and business
partners, are engaged as well.

The collection of tools in support of creation and operation of composable enterprise forms a
democratized platform that reflects the spectrum of skills and objectives of the participants, including
traditional coding and low-code approaches.

Business-IT Continuum
Central IT organizations have evolved from the traditional centrality of custom development to new
modes of operation that include new roles, such as the specialists in assembly/integration of
application experiences, product-style application life cycle management, and continuous business-IT
collaboration. The new IT-related roles are distributed across the organization, including the business
units and central IT. The role of central IT has thus shifted to that of a partner of business units,
providing support, guidance and advice, as well as new development as needed.

Figure 3. Business-IT Responsibilities Continuum

The continuing empowerment of business organization creates a continuum of business-IT

responsibilities that spans the organization (see Figure 3).

■ Central IT retains the responsibility for strategic planning and development for advanced technology
and cross-enterprise use cases, but its new core role becomes that of the partner, facilitator and
trusted guide to the business units.

Gartner, Inc. | 3976170 Page 6 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

■ Business unit IT. Business units establish internal IT skills to combine their in-depth business
understanding with the available low-code and pro-code technologies, and to empower the business
unit to self-determine more of its application experience.

■ Citizen IT. Business users may finalize the application experiences created by business unit IT and
central IT for their roles and responsibilities by adding or modifying the model over time to reflect their
personal business practices. This is, in effect, citizen IT (see “Maximize Digital Dexterity by Cultivating
Citizen IT”).

■ Fusion teams form to facilitate collaboration of IT and business professionals (see “Fusion Teams: A
New Model for Digital Delivery”). In their collaboration, they follow the organization’s strategic
business and technology objectives while delivering on tactical business requirements and technology
decisions.

Adoption Patterns
Designs like City of Antwerp’s 3 “engines,” T-Mobile’s 4 “commerce services,” Merchants Fleet’s 5
“modules” and the “industry capabilities” of Alibaba (Terminus) 6 are some examples of early adoption
of PBC-style building blocks. City of Antwerp reports that, in some scenarios, transition to this model
allowed it to realize over three years 60% savings in the costs of delivering new business applications.
Although strategic adoption of PBC architecture is a province of leading-edge innovators like those
mentioned above, there are multiple current precursors that are paving the way for the future
composable enterprise.

Organizations using any of the PBC precursor technologies today are

advancing, by plan or by intuition, toward the composable enterprise.

API-Centric SaaS
API-centric (“headless”) SaaS, such as that offered by Twilio and Stripe, is in fact a current
representation of PBCs. It is designed as encapsulated business capabilities (in the case of Twilio and
Stripe, implementing communications and payments services, respectively) that are offered via APIs or
event channels. Some UIs, like dashboards, may also be offered, but the primary business model is to
offer organizations and partners the building blocks for their unique business expression. A special case
of API-centric SaaS is data services (also known as data as a service [DaaS]; examples include
SafeGraph and Oracle Data Cloud). These vendors deliver data-centric business capabilities for well-
defined entities like collected data about businesses or analytics of product popularity.

The number of API-centric SaaS offerings is increasing (see the Representative Providers section below
and the API-centric SaaS innovation profile in “Hype Cycle for Platform as a Service, 2019”). The success

Gartner, Inc. | 3976170 Page 7 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

of this model, introduced by new cloud-native innovators, is putting pressure on the major SaaS vendors
to shift toward the PBC model as well.

API Products and Marketplaces

APIs have traditionally been delivered as projects, rather than as products. Treating an API as a product
involves assigning a product manager role to govern the versioning and life cycle of the API (see “Create
the Role of API Product Manager as Part of Treating APIs as Products”). It also involves treating the
consumers of the API as customers. This can apply equally to both internal and external APIs. In the
case of external APIs, they may be monetized as commercial products (see “Choose the Right API
Monetization and Pricing Model”).

When marketing the API to potential consumers, an API marketplace may be used. API marketplaces are
a good way for individual API providers to create an ecosystem around their APIs. They are also evolving
toward presenting their services in increasingly business terms, which is best addressed by grouping
APIs around a well-defined business capability. The emerging PBCs are surfaced as sets of APIs and
event channels that encapsulate a business capability, so the current investment in API products and
marketplaces forms a foundation for the management of PBCs as well.

Advanced Digital Twins

Although digital twins are more frequently used today to optimize operations of a physical asset (see
“What to Expect When You’re Expecting Digital Twins”), their architecture is well-suited for advanced
representation of any business capability. Digital twins in their fully expressed form must support digital
simulation of the physical asset or process they represent. To deliver this level of modeling, digital twins
must be autonomous, represent the high-fidelity data/state of the device completely, and include all
necessary APIs and event channels to represent all functionality and full life cycle of the asset or “thing”
they model.

The PBCs in their full expression must have the same characteristics: to “own” the state and history data
managed by the business capability, to be autonomous and to represent the life cycle of the internal
business objects. Use of the digital twin tooling for modeling more abstract entities, like people and bank
accounts, is already occurring in some experimental settings. Increasing maturity and demonstration of
the value of digital twins will attract more use of this technology and architecture beyond the confines of
just physical assets like products and equipment.

Product-Centric Application Development

The fundamental premise of product-centric application development and delivery is that individual
business capabilities, grouped into products delivered by product teams, are delivered and maintained
over time independent of other business capabilities of the same application (see “Survey Analysis: IT Is
Moving Quickly From Projects to Products” and “Transform Application and Project Portfolios Into a
Product Portfolio”). The more autonomous the individual delivered capabilities are, the closer the
development organization is to effective product-centric delivery. Inevitably, organizations evolving from
project to product practices are redesigning and reorganizing their applications toward the architecture

Gartner, Inc. | 3976170 Page 8 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

of PBCs. The more prevalent the product-centric model of the application life cycle is with vendors and
IT organizations, the more they will be producing PBC-based applications.

Prepackaged Integration Processes in iPaaS

Most leading integration platforms are low code and include a collection of prepackaged integration
processes (PIPs) — see “A Litmus Test for Business Applications Integrability” — for the most common
integration use cases (for example, moving sales data from Salesforce Sales Cloud to SAP S/4 HANA).
These PIPs surface access to external applications through APIs, event channels or scheduled tasks, and
represent compositions of some functionality of those applications aimed at enabling data
synchronization or process automation across multiple applications. Some PIPs are designed to
represent concise business capabilities — for example, employee onboarding, payment processing —
offered through composition of atomic business functions in those external applications.

PIPs are early precursors of simulated PBCs. They are simulated because the business capability is not
necessarily encapsulated in an autonomous component in the original application, and yet is
represented to users as an encapsulated business capability. Many vendors provide PIPs on top of their
own or third-party integration platform as a service (iPaaS) to facilitate integration with, and access to,
their applications (SaaS or software). These vendors will use the same model of simulating a
composable business capability by exposing APIs in front of monolithic application back ends while
preparing for transformation of their software to true PBCs.

Low-Code Application Platforms

Low-code application platforms (LCAPs) are oriented toward improved productivity in application
development through raised abstraction levels for developers (see “Magic Quadrant for Enterprise Low-
Code Application Platforms”). These platforms model application logic in terms that are more business-
oriented than traditional code. Compare and contrast how one represents business logic flow in a Java
application logic to that of Mendix or Betty Blocks to understand the new abstraction level. Enterprise
LCAPs all support bidirectional API support. As such, they can be the immediate precursor tools for
assembly and orchestration of PBCs, which interact with the “outside world” through APIs and event
channels. As PBCs emerge, the LCAP tools are ready to absorb them into application design models.

Recent trends in the LCAP market show many vendors beginning to offer vertically specialized solutions.
These include prebuilt business capabilities as a collection of accelerators such as application
templates, processes and data models, specific to an industry or even just a narrow segment of an
industry (for example, Finastra’s LCAP specialized for financial industry, or datb for local governments).
The fast growing, cross-industry adoption of LCAP delivers to mainstream users both the taste of
composable enterprise and some of the design tools to manage it.

Middle Platform Architecture (Alibaba Initiative)

Highly influential in China, the Alibaba model of “middle platform” (中台) essentially establishes the
general architecture for a technology-centric business innovation platform. Although part of the middle
platform is technical, like integration or data management systems, equally significant are libraries of

Gartner, Inc. | 3976170 Page 9 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

prebuilt business capabilities like order or product management. These business capabilities, offered
with or without a starting set of UIs, are packaged to be used as building blocks for custom application
compositions. Many business organizations in China, especially those that wish to partner with Alibaba’s
vast business network, are encouraged to adopt this architecture. The middle platform initiative
anticipates large numbers of partners and customers contributing such encapsulated business
capabilities to the total platform portfolio. The success of Alibaba’s vision of the middle platform for
business will make PBC architecture increasingly common in China and gradually in other worldwide
geographies.

Benefits and Uses

Applications that are delivered by vendors, or developed by enterprises as collections of PBCs, have the
following advantages over the more traditional monolithic or semi-monolithic architecture. They:

■ Deliver higher pace of innovation with better controlled risk by relying on the autonomous design of
PBCs and well-defined composition practices

■ Enable active business participation to shape its application experience by supporting low-code
application, integration and multiexperience development platforms

■ Promote the business-IT collaboration culture and the cross-organization continuum of IT roles and
responsibilities by articulating application architecture in business terms of business capabilities

■ Better respond to business demands by closely tracking in software the dynamics and dimensions of
the business model and its practices

■ Offer native support for product-centric delivery as the components of the architecture are
significantly (or entirely) autonomous and therefore can be delivered and replaced without affecting
operation of other components

■ Provide a natural foundation for active formation of ecosystems by treating the PBC portfolio in an
open, provider-independent manner

■ Promote expansive, multiexperience design through the fundamental commitment in PBC

architecture to support mesh app and service architecture (MASA) principles, and the cohesive
delivery of apps across a wide variety of digital touchpoints and interaction modalities

Organizations that adopt PBC-based application architecture will have the following potential
advantages over their competitors:

■ Democratized access to business innovation through active use of technology becomes a common
and safe practice.

■ Balanced distribution of responsibilities and roles — between central IT, business unit IT and
business users — supports faster business innovation at a lower risk. Greater efficiency of technology

Gartner, Inc. | 3976170 Page 10 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

and business investments is facilitated and supervised in the cross-role fusion teams.

■ Business users excel in their roles and are empowered to innovate beyond the common practices
through access to contextual and continuously modifiable application experience. The organization
develops greater digital dexterity.

■ New business models and partnership opportunities are implemented faster and at lower costs by
incorporating business capabilities sourced in the portfolios of ecosystem partners.

■ Upgrade, repairs, improvements and innovation in applications are more seamless and at a lower
cost when delivered through continuous modernization of individual business capabilities, their
orchestration patterns and multiexperience digital touchpoints (see “Use Continuous Modernization to
Build Digital Platforms From Legacy Applications”).

■ Recovery from unsuccessful initiatives is well-managed by recomposition of the affected application

experience.

Risks
The risks of adopting PBC-based application architecture depend on the level of an organization’s
readiness in technology, skills, culture and operational practices. Successful implementation of the
composable enterprise PBC model depends on some important prerequisites.

Without a good degree of mastery in API management, integration, business-

IT collaboration and the use of democratized tools, the attempted PBC
implementations are certain to fail. The organization is likely to blame the
architecture, not its own lack of preparedness, blocking further PBC initiatives
for some time.

The risks of adopting the PBC architecture and the strategy of composable enterprise must be weighed
against the risks of avoiding them. Such comparisons will guide your decision making on when, where
and at what pace to begin the transition.

The risks of adopting a PBC-based composable enterprise strategy may include the following:

■ Poorly designed PBCs (too small, too large or too entangled with external resources) will not deliver on
the expected business agility and will put in question the value of the entire strategy, delaying further
progress.

■ Attempting PBC-based architecture while lacking essential design, development and management
skills for the job may lead to failures and a temporary rejection of the whole approach.

Gartner, Inc. | 3976170 Page 11 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

■ Lack of democratized assembly and orchestration tools, such as low-code application and integration
platforms, will prevent business users from taking full advantage of the PBC-centric architecture and
will lead to low ROI, challenging the value of the entire investment

■ Resistance strategies of major legacy vendors may create some period of PBC “washing.” Vendors
may declare PBCs that are simulations, lacking the expected autonomy and agility and not suitable
for assembly outside of the vendor’s context. Some may offer PBCs usable only inside their own
control environment. Such experiences will create general skepticism in the market for the whole
architecture of composable enterprise.

■ The central IT leadership may resist the expanding self-service within business units and resist,
underpower or otherwise undermine the PBC-based application initiatives.

■ Users with applications that have failed to deliver expected business value will resist investing in new
architecture until they achieve the expected ROI.

The risks of not adopting a PBC-based application strategy (these are great candidates to be translated
into the business case for adoption) include:

■ Slow pace of modernization and business innovation, constrained by inflexible application

architecture

■ Proliferation of little-used APIs that are not organized in a business-centric way

■ Limited ability of business users to define their own differentiated application experience,
perpetuating the frustration of business users with the complexity of generic applications, and
prolonging the disconnect between business and IT

■ Persistent complexity for business users in adopting the vendor-composed, all-in-one application
suites

■ High costs and low efficiency of participation in ecosystems, compared to more progressive enterprise
competitors

Recommendations
Application leaders, in collaboration with CIOs, responsible for strategic business change in their
organizations should:

■ Prioritize mastery in API management, integration, business-IT collaboration and democratized

tooling to achieve preparedness for operating a composable enterprise experience

■ Reject any new monolithic solutions proposed by vendors or in-house developers, and plan to
renovate or replace the old ones to begin to move to composable application experiences

Gartner, Inc. | 3976170 Page 12 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

■ Accelerate product-style delivery of application capabilities packaged as building blocks for

application assembly, using agile and DevOps techniques over traditional methods

■ Build a technology portfolio of democratized tool capabilities in support of development,

integration/assembly and governance of composed application experiences

■ Transform the culture of the IT organization from its nearly exclusive focus on strategic software
development to the role of partner and source of strategic guidance, support, service and some
software development for the business-led technology innovation

Representative Providers
API-centric SaaS and API products are the most direct precursors to the architecture of PBCs. Some,
incorrectly but understandably, refer to them as “microservices.” Indeed, some key principles of
encapsulation of microservices are applied, at the larger scope, to the PBC architecture. The proper use
of the term “microservice” remains in the more technical software design context.

The many vendors delivering this service include commercetools, Contentful, eBaoTech, Elastic Path,
finreach, Mambu, Moltin, Nexmo, Plivo, Stripe, and Twilio.

Additional research by Mike Gilpin, Paul Vincent, Kevin Ji, Jason Wong, Gary Ollffe and Jason Daigler.

Acronym Key and Glossary Terms

CRM customer relationship management

ERP enterprise resource planning

iPaaS integration platform as a service

LCAP low-code application platform

MASA mesh app and service architecture

PBC packaged business capability

PIP prepackaged integration process

RPA robotic process automation

SaaS software as a service

Evidence
1
 Antwerp City Platform as a Service

2
 “T-Mobile: The Un-carrier Unleashes Digital Transformation With Agile Commerce — Full Presentation.”

Gartner, Inc. | 3976170 Page 13 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.
02/18/2021

3
 Fleet Technology to Drive You Forward. Merchants Fleet.

4
 “Alibaba Cloud Adds an Application PaaS Solution via the Terminus Acquisition.” GlobalData.

5
 “Adobe Launches Commerce-Based Microservices Across Its Clouds.” MarTech Today.

6
 Hexagonal Architecture (Software). Wikipedia. [Last updated 25 November 2019.]

Recommended by the Authors

2021 Strategic Roadmap For The Composable Future Of Applications
Hype Cycle for Advanced Future of Applications, 2019
How to Prepare for the Future of Applications
The Key Trends in PaaS and Platform Architecture, 2019

© 2021 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. and its
affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior written permission.
It consists of the opinions of Gartner's research organization, which should not be construed as statements of fact.
While the information contained in this publication has been obtained from sources believed to be reliable, Gartner
disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner research
may address legal and financial issues, Gartner does not provide legal or investment advice and its research should not
be construed or used as such. Your access and use of this publication are governed by Gartner’s Usage Policy. Gartner
prides itself on its reputation for independence and objectivity. Its research is produced independently by its research
organization without input or influence from any third party. For further information, see "Guiding Principles on
Independence and Objectivity."

Gartner, Inc. | 3976170 Page 14 of 14

This research note is restricted to the personal use of maryvonne.tubb@mavenir.com.