The whole picture: getting the most out of your integration platform

Are integration platforms just old wine in a new skin, re-marketed for our age? At some level, you could say that; integration is integration, after all, decade on decade. From the era of EAI to the era of the ESB to the now and present form, iPaaS, applications consume and produce data to work together. But I would argue today’s integration platforms are an entirely new breed. Here’s a look at what modern integration platforms have to offer, and how enterprises can find the right solutions to meet their needs as complexity grows.

Integration platforms have evolved dramatically

Integration technology has served for years to make and manage connections and align the semantics of the data between applications. Likewise, B2B is B2B, broadly. Businesses produce and consume data to conduct business together. B2B integration technology has served to make and manage these connections and align the semantics and proclivities of each organizations use of standards.

At the same time, there has been a sea change in the landscape for the following reasons.

Changes in technology

APIs and API management represent the single largest change in the integration landscape. APIs inserted themselves into the integration landscape as an internet- and firewall- friendly standard for interoperability (good for integrating cloud apps and a new form of B2B).

What’s more, APIs largely replaced proprietary application connectors that marked industry and industry challenges for years, and they also brought in the developer persona to the discussion – as a consumer of the APIs, as an integrator and as an innovator (developing experiences). That last point is not inconsequential: APIs serve the people integrating/automating as well as the ones building new experiences.

Cloud(s) and cloud delivery

This has been a huge change. First of all, organizations are moving to cloud(s) and cloud-based architectures for in-house development. Then, the applications we integrate as SaaS are delivered in clouds (and thus need to be integrated from whatever cloud they are in) and use cloud-friendly methods of integration (i.e. APIs). Third, integration technology is also delivered in the cloud, ending the painful history of “upgrades” of big on-prem solutions, allowing economies of scale in use of cloud infrastructure.

And then there’s the new financial model for organizations consuming integration technologies: subscription. Integration, like the very processes it helps integrate, is now SaaS itself.

User Experience and the Citizen Integrator

Say what you will about the reality of Citizen Integrators and a non-technical person building an integration, but no matter who the user is in the integration space, the tectonic shift in user experience we see present in all technologies has cast itself into the integration landscape.

Further, the SaaS/self-service delivery model of an iPaaS requires great user experience. Integration has focused on being easier to consume. Buyers in the line of business can now operate under the radar from Procurement to try and consume technologies, and the best experience will win.

The shared service and self-service enablement model in IT

IT can no longer say “no, get in line,” delaying projects until they have freed up the capacity to build integrations or support projects. IT must scale and enable lines of business to be self-sufficient through self-service tooling, enablement, and much greater flexibility. At the same time, they must prevent a complete Wild West situation that throws compliance and centralized audits to the winds.

With all of these developments, how can an enterprise confidently choose the right solution(s) for their needs? And how do different solutions work together as the ecosystem they operate in expands?

How to select an integration platform: Best of Breed or Best of Suite?

I wish there were an easy answer here, but the truth is, it’s a mix. The breadth of integration disciplines required by an organization stretches beyond a one-size-fits all approach. Mergers and Acquisitions, departmental choices in technology, and embedded integration tools in infrastructure make the one-size-fits-all approach near impossible.

Furthermore, a single integration discipline may require specialization. To assume one vendor, one suite to deliver all, is therefore unrealistic in practice.

For this reason, an open approach to integration platforms should come first. “Best of suite” is now marked by openness: it’s a necessity for the enterprise strategy and allows for best-of-breed where it is (often) required.

What does this mean in practice and what does it look like? It means adopting an enterprise integration strategy where IT serves the business, with a mix of integration technologies delivered through self-service for lines of business.

Axway has delivered our Amplify Platform with this in mind, and at its roots is our Open Everything philosophy. Openness in the sense that it is multi-cloud, multi-protocol, and multi-gateway, but also that openness comes first from an effective API strategy at the heart of the platform.

Openness and interoperability

From embracing enterprise APIs – wherever they may be found – to curating them in a common catalog, an open approach means building API products that break down enterprise capabilities for consumption in integration use cases as well as innovation use cases. The final step is to publish these API products to a marketplace for discovery and use.

In a model of composability, APIs become the lowest common denominator of enterprise capabilities: they are the sources for innovation and the means for integration of any type. APIs are the essential building blocks for new business models, new experiences, and for co-creation with other enterprises.

With this of course, APIs become the new B2B, and hence when mixing these together, the marketplace must have an “internal” as well as an “external” and possibly “public” face.

Back to integration, openness allows for APIs from other integration vendors to be brought in, as well as for other collaborators to consume services or publish flows through the marketplace. In our own example, we offer world class B2B integration to address the traditional B2B patterns as well as the emerging API-based B2B patterns with our Amplify Platform for a breadth of use cases. Further, we publish APIs for the traditional use cases to marry the old and the new. In all cases, APIs are at the heart of this.

Beyond that, our own B2B integration platform can be paired with third-party and competitors’ solutions. In one case, an Axway B2B customer uses Axway’s application integration tooling but also has customers that have an iPaaS (or two) in play for application integration which connect with the Amplify platform (best of suite). The iPaaS (whether best of breed or not) they’re already using ties in with Amplify, as does Amplify’s native tooling. This allows customers the flexibility of choosing us for MFT, B2B, or our API Platform even if an incumbent application integration tool is in place.

Finally, an open approach to integration is an excellent way to avoid vendor lock-in.

Getting the most out of an integration platform

Three essential elements to getting the most out of integration platforms are:

1. Taking a shared service approach, delivering integration capabilities as self-service with APIs at the center,
2. Strategically delivering enterprise capabilities as API products through a platform, which allows for flexibility and agility across patterns and use cases (the heart of all things integration and innovation)
3. Building out a strategy, competency, and enablement team centrally to oversee the larger platform’s delivery.

In terms of integration goals, reuse is important, as today’s organizations are much more dynamic.

A smart approach here would be to adopt an API First strategy that sits behind all integration. As I mentioned above, APIs act as the lowest common denominator for an organization and can be consumed by integration flows and/or development initiatives – which are very likely to change.

The overarching integration approach and core API strategy should be defined and known in-house; it requires proper implementation and knowledge of this strategy, as well as a solid understanding of how enterprise capabilities made available as APIs can be differentiating.

By starting with the API strategy, organizations can then work towards integration self-service for the lines of business, and weave in capabilities from there. But beyond this essential internal API know-how, outsourced resources can work from here.