ESB to Event-

Driven iPaaS
The Architect’s Guide to Building
a Modern Data Integration Platform
“
By 2020, event-sourced, real-time situational
awareness will be a required characteristic
for 70% of digital business solutions, and
80% of new business ecosystems will require
support for event processing.”

“
-SOURCE: GARTNER “TOP 10 STRATEGIC TECHNOLOGY TRENDS FOR 2018: EVENT-DRIVEN MODEL.” 8
MARCH 2018, YEFIM NATIS, DAVID CEARLEY, MIKE WALKER, BRIAN BURKE.

In iPaaS we find the groundwork being

laid for a digital future, as the products
in this segment are lighter, more agile IT
infrastructure suited for the rapidly evolving
use cases around digital business.”
-SOURCE: “GARTNER SAYS WORLDWIDE APPLICATION INFRASTRUCTURE AND MIDDLEWARE MARKET GREW
12 PERCENT IN 2017.” 4 JUNE 2018. HTTPS://WWW.GARTNER.COM/NEWSROOM/ID/3877263

Text copyright © Solace

All rights reserved. No part of this work may be reproduced, or stored in a retrieval system, or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, or otherwise without permission from Solace.

For inquiries about permissions, contact:

Solace
535 Legget Drive, 3rd Floor
Ottawa, Ontario K2K 3B8
Canada

Phone: +1 613-271-1010
Web: solace.com
 TABLE OF CONTENTS
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Integration and the Introduction of an ESB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

8 Integration Challenges Architects Must Overcome to Achieve Digital

Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Baking agility into your infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Integrating IoT device and data into your enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Giving legacy systems access to cutting-edge cloud services . . . . . . . . . . . . . . . . . . . . . . 5

Linking globally distributed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Ensuring application portability across hybrid and multi-cloud . . . . . . . . . . . . . . . . . . . . 6

Guaranteeing delivery (embracing “eventual consistency”) . . . . . . . . . . . . . . . . . . . . . . . 6

Avoiding API and protocol lock-in through open standards   . . . . . . . . . . . . . . . . . . . . . . 7

Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

How event-enabled iPaaS unlocks true digital transformation. . . . . . . . . . . . . . 8

Common iPaaS design patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Enter the advanced event broker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

How to event-enable your iPaaS with an advanced event broker . . . . . . . . . . 11

Decouple systems through subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Bridge synchronous and asynchronous interactions. . . . . . . . . . . . . . . . . . . . . 12

Case Study: Consumer Packaged Goods Company . . . . . . . . . . . . . . . . . . . . . . 13

Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

About Solace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Upgrading Your ESB to Event-Driven iPaaS

INTRODUCTION
Companies around the world and in every
sector are striving for digital transformation—
the incorporation of AI, hybrid cloud, mobile
computing and IoT into their business
practices. Such transformation promises
to improve situational awareness and
operational agility, and to help companies
build close, customized relationships with
their customers.
But these benefits don’t come easy.
For most enterprises, pursuing those critical
benefits drives an astronomical increase
both in the number of systems and devices
they need to integrate and in the amount of
information flowing between those systems
and devices.
DID YOU KNOW ?
The iPaaS segment grew 60% in
2016 and 72% in 2017, making it
one of the fastest-growing software
segments.
Source: Gartner Newsroom (2)
Additionally, today’s empowered consumers
expect real-time responsiveness, and
business leaders are tasked with being able
to do so with finer levels of granularity than
ever before.
Simply put, current architectures and
infrastructures are not able to keep up.
One key to success is evolving your
architecture and business processes from
request/reply to event-driven. As analysts at
Gartner put it, “By 2020, event-sourced, real-
time situational awareness will be a required
characteristic for 70% of digital business
solutions....(1)”
The other key: consuming integration as a
service (also known as Integration Platform as
a Service, or iPaaS) so it can adapt and scale
to support whatever comes your way.
This paper describes how you can upgrade
from your on-prem-centric enterprise service
bus (ESB) to an event-driven iPaaS approach
that will facilitate and in many ways future-
proof your digital transformation.
INTEGRATION AND THE INTRODUCTION
OF AN ESB
Integration can be described as sharing
data between two otherwise separate
systems, a process that consists of three
steps:
1. Data retrieval: read the customer
record from App A;
2. Data movement: move the customer
record from App A to App B,
transforming payloads as necessary;
and,
3. Data insertion: write the customer
record into App B.
In the real world this becomes more
complicated as App A usually represents
a record (a customer, for example)
differently than App B.
Or let’s say App A uses “California” for
state records and App B uses “CA.”
This introduces the need to transform
that data at some point. You could
transform California to CA as the data
moves directly from App A to App B, but
in systems with many producers and
consumers of information it makes sense
to rationalize messages into a canonical
or normalized data format.
• Direct transformation: App A -> App B
• Canonical transformation: App A ->
Canonical -> App B, App C and App D
Canonical data formats allow for reuse
of data transformation mappings. They
also add complications that are beyond
our scope here, but suffice it to say
complexity can grow to incorporate
not only complexities in the data
 representation, such as nested data Infrastructure as a service (IaaS)
