BROUGHT TO YOU IN PARTNERSHIP WITH

Hybrid Integration
CONTENTS

öö The Promise of HIP

öö What Is a HIP?

Best Practices
öö How to Build a HIP

öö Empower the Ecosystem

WRITTEN BY THOMAS JARDINET

IT ARCHITECTURE CONSULTANT

It’s clear that rethinking your integration stack is becoming more and • To build integration flows in a few days rather than a few weeks
more urgent. or months,

• To no longer be blocked by the firewall,

Back in the year 2000, we saw the emergence of service-oriented archi-
tecture (SOA), with the rise of enterprise application integration (EAI) • To embrace both the “do-it-yourself” and the collaborative way
and the enterprise service bus (ESB). These areas of expertise explod- of work,
ed and gave people like me a lot of work until easily 2012, when API
• To have all profiles concerned directly or indirectly by integration
management platforms and more modestly iPaaS platforms had started
around the same table and the same integration stack,
to grow their adoption. At the same time, agility, the cloud, and the rise
• To integrate Cloud and on-premise, and this in an easy way what-
of “citizen-x” (citizen developer, data citizen, and so on) have reshaped
ever the integration topology,
IT, sometimes with 10-year-old technologies. Meanwhile, the older inte-
gration stack is often perceived as obsolete, if not outright useless. (Of
course, API management is not included in these statements.)

In this changing context, the concept of the Hybrid Integration Platform

(HIP) has emerged. A recent survey from Axway found that 45% of re-
spondents have implemented (or are implementing) a hybrid integration
platform to close the gap between new and traditional integrations.
Why? According to the survey, the primary factor driving adoption is the
need to innovate faster to keep up with agile, cloud-native start-ups.

The Promise of HIP

Since the “winter” of integration, the IT world has evolved, and there
is an urgent need to bring more value, more quickly, to new infrastruc-
tures and to a relatively new audience. This is the promise of HIP — to
be able to connect an increasingly hybrid world more quickly. It thus
becomes necessary:

1
Destination:
Hybrid integration platform

How far along the journey are you?

Spend 5 minutes,
save 5 months

Optimize your API program

for innovation

axway.com

• To discuss new use cases around IOT and AI, and
• To activate and blend together the different architecture strate-
gies (services, events, and data).
This multi-dimensional complexity requires the ability to address all
these points, with a combination of possibilities that seems infinite. It
is therefore a question of managing this complexity through a modular
and integrated platform logic so that we will not have to separately
integrate each new business need. In this manner, we can produce inte-
grations as easily as building with Lego toys.
This is how it is possible to integrate the data from a company’s data
lake with a new SaaS application, an IOT management brick, and an old
on-premise database, very simply and quickly (in less than a week), with
just a few clicks. It’s also possible to share these integration capabilities
with integration specialists as well as end users who would like to make
flows themselves, with a solution like Microsoft Flow or Zapier.
What Is a HIP?
So what is a Hybrid Integration Platform (HIP)? First of all, it is important
to understand that it is a concept, just as SOA is a concept. It is not a
ready-made software solution to buy “off the shelf” from a vendor. A HIP
can be defined as any combination of several technologies that integrate
on-premise and cloud applications seamlessly. The general architecture
schema of a HIP can be framed like this:
This view of the HIP architecture shows its hybrid character. The details
will change according to your integration needs, but this view gives you
the big picture of a HIP.
In a HIP, API management is central to all your integrations, and must ad-
dress both on-premise and cloud endpoints. This API management should
work in concert with new data integration solutions, iPaaS/iSaaS solutions
(which we’ll introduce later), RPA, and iBPM, as well as specific cloud plat-
form solutions, and of course, your legacy integration stack (generally ESB,
ETL, and MFT). This is not a comprehensive list — you’ll probably think of a
few additional endpoints for API management in your HIP.
Why Do I Need a HIP? Why Should I Care About
This Concept?
First, if your global architecture looks like the diagram above, or if it will
look similar in the future, you already have or will soon have a HIP. A
3 BROUGHT TO YOU IN PARTNERSHIP WITH
HYBRID INTEGRATION BEST PRACTICES
HIP is far more complex to address than it might seem. You will need
to grasp this complexity on a fundamental level in order to address it
sufficiently. A HIP is, in fact, truly hybrid across several axes:
So, a HIP is hybrid:
• In its use cases: Whether you want to exchange data among
IOT, A2A, B2B, B2C, or SaaS platforms, you can mix integration
points exactly how you want, with the communication patterns
required (files, messages, transactions, and so on).
• With its users: From non-technical enterprise users to integra-
tion specialists, from business partners (of course they want
to to be integrated with your product/services!) to “citizen
integrators” using Microsoft Flow and ad hoc integrators, the
goal is to enable integration for everyone. You can govern these
“integration assets” through a centralized point of integration.
• By the organizational needs it covers: Some business needs
require fast integration — for example, an Office 365 application.
You don’t want to wait to use it; you want it ready and easy to
use. On the other hand, for a very large project, you’ll maybe
let the job be done by integration specialists, or hand it off to
the project developers. You can address different topologies of
organizational needs along with difference SLAs.
• By the architecture strategies it covers: Stop the useless debates
around architecture. You need several architecture strategies
following your specific needs. You need to use and combine sev-
eral integration patterns, such as services-oriented integration,
data-oriented integration, or events integration. Each pattern
uses different technologies, and they all must live and work
together seamlessly.
• By solutions: Following your integration needs, you’ll need dif-
ferent technologies. After this, we’ll zoom in on APIs and iPaaS.
I’ve added data-oriented solutions, like CDC or data virtualiza-
tion, that let you have access to data very easily and quickly.
• By deployment: You need to integrate your endpoints, regard-
less of where they reside, with technologies that work seamless-
ly on-premise as well as in the cloud.
 HYBRID INTEGRATION BEST PRACTICES

