Integration as a Service

What is it?

Integration as a Service is a step beyond Integration Platform as a Service, it is the provision of integrations or APIs without concern for the underlying infrastructure, typically as a cloud delivery model. Essentially it’s a contractual relationship between the producer of an Integration or API, and the customer, in which the characteristics are focused on the specific availability, performance and scalability (plus other factors) of the API or Integration Flow.

There are two main flavours of Integration as a Service:

Self-service, cloud-based pre-built connector marketplaces
- Solutions such as Zapier, Automate.io , IFTTT and Microsoft Power Automate allow the creation of integration flows with pre-built connectors directly from a marketplace
Custom developed
- 3rd Party solution providers such as Chakray can build integration flows and APIs from requirements and provide them as a service

Value proposition of the capability

The clear value in Integration as a Service is the removal of all overheads associated with platform and infrastructure. The solution is simply provisioned as a “black box” in which the underlying architecture is of no concern, therefore resulting in potentially huge savings in Infrastructure, DevOps and platform maintenance. It is also much easier to ensure services are fit for purpose, with much clearer lines of responsibility and ownership.

The service also makes it much easier for the customer organisation to be digitally agile with regards to integration. Typically integration is one of the key challenges during any transformation initiative, if this is being provided as a service then it’s much easier to change a service with a provider than it is to rebuild or change integrations internally.

Integration as a Service provides known, predictable, costs. Whilst it may not necessarily be a cheaper alternative, it is well understood up front, even with consumption based pricing. Internal integration, infrastructure, platform and DevOps teams can make it difficult to understand the true cost of integration, let alone the specific cost of a single integration or API. IPaaS can result in an easier approach to costing, but development and support services can still make it difficult to calculate on a granular level.

Non-technical users can be involved in integration and build flows that add value to an organisation without the need for “IT” involvement. This is known as the role of Citizen Integrator. The ability to allow business users to develop integrations can lead to improved productivity and innovation of new products and services.

Common uses or use cases

Integration as a Service can be an excellent choice for all use cases, but is best suited to well understood integrations that can easily be mapped and implemented. Complex integrations that are less predictable, spanning many systems with mediation logic can be difficult to manage in an integration as a service scenario and may require a more hands on approach. SaaS applications are also a prime use case as the connectors to them tend to be well known and understood. Legacy applications with non-standard approaches to interoperability will be unlikely to be available in self-service cloud Integration as a Service solutions.

Integrations of a high value are good candidates for Integration as a Service, as even though it can be a costly service, if the value of the integration or API to the organisation is high, then there is a clear return on investment from the service, and a 3rd party can be clearly accountable for the delivery. This can be much easier to manage than relying on internal resources spread across multiple teams.

Organisations with limited infrastructure, integration, platform or DevOps capability or maturity are clearly prime candidates for Integration as a Service. Growing and nurturing these capabilities can be costly and time consuming, so if there are no major needs for the capabilities in other areas of the organisation then it may make sense to simply procure integration as a service. It is also an easier service to articulate as it can simply be specified in terms of business outcomes. When procuring development, integration platforms or testing services, it is important to have the knowledge of what it is exactly that needs to be procured or delivered. This can be difficult to do if the expertise does not exist in the organisation.

Implementation Best Practices

The first thing to consider when looking into Integration/API as a service is the value that it will bring to the organisation and whether it’s being viewed as a Tactical solution or Strategic. For startups or organisations with little to no infrastructure/platform capability, this may be the strategic choice for the organisation going forward. Organisations with those capabilities already may simply procure Integration as a Service in order to accelerate delivery of another initiative. This may be something like the implementation of a SaaS suite such as Workday or Salesforce.

Once the role of Integration as a Service is understood in the organisation, it is important to understand exactly what is needed from the service. A purely SaaS based startup will likely have simple needs related to getting data between A and B and therefore would point more towards the self-service solutions such as Zapier and IFTTT. However, the requirements should be gathered up front to ensure that it’s clear exactly what is expected from a procured service.