structures, but also in the relationships platforms provide hardware resources
between records. such as compute, disk, and network on
demand. And platform as a service (PaaS)
Think of a Return Material Authorization
added to that software platforms such
(when you want to return a product to a
as OS’s, databases, middleware, Java
store). There will be a customer record,
runtimes, and more.
maybe a warranty record, and a time of
purchase from the sales record—to name Then, with software as a service (SaaS),
just a few. complete applications were offered in
the cloud—first and still best exemplified
The complex relationships between those
by Salesforce.com. This evolution meant
records of information, both at rest and
that integration now had to extend
in motion, led to the advent of Enterprise
beyond the traditional LAN to include
Application Integration (EAI) software and
these cloud-based services and take
then enterprise service buses.
advantage of the benefits of cloud-native
ESBs retrieve data from source systems, deployment.
transform it as required, route it,
IPaaS addresses this need and brings
choreograph it, and write subsequent
traditional ESB capabilities to the cloud.
data into destination systems. This was
usually done over fast, reliable LAN
links within the walls of the enterprise
(corporate datacenters).

Eventually, the messaging layer was

abstracted from the transformation/
integration layer of the ESB because
reliable data transport scaled differently
and had its own set of requirements. The
key capability for data transport was to
guarantee that the data was delivered
securely, timely, and reliably.

With the growth of cloud-based services,

we’ve seen many critical capabilities shift
to the cloud.

3 Upgrading Your ESB to Event-Driven iPaaS

8 INTEGRATION CHALLENGES ARCHITECTS
MUST OVERCOME TO ACHIEVE DIGITAL
TRANSFORMATION

For companies with fairly simple, low-
volume, non-real-time integration
requirements, a simple integration
model might work fine: hub and spoke
architecture, request/reply interactions
using RESTful HTTP.
But many companies—especially those
linking large numbers of applications and
connected devices, serving multiple lines of
business, or that have complex IT systems
that are distributed across datacenters
and geographies—will need a more
sophisticated system.
User expectations and information
technology are evolving from database-
centric request-based interactions to
event-centric, real-time interactions. From
social media platforms to the Internet of
Things, events are what drive exchanges
of information. This means architects and
developers need to shift their mindset
from being data-centric to event-centric.
Event-driven architectures enable greater
agility, scalability and communication
across diverse cloud and datacenter
environments.
Here are some of the architectural and
operational challenges you will need to
overcome to evolve toward an event-
driven architecture and ultimately achieve
success in your digital transformation
initiative if your system is complex, large or
performance-sensitive.
 BAKING AGILITY INTO YOUR