• By unforeseen related needs: In general, you must future-proof by abler of hybrid integration, in conjunction with an API management solu-
being able to integrate every new technology that will emerge. tion. And major iPaaS vendors offer prebuilt templates and connectors
that can be easily reused, so iPaaS development can actually require
We see that the hybrid character of a HIP is multi-dimensional, and that
less time than before. This blend can work very well, as a number of
the combinations of possibilities is almost infinite. We must therefore
iPaaS have agreements with third-party API management solutions and
be able to absorb this complexity, and be able to address any idea that
vice versa, API management companies that have bundled iPaaS. The
we may have only conceived of six months ago. Of course, you can
reality is you need both to accomplish today’s more complex integration
imagine a lot of different integration patterns, including many previously
use cases and scenarios.
unheard-of, and even more not supported anywhere.
Finally, one of the potential benefits of iPaaS is to provide an iSaaS solu-
It is important to keep in mind that a true HIP can only be executed grad-
tion. iSaaS is a bit like iPaaS for end users. We can cite Microsoft Flow as
ually, in step with its unique current starting point, new requirements,
an example, which is quite oriented toward office automation uses.
and anticipated future needs.

How to Build a HIP

We can define an essential starting point to a HIP with two technologies:
Between dream and reality, there is necessarily a gap to bridge. To sim-
API management via an API-led application integration strategy, and
plify the task for you, I present what I believe are the main components
collectively with an iPaaS.
of a HIP:

It would be tempting to say that API management is so familiar to the

A GREAT TEAM
tech world that it no longer needs discussion — as the subject has been
Rome wasn’t built in a day. It’s the same for your HIP. It’s a job that
seen and reviewed so often, and is so well-known by top management.
will take time to set up, and therefore needs significant planning
However, there is a value within API management that is relatively over-
resources — starting with a solidly multidisciplinary team. You will
looked: its contribution to the concept of modular IT. Indeed, today’s
have a whole technological stack to set up, depending on the existing
large IT projects, increasingly driven by product logic, mean that any
situation and your future needs. This requires integration experts, but
product/service of a company is the result of a precise combination of IT
it also needs API strategists, development method experts, DevOps
services. Whether these services are delivered in part by applications like
and Agile support, digital transformation experts, and business and
Salesforce or by a specific on-premise business software, they require
architecture experts. To all this, it is also necessary to incorporate
the use of multiple components — and it is via APIs that a new product
your internal innovators and disruptors. Not only will you change the
or functionality can be quickly implemented. Your customers don’t care
way the company works, but also the products the company delivers
that this combination of services is “hybrid” in the way your solutions
and new business models that it will pursue. It is not a question of
are deployed or the ways these services are integrated. The API is their
redoing what has already been done, but rather of ensuring that
main entry point (but not the only one, of course).
you build a competitive advantage that will set the company up for
success in perpetuity.
Another technology, application integration, is at the core of a key HIP
principle. When cloud-based, it’s called an iPaaS. When we have to explain
However, it is not necessarily a question of having a full-time team on
iPaas quickly, we often reduce it to an ESB in the cloud. That’s the general
the project from the start. The framing work is tedious and potentially
idea, but it’s also more than that. A true iPaaS must be API centric at its
time-consuming, and you will not be able to start everything right away.
core and be able to fully address the multi-hybrid nature of integrations.
This is the next point I will address: the planning and construction of
“Hybrid” by the nature of the deployment of the endpoints concerned:
your HIP.