For needs that require a more custom approach from a trusted 3rd party, it’s recommended that there be a strong emphasis on supplier relationship management. Supplier management is a critical capability for any organisation with an outsourcing strategy.

Beyond establishing the need and the approach, the next steps are more of a procurement exercise. This would be relatively trivial for self-service platforms as they are easy to start consuming, though the requirements still need to be matched to the provider. The connector marketplaces will likely be very similar, but one may have a specific connector that the other doesn’t, or support a flow that is required etc… so ensure that the functional and non-functional requirements are met by the provider and then start with a basic proof of concept for your organisation checking it’s delivering what is required. If time is not a factor, then the PoC can be conducted with multiple providers simultaneously to compare the experience, features and benefits first hand.

For a bespoke service provider, the procurement exercise should be more robust, taking into account security requirements around data processing, and ensuring that there is no danger of being “locked-in” to the provider. Ideally the service should be easily portable to different providers in order to be in a stronger position during contract renewals. Try and formulate a partnership with the provider ensuring that they truly understand the requirements and broader needs of your organisation. There can be lots of added benefits by having a partnership in this space, especially if the partner is looking after your best interests. It can be beneficial to use another 3rd party to validate the delivered services and recommendations from a partner in order to ensure that you’re getting the best value for money.

How Do Technologies Differ?

In the self-service space, from a technology perspective the solutions vary from basic 1-to-1 integrations to more fully functional integration solutions, though generally they all have a focus on automation of workflows. The pricing therefore tends to be associated with tasks, zaps or bots, general terminology for the actions in a workflow. There are variations on the theme in which some focus more on the connector or connected applications, while others look at data volumes or numbers of records, others are a per user basis, though the most common is focused on actions or flows.

This emphasises the importance of understanding the needs and requirements, as solutions focused on 1-to-1 integrations and app-based pricing may not be the best fit if the requirements are more directed to processes across 3 or more applications.

A custom or bespoke service from a 3rd party could be an already defined service, or the service could be defined as part of the agreement. Typically a defined service will emphasise the underlying technology as a trusted name, even though it will effectively be transparent. A bespoke service offers more flexibility as the service provider can potentially implement a platform that is best suited to your specific requirements. This is likely to be a costlier option, though in some cases it could be cheaper as the provider may leverage technologies that can yield savings.

A clear differentiator in custom offerings is whether it is a shared or dedicated service. A shared service means that the provider will have many customers on the platform, segregated virtually for data protection purposes where necessary. This is likely to be a cheaper option as the provider will be leveraging economies of scale. A dedicated offering will be more expensive as the provider will have all the costs associated with maintaining the environments specifically for your organisation. Security and Data requirements along with financial budgets will help define the best option here.

Considerations

Consider :-

If there are any benefits in implementing capabilities such as cloud/infrastructure management or DevOps elsewhere in the organisation. If there is, then it may be best to build those capabilities and leverage them for integration internally for more control.
Think about the likelihood of changing integrations regularly. If a 3rd party is managing integrations then there is likely to be a cost for changing them. Ensure that this is known and accounted for in the service.
Security and Data Protection. Integration should generally be transient, although it’s important to ensure that data is protected in transit, and if there is any need to store data, that it is secured as per requirements.
Outsourcing in general has a caveat that it can be difficult to return from once the decision is made, though this doesn’t have to be the case. Ensure there is due diligence on abstraction of logic from technology so that any solutions can be easily portable.

Why Chakray?

At Chakray we take a pragmatic approach to integration. One size does not fit all, and with our wealth of experience across many industries, we have a large appreciation for all types, styles and approaches to integration, prioritising outcomes and success above perceived “right” and “wrong”. Integration as a Service is a key service provided by Chakray, though we are happy to work with you in any capacity along your integration journey even if that is to validate existing Integration as a Service relationships.