INFRASTRUCTURE
The evolution of software development
practices and runtime environments means
applications can be created at a breakneck
pace. No app is an island, though, so if
you want to seize the advantages of rapid
development and deployment you can’t
forget rapid integration.
To do this, it’s critical to develop an event-
oriented data sharing infrastructure
that makes it easy for apps to exchange
information with other systems so they can
play their part in business processes and
transactions. Functionality is implemented
as microservices, which consume and
produce events.
This means microservices can be injected
anywhere into a choreographed flow as all
they care about is which event they need to
handle and whether they need to handle it
synchronously or asynchronously.
INTEGRATING IOT DEVICE AND DATA
2 INTO YOUR ENTERPRISE
There are two reasons it’s hard to
incorporate IoT into your business
processes and decision-support systems.
First, IoT devices come in larger numbers
than applications—tens of millions in
many cases. This demands sophisticated
aggregation, routing, filtration and fan-out
5 Upgrading Your ESB to Event-Driven iPaaS
across massive amounts of concurrent
connections.
Second, IoT devices exhibit different
characteristics and behavior than
applications, such as not being on or
connected all the time, and requiring very
low power/bandwidth communications
(many of which dictate the use of
specialized APIs and communications
protocols such as MQTT, which you need to
bridge with legacy APIs and protocols).
Command and control, especially at scale,
is particularly difficult because you need to
make sure that when a user clicks ”Unlock
the door” that their car and only their car
reacts.
GIVING LEGACY SYSTEMS ACCESS TO
3 CUTTING-EDGE CLOUD SERVICES
The investment that enterprises have made
in existing infrastructure is significant and
can’t be thrown away. Many refer to their
way of dealing with this as “cap and grow,”
meaning they cap their investment in
existing assets and link them to new assets
and infrastructure so they can gracefully
grow their infrastructure to meet new and
future needs.
This means they need to make new cloud-
native services, such as AI and machine
learning, accessible to legacy on-premises
systems across their enterprise.
Legacy systems, such as mainframes or
systems of record, are usually written
in Java or C/C++ and will be around for
a long time; they will usually run on-
premises. IPaaS solutions must be able to
incorporate hybrid cloud capabilities that
allow for events to flow to and from these
older systems, as they occur, to the newer
systems that are built in the cloud.
4 LINKING GLOBALLY DISTRIBUTED
SYSTEMS
Integrating applications and devices
running in diverse environments entails
dealing with the realities of distributed
systems. Wide area networks (WANs)
are less reliable than LANs, and have
less bandwidth available and higher, less
predictable latency.
Given the increasingly distributed nature
of IT systems, you need WAN-optimized,
encrypted, and lossless bridges between
different instances of your applications and
integration infrastructure so that events
can flow across a global event mesh in a
guaranteed manner that optimizes WAN
bandwidth.
5 ENSURING APPLICATION PORTABILITY
ACROSS HYBRID AND MULTI-CLOUD
One of the key benefits of migrating
applications to the cloud is the flexibility
it affords, especially if you migrate to the
cloud in a way that is cloud-native and
cloud-agnostic.
Doing so means both eliminating reliance
on proprietary cloud-native services so that
you aren’t locked into any one cloud and
embracing open standards so you aren’t
locked into any one messaging technology
or event broker.
You can bet your business on one cloud,
you can run different applications in
whatever cloud best meets your unique
needs, or you can run multiple instances
of the same applications in multiple clouds
for business continuity purposes. In any
case, you need to build and integrate
your applications in such a way that you
can dynamically move workloads across
diverse on-prem and cloud environments.
Today’s architects focus on building new
architectures that let them leverage
existing assets without being tied to
specific environments or technologies
moving forward.
GUARANTEEING DELIVERY (EMBRACING
6 “EVENTUAL CONSISTENCY”)
If you look at any data flow, you’ll
realize that not all nodes of the flow
must be synchronous. In fact, a very
small proportion of most flows must
be synchronous while the majority
of interactions, such as non-inline
transactions and data logging, are
asynchronous.
 In many cases, these asynchronous proprietary, which can lock applications in
messages simply can’t be lost. You need a and reduce portability.
way to guarantee delivery to all intended
With technology’s rapid evolution, you
recipients (even if something goes wrong
need the peace of mind that comes from
with the network or an application)
using open APIs and protocols such as
whether a given recipient is disconnected
AMQP, JMS, MQTT, REST and WebSocket.
or unable to keep up with the flow of
messages. This includes accommodating
bursts of data without overwhelming
8 GOVERNANCE

recipients or putting back-pressure on Governance is critical for integration at

publishers.
Then there are situations when all
recipients have consumed messages but
need them again weeks or months later
due to technical issues. In such cases you
need to be able to let these applications
“replay” messages.
Global distribution (and the limits of
physics) dictate that not all endpoints will
have the same data at the same time. This
is only acceptable if you are certain that
they will all eventually receive the same
events and therefore share the same state.
scale—for the sake of satisfying service
level agreements, conforming with
corporate security policies, and ensuring
compliance with industry and government
regulations.
You need robust governance for visibility
of events via cataloging, and you need to
be able to “eavesdrop” on events flowing
through your enterprise.

This certainty can only be achieved with

an event distribution layer that guarantees
delivery of events to all endpoints.

AVOIDING API AND PROTOCOL LOCK-

7 IN THROUGH OPEN STANDARDS

Open standards keep you from getting