• Which requires crossing the firewalls of various companies in a

secure industrialized way,
• Which requires having hybrid iPaaS runtime deployment capa-
bilities, and
• Which requires making the tool accessible to all types of users,
PLAN AND BUILD
Before planning and building, you need to have a vision of what your HIP
system should be, and which future key endpoints your HIP will leverage.
• If you don’t know where to go, maybe you don’t need HIP, or

and having an extremely simple development process maybe your organization isn’t mature enough.

• If you don’t know what you will be able to sell to your company
There is nothing more annoying than having an integration solution that
executives, you’ll get no money to work on it, or maybe worse,
requires a week of training, all to make flows that should not take more
not enough to accomplish your future needs in the right manner.
than half an hour to develop. All these points constitute the innovations
of iPaaS beyond the classic ESB. They serve to make iPaaS the real en- This vision should adapt to your organization’s changing needs. Compa-

4 BROUGHT TO YOU IN PARTNERSHIP WITH


ny strategy, future needs already expressed, industry trends, competitive
intelligence, and the degree of growth of the cloud and SaaS applica-
tions in your company are all good insights to take into account.
After defining your vision, you must first analyze your existing system,
because you certainly have a legacy on integration topics. You will need:
• Knowledge of current flows to map your existing systems and
subsequently determine what will require changes in order to be
more HIP-ready,
• Knowledge of the integration solutions and patterns you have,
as well as the level of maturity of their implementation,
• Already known future integration needs (the earth continues
to turn, right?), to which must be added any integration needs
expected in the coming year, over three years, and over the next
five years. This requires the intervention of specialists, as well
as your team, in addition to the people you have identified as
innovators. The new uses and new products drive the need for
integration in the first place.
• A vision of emerging technological developments over the next
few years. Where will we be on AI in five years? Did Salesforce
crush everything? Will data lakes become much easier to man-
age, or not at all? These are the questions you should try to an-
swer to identify the technologies that will drive (or hinder) your
innovation opportunities. Of course, no one is psychic, and yes,
you will be wrong sometimes, but at least you will set a course
for topics to come, which you can update regularly.
This is how you can start choosing your core tech, and start setting a
technological roadmap. Every company is different, but I would at least
advise you to:
• Phase your roadmap. It’s a long effort, and you will need to
demonstrate and sell your integration stack. Set up important
milestones so that everyone can know and recognize what you
are putting in place.
• Work in an incremental way. If you enjoy agility, I have no doubt
that you will agree. You will not be able to make a HIP stack
available that does everything right away. Instead, focus on
long-term business value.
• Put some thought into your internal marketing and communica-
tion surrounding this project. You have to sell yourself and your
team to stakeholders.
• Think API and API strategy. This one is hard to miss. (Of course,
always in an incremental way!)
OFFER INTEGRATION AS A SERVICE
In the time of AWS, Salesforce, and all the other existing platforms, you
will need to sell your solution. You will have to sell it to a range of poten-
tial customers:
5 BROUGHT TO YOU IN PARTNERSHIP WITH
HYBRID INTEGRATION BEST PRACTICES
• Project managers:
You must offer them a catalogue of easy-to-understand,
off-the-shelf APIs, but also support them in defining the
APIs to be built with their help. Show them a schedule of
your APIs and their versions, and support them in defining
their integration needs. You should also enable them to
understand for themselves what the best integrations would
be to implement. Transform into a one-stop-shop for them,
to make their tasks as simple as possible.
• Application developers:
You must make your integrations available to them in
self-service, and at the same time, give them the support
necessary to carry out their integrations themselves. This
requires not only traditional support, but also a version of
open-source governance, where the team responsible is
above all the guardian of the temple, letting the projects
work themselves.
• Internal integration siloes:
Many companies have teams that are dedicated to one
specific integration silo. I know, integration should be trans-
verse. You will inevitably have to work with these teams,
however, and you will have to explain to them that your HIP
will not kill their way of doing things. (At the same time, if
they’re interested in joining up with the HIP initiative, you
could say that everybody won!)
• Security team:
You’ll have to explain the reasoning behind your HIP initia-
tive, and to ask them about security constraints. It’s entirely
possible that your HIP will improve security. Work with the
team to find any security improvements that can be made.
• IT director :
Often, the IT director is closer to business users than to the
most technical people. You’ll need to show them the con-
crete value of the HIP to get them on board. Their involve-
ment will be crucial in order to sell the HIP to executives.
• Executives:
Explain what would be easily achievable and demonstrate
key targeted use cases. Seek to inspire them and align with
their vision for their business. They are the ones who will
give you your budget. Sell your HIP initiative to them by
explaining how much a HIP will help your company achieve
future needs, and to attract and retain future business.
 HYBRID INTEGRATION BEST PRACTICES

In order to sell your HIP initiative to these groups, you’ll have to be
able to frame your integration stack as a product. The HIP will need to
improve your company’s operations in measurable ways. Integration will
need to become faster and better as a result of HIP implementation. To
achieve that, you’ll need to create and operate a help desk that will man-
age integration requests, but also to accompany and manage key user
accounts. You’ll need to have technical architects, API architects, and
functional architects in your team. As an integration guru, you will also
need to establish best practices to ensure everyone’s best efforts have
the biggest impact. Indeed, many tasks will be quite repetitive. It is up
to you to gradually operationalize them through a genuine continuous
improvement process. Finally, in the same vein as the need to market
your HIP platform, you will need to ensure that the user experience of
your platform is impeccable.
TECHNOLOGY BEST PRACTICES
As I said earlier, the API is the cornerstone of a HIP. It is essential because
it will be the common point for all your integrations, allowing you to
share your integrations with all types of actors. Nevertheless, as we
have also seen, any number of new technological solutions are regularly
emerging. And this point has two obvious corollaries:
point, the HIP team must likewise integrate with microservices for other
projects, but also integrate their own microservices.)
At the same time, how can you integrate your HIP with aging, legacy
IT? How do you link your mainframe to your customer website? The big
problem is that you can’t give your customers almost direct access to the
mainframe. It would not support the influx of requests.
For example, consider a small insurance company with a mainframe
that did not yet have a customer portal. It would be impossible to API-
call their mainframe directly, and even so, the throttling rules needed for
the API gateway so as not to collapse the mainframe would have been
too restrictive for fully functional use.
At the same time, it’s a simple question of displaying customer
information. Let’s say this company has a close relationship with its
customers, who do not hesitate to call or go to a branch if they need to
get something done. Therefore, we should port this data into a resilient
system — in this case, a SQL database. If the mainframe and database
are synchronized via a change data capture (CDC), the client only needs
to put in Java code that would read the database, then expose this
Java code via their API manager (with throttling limits acceptable to the

• Technological: Yes, it is obvious, but it’s important to keep client). Thus, customer data would remain the full property and respon-

in mind that many subjects are maturing rapidly each year. sibility of the mainframe, and the role of the API is to be the single entry

DevOps? New tools are always emerging or improving. Big Data? point for the customer portal.