locked into any architectural decision,
communication protocol, cloud or event
broker. Most cloud-native services are

7 Upgrading Your ESB to Event-Driven iPaaS

HOW EVENT-ENABLED IPAAS UNLOCKS TRUE
DIGITAL TRANSFORMATION

IPaaS offerings from companies such as
Dell Boomi, Informatica, Jitterbit, MuleSoft
and SnapLogic are gaining a lot of traction
in the integration space, and their adoption
is accelerating with the increasing
popularity of cloud-native deployments.
Companies of all sizes are using iPaaS
solutions to integrate a wide variety of
on-premises and cloud-native applications,
which generally encompass the following
four functions:

1. Adapters that enable connectivity via a variety of open and proprietary APIs and
protocols;

2. Transformation of payloads so systems can send and consume information in

familiar formats;

3. Orchestration of processes and transactions that span multiple applications; and,

4. The real-time distribution of events and information via messaging and/or

streaming.
 COMMON IPAAS DESIGN PATTERNS
Many enterprises adopt a very simplistic
approach to integration, as depicted in the
image above.
An ESB or iPaaS (or even an API Gateway)
is deployed. It has adapters to connect or
proxy services from legacy and modern
systems. These adapters could be File or
Database or Oracle or SAP ERP. Sometimes
they could be cloud or SaaS adapters, such
as Salesforce or AWS S3.
Once the connectivity is established with
the enterprise systems, transformations
of payload is sometimes required. The
ESB/iPaaS orchestrates these services in a
tightly coupled manner.
A simple point-to-point, RESTful
architecture works at a small scale, but as
more enterprise systems are connected,
agility and performance both suffer as the
9 Upgrading Your ESB to Event-Driven iPaaS
API interactions get coupled.
As depicted in the image above, as more
upstream and downstream systems
get added a point-to-point integration
mechanism becomes exponentially
complex. This is especially true if the same
messages/APIs need to be sent to multiple
downstream systems.
ESBs, and iPaaS’s that use REST, have
service interactions that are tightly coupled,
which leads to a lack of flexibility. Agility
is also inhibited by orchestration (the
codification of routing rules in BPEL or a
similar expression) as it requires someone
to revisit the code each time an endpoint is
changed or a new one is added.
Adding new endpoints is difficult, and
supporting many endpoints in this manner
is inefficient.
 ENTER THE ADVANCED EVENT BROKER
As systems become more complex or scale
in volume, an event-driven architecture
works much better. Fortunately, most
ESB and iPaaS offerings let you decouple
applications and incorporate events
into the infrastructure by leveraging an
advanced event broker as the foundation
of data sharing behind the scenes.
The core capabilities and characteristics of
advanced event brokers are:
• Support for synchronous and
asynchronous communications using
message exchange patterns such as
publish/subscribe, queueing, request/
reply and streaming;
• Support for best-effort and guaranteed
delivery depending on the nature of the
interaction, such as the need for lowest
REASON #5 FROM 7
WARNING SIGNS YOU NEED
TO REPLACE YOUR ESB:
“You spend more money on servers
and software than on modernizing your
infrastructure.”
Source: Dell Boomi
possible latency and the need to ensure
lossless delivery no matter what. This
includes the ability to ensure delivery
to disconnected or slow consumers
without putting any back-pressure on
publishing systems;
• Ability to link systems using open APIs
and communication protocols such as
AMQP, MQTT, REST, JMS and WebSocket
to make sure each application can use
an appropriate protocol;
• Support for sophisticated event routing
and choreography, including the use of
wildcards for messaging topics (MQTT,
JMS, AMQP) and REST URLs. As an
example, you could publish REST and
consume JMS/AMQP with the REST URL
becoming the JMS topic; and,
• Governance capabilities such as security,
access control, event cataloging, metrics
and instrumentation.
 HOW TO EVENT-ENABLE YOUR IPAAS WITH
AN ADVANCED EVENT BROKER

Now let’s talk about why and how you advanced event broker to handle the high-
can take things to the next level by speed, high-volume distribution of events
incorporating an advanced event broker between globally-distributed applications,
into your iPaaS architecture. devices and nodes of your iPaaS.

Simply put, you’ll be using your iPaaS Here’s what you should strive to achieve as
for frontline integration, application you event-enable your iPaaS as a means of
connectivity, service choreography, and realizing true digital transformation.
message transformation, and using an