We’re talking more and more about DataOps, and the sector is in
So, to summarize, you need to extract the data into a high-performance
full consolidation. AI? We all know that the subject will become
data layer that will be exposed by an API manager. Two main types of
more and more defined in the coming years. Microservices? It is
technologies allow this. The first, change data capture (CDC), is the
an area that is still maturing, whether technologically speaking
bidirectional synchronization between the legacy system of record and
or in its logical architecture in the company. Embarking on mi-
your modern system. The second can be grouped as all messaging tech-
croservices means potentially embarking on a project where the
nologies. These two types of technologies allow the two systems to be
definition of done is a moving target. Streaming APIs? So many
uncorrelated, without impacting the performance and developments of
technologies are available that you may not really know which
the legacy system. From this fast data layer, you can bring needed data
one to choose. It is therefore necessary to be able to follow
into the digital system.
technological developments in order to quickly anticipate and
embrace the requests they will make to HIP teams. The schema can be simplified like this:

• Functional: New technologies create new uses. It is the role of

the API to highlight future uses. So you have to follow these
technologies to see how you might enhance them. The HIP team
is essentially transversal, and it is responsible for proposing and
supporting projects in their development. Indeed, the transver-
sal nature brings a capacity for innovation and a much richer
overview. (Other people’s projects belong to you too!)

I have just mentioned DevOps as an example, for which an additional

emphasis seems important to me. It is crucial for the HIP team to remain
continuously at the forefront of innovations in DevOps. At the high speed Empower the Ecosystem
of production implementation, the other teams will not wait for you to Finally, your HIP will be nothing if you don’t bring it to life for its users.
engage with DevOps to see you deploying quickly. (As a corollary to this Just like many companies at the time of writing are using Slack, Teams,

6 BROUGHT TO YOU IN PARTNERSHIP WITH

 HYBRID INTEGRATION BEST PRACTICES

or Yammer, your HIP will need an engaged community. You must not up for debate. Business users, developers, CDOs, CEOs — all must
communicate on new features, your roadmap, new APIs, and also take be sponsors of your HIP. The ROI will not be immediate and will not
the opportunity to exchange and bring out new ideas. It is therefore be immediately visible, so it is important to make sure that everyone
necessary to bring to life this great engine of innovation that is the HIP. appreciates the stakes involved. The future cost of integration is a key
The innovative personalities incorporated into your HIP team must take consideration of any business project.
control of this process, and must be supplied with the toolsets to do so.
I hope in any case that this Refcard serves as a resource for those who
Design thinking, visual management, and CX/UX are all methodologies
are considering implementing a HIP, and provides a number of keys
that may prove useful. But if you think internal teams are your only
to implement it in a range of diverse circumstances. Like any solution,
potential audience, you’ve already lost! Modern companies operate an
there is not a single possible path, and it will be up to you to find the one
ecosystem, with more and more business partners joining all the time.
that suits you.
This ecosystem is broader than just internal teams. Your HIP should
also embrace partner ecosystems and larger value chain ecosystems —
always with the goal of creating more value for your end customer. You
are not alone in your business, so share your assets and your knowledge
with partners. Collaboration will lead to even more innovation.

The lead innovator is the role that must take charge of the HIP team —
not all alone of course, but with everyone connected to the spirit of
innovation in the company. The HIP team must cement its value in the
minds of the various stakeholder groups in order to work efficiently. As
I said earlier, the subject of integration has experienced its “winter.” It
is therefore necessary to improve its image and re-affirm its value. In
this respect, we will be helped by the contribution of API management,
which benefits from a modern and innovative image, whose benefits are

Written by Thomas Jardinet, IT Architecture Consultant

Thomas Jardinet is an IT architecture consultant with 13 years of experience. He assists clients in defining their
architectures, whether they are organized by function, application, or technology. He is a supporter of flattened
organizations, as he believes it greatly improves the productivity, robustness, and resilience of companies.

Devada, Inc.
600 Park Offices Drive
Suite 150
Research Triangle Park, NC

DZone communities deliver over 6 million pages each month to
more than 3.3 million software developers, architects, and de-
cision makers. DZone offers something for everyone, including
news, tutorials, cheat sheets, research guides, feature articles,
source code, and more. "DZone is a developer’s dream," says PC
Magazine.
888.678.0399 919.678.0300
Copyright © 2019 DZone, Inc. All rights reserved. No part of this
publication may be reproduced, stored in a retrieval system, or
transmitted, in any form or by means electronic, mechanical,
photocopying, or otherwise, without prior written permission of
the publisher.

7 BROUGHT TO YOU IN PARTNERSHIP WITH