DECOUPLE SYSTEMS THROUGH SUBSCRIPTIONS

Agility is king. If you aren’t agile, you won’t synchronous request/reply interactions
be competitive. Building applications as a tightly couple services.
collection of cloud-based and on-premises
If someone needs to define, encode, test
microservices is a great way to make your
and deploy specific paths for information
IT infrastructure more agile, but tight
to take, they won’t be able to quickly adapt
coupling between these microservices
to new requirements. An event-driven
through request/reply-based synchronous
architecture lets new services participate
interactions can keep you from realizing
in existing flows dynamically, without
those improvements.
encoding or deploying any rules.
That’s because event-driven architectures
Traditional ESB orchestration involves
generally enable the loose coupling
codifying service interactions in
of microservices, while traditional
technologies such as BPEL, which means a

11 Upgrading Your ESB to Event-Driven iPaaS

series of services are tightly bound to one
another. In order to add new producers
and new consumers of data, you need to
revisit the BPEL or, as with orchestration,
add the new endpoints, then save, test, and
deploy them.
That process is the opposite of
dynamic, and applies to using REST in a
microservices environment as well.
One of the benefits of synchronous
interactions is you know if the endpoint
received the request, and you can resend
if required. Likewise, in orchestrated
interactions, failures can be tracked and
handled with actions such as retries and
compensating transactions.
When you switch to asynchronous
interactions, the requestor/producer has
no idea if the consumer received the data.
BRIDGE SYNCHRONOUS AND ASYNCHRONOUS
INTERACTIONS
Modern architectures demand that
systems be able to communicate both
synchronously and asynchronously.
Event-driven architectures are uniquely
well-suited to meeting the needs of
asynchronous exchanges of data thanks
to features including deferred execution,
parallel processing, and publish/subscribe
distribution.
Likewise, using self-choreographed service
interactions differs from orchestration
in that failures cannot be compensated/
retried. Guaranteed delivery offsets this
change in capability by ensuring eventual
consistency.
To maximize agility, you must be able
to dynamically produce events and to
dynamically express interest in events.
With some event brokers it takes several
steps to create topics, and they limit or
even prevent the use of wildcard-based
subscriptions. You also need to have
the ability to have “queues” subscribe to
events, as multiple events on topics could
be funnelled into a queue to feed the same
microservices group in a load-balanced
manner.
In short, you need both queuing and
streaming, not one or the other.
However, synchronous exchanges are not
going away; they’re still relevant for exposing
external APIs, issuing commands and sending
queries, to name a few use cases.
A well-designed advanced event broker
supports both synchronous and
asynchronous communications, enabling
seamless bridging between the two kinds of
communications.
 CASE STUDY: CONSUMER PACKAGED GOODS
COMPANY
One of the world’s leading consumer
products companies wanted to reduce
costs and improve corporate agility
by consolidating over 60 datacenters
around the world into just 15 by migrating
applications and workloads to the cloud.
They relied on TIBCO BusinessWorks as an
on-premises ESB to integrate applications,
and TIBCO Enterprise Message Service
(EMS) for queueing, routing, transportation
and persistence of information between a
powerful SAP ERP system and a plethora of
supporting 3rd-party applications.
To meet their goal of migrating workloads
from datacenters to the cloud, the
company selected Dell Boomi to give their
cloud-native systems and services easy
access to capabilities such as connectivity,
transformation, orchestration and error
handling, all of which Boomi provides for
both on-premises and cloud-native systems.
From there the company needed a way
to connect the different service endpoints
13 Upgrading Your ESB to Event-Driven iPaaS
that would exist in their new architecture.
Generally speaking, they needed to
overcome many of the challenges described
above:
1. They needed to establish extremely
reliable and real-time event-driven
communications between systems
running in a variety of cloud and on-
premises environments, commonly
called hybrid cloud and multi-cloud
architecture. Complicating this hybrid
cloud connectivity is that the number
of producers of data is unknown and
constantly changing, as is the number
of consumers of data, which can include
cloud and on-prem destinations such as
AWS S3, Hadoop, Postgres and SAP.
2. They needed to integrate legacy
applications with IoT devices and
microservices, and do so in a way that
enabled gradual migration both from
datacenter to cloud, and from batch-
based to event-driven.
3. They needed to ensure rapid, reliable,
guaranteed delivery over very long
distances (the Internet and private
WANs), factoring for long and less
consistent round trip times, less
predictable availability, and the need to
minimize/optimize bandwidth.
Using the combination of Dell Boomi and
Solace PubSub+, the company was able
to deploy a hybrid and multi-cloud event
distribution backbone for gradually moving
apps to the cloud.
The first application was to synchronize a
master data management (MDM) system
across various internal and external
applications in two public clouds (AWS and
Azure) and an on-premises system of record
as diagrammed below.
Batch data was also transformed into
streams at source, so consumers could
consume a filtered stream on what they
needed via wildcarded topic routing.
 Given this architecture and associated
operational requirements, they needed the
SAP MDM system to be able to distribute
data to downstream SaaS applications. And
as more and more applications were being
spun up in the cloud, they needed the
ability to easily fan-out data to many new
destinations.
They utilized an event-driven architecture
and the publish/subscribe exchange
pattern to decouple senders and receivers,
allowing for the very fast subscription-
based addition of new destinations.
devices only need to publish data to a local
Solace node. From there, AWS analytics can
consume it locally in the cloud either via
subscriptions or a RESTful push.
The company is now looking to build
a global event mesh on this same
infrastructure so they can publish in one
region and fan-out to all the others. This
could very well be a many-to-many data
exchange, made easy with Boomi providing
integration and application services and
Solace ensuring the real-time guaranteed
delivery.

Beyond the master data management While a current Managed File Transfer
application, many other applications—such solution can provide the data movement,
as order management, order processing, it is unable to offer the granularity,
and customer channel integration— self-routing, real-time, and protocol
leveraged the same event-driven iPaaS. independence of a Solace/Boomi event-
driven iPaaS implementation. For that to
The company also needed to give
happen, bidirectional data delivery, which
applications and devices the ability to send
Solace PubSub+ natively supports, would
and receive messages using JMS and REST,
need to be coded into MFT-style solutions.
both of which are supported by Solace
PubSub+. And because they plan to use
this same infrastructure as the foundation
of an IoT platform, they needed support for
MQTT, which PubSub+ also supports.

At the company, data is acquired from the

sensors on the factory floors that collect
information such as temperature and
running time. That data is then sent to AWS
for analysis and then sent back for action
to be taken. Thanks to the event-driven
architecture Solace PubSub+ enables,

15 Upgrading Your ESB to Event-Driven iPaaS

 CONCLUSION
As made clear by the example above, pursuing a digital transformation can both solve
immediate challenges and allow enterprise leaders to cast their gaze toward the future.

This shift in mindset is what Gartner refers to as “event thinking(3)” and it’s critical for
enabling modern data integration and data movement across distributed enterprises.

Combining the easy, flexible, cloud-native integration that iPaaS offerings provide with
an event-driven architecture is the only way to achieve the maximum value from cloud-
native applications, hybrid cloud deployments, and microservices.

Endnotes

1. GARTNER “TOP 10 STRATEGIC TECHNOLOGY TRENDS FOR 2018: EVENT-DRIVEN MODEL.”

8 MARCH 2018, YEFIM NATIS, DAVID CEARLEY, MIKE WALKER, BRIAN BURKE.

2. “GARTNER SAYS WORLDWIDE APPLICATION INFRASTRUCTURE AND MIDDLEWARE MAR-

KET GREW 12 PERCENT IN 2017.” 4 JUNE 2018. HTTPS://WWW.GARTNER.COM/NEWSROOM/
ID/3877263

3. GARTNER “INNOVATION INSIGHT FOR EVENT THINKING.” 5 OCTOBER 2018. YEFIM NATIS,
ROY SCHULTE, ROB DUNIE, ELIZABETH GOLLUSCIO.

16 Upgrading Your ESB to Event-Driven iPaaS

 ABOUT SOLACE
We are the creators of PubSub+, an advanced event broker that can
be used to create an event mesh. As the only unified event broker that
supports publish/subscribe, queuing, request-reply and streaming using
open protocols and APIs across hybrid cloud and IoT environments,
PubSub+ rapidly and reliably routes information between applications,
devices and people across clouds. Established enterprises such as SAP,
Barclays, and the Royal Bank of Canada as well as high-growth companies
such as VoiceBase and Jio use our smart data movement technologies to
modernize legacy applications and successfully pursue analytics, hybrid
cloud and IoT strategies. Learn more at solace.com.

A FEW OF OUR CUSTOMERS

OUR FEATURED PARTNERS

R
solace.com