MiPaaS vs iPaaS

In order to explore the differences between iPaas and MiPaas, let’s first understand what they are.

iPaas – Integration Platform as a Service – is “a suite of cloud services enabling development, execution and governance of integration”

MiPaas – Managed Integration Platform as a Service – similar to iPaaS but where the service provider manages the whole solution lifecycle for you, hence ‘Managed’.

So where’s the differentiation?  That little word ‘managed’ totally changes the way the end consumer interacts with and thinks about such a service; technically, commercially and from a security perspective.  Integration solutions’ very purpose is to reduce workload or cost but iPaaS solutions frequently end up moving both problems to somewhere else within the business, often to a development or IT team.  Rather than play musical chairs with cost, MiPaas is designed to remove it from the business altogether, putting the problem in the hands of someone who’s entire focus is integration.

What are the technical differences?

It’s very common in the iPaas world for end users to implement the solutions themselves from beginning to end; many of the widely known platforms that are available today are self-design, self-build, self-monitor and self-fix solutions.  For many this feels like a good thing because technical people often like control, they like to understand the nuts and bolts of all the kit that’s in their estate.

On day one, when a requirement for integration is first recognised but not well understood, a sense of control provides comfort and the impression of lower risk.  That poorly understood requirement is bound to change, and a belief that the integration can be changed at the snap of the fingers provides the technical architects with confidence that they can stay one step ahead of the game.  Of course there’s a technical learning curve too, but they know this and can schedule the time it’s going to take to learn and implement into the next quarter.  Hey, there might even be some funky technology to add to the CV.

However on day n, once the solution has been in place for a little while and something needs changing or fixing, someone in development or IT has to remember how.  That tutorial video from twelve months ago seems a distant memory and no one can find the password for the orchestration portal.  A password reset later and some poking around, someone’s now staring at an integration wondering why their ex-colleague built it like that and how it ever worked in the first place.  Worse still, they daren’t change it in case the whole thing falls over and the CTO’s finger points directly at them.

MiPaaS turns these headaches into conversations.  When a requirement is recognised, the end user can pick up the phone to someone who knows integration, how best to solve it and how to avoid the pitfalls.  They can talk business language rather than techie which helps the user know they’re describing their need correctly.  A MiPaaS provider has the knowledge needed to implement something today; no learning curve and probably very little delay to get something up and running.

As the requirement evolves, the problem remains a conversation; an email or phone call explaining the changes.  The MiPaaS provider has probably seen similar before, will either know what to do with it or will at least pick up the phone and talk it through with the customer.  No forgotten technology, no passwords to forget, no unfamiliar portal – just someone who knows what they are doing and is there to take the problem away.  Control is not lost, in fact there is probably greater control – guided expert control and the IT teams have the freedom to get on with something else more interesting instead.

Which is more Secure?

Self-service iPaaS generally requires a customer portal.  It can take just one email to get a password reset link or maybe an ex-colleague still knows the password?  Either way, the business’s data flow is exposed through that portal; end points, data transforms and maybe even trace logs.

MiPaaS often negates the need for this exposure.  In fact some MiPaaS platforms carry no web exposure at all so there’s no passwords to capture, no risk of ex-colleagues leaving with access to data flows and endpoints, and no risk of data leaking through insecure web sites.

What are the commercial differences?

Commercially MiPaaS solutions may provide greater clarity and certainty than iPaas. Many of the iPaaS offerings are priced on transactional volume or consumption making it sometimes tricky to accurately predict monthly costs.  A good understanding of data volumes and usage and the iPaaS provider’s pricing model is essential in order to successfully gauge a monthly fee.  A fee that may turn out to be highly volatile; a bumper month of data might mean a bumper month of transaction consumption.

It’s not just about the monthly fee either.  Coupled with the learning curve and the need to ensure that someone in the business can support the chosen technology, hidden ongoing costs can be significantly higher than the flat rate that MiPaaS often provides.  And let’s not talk about the handover/retraining costs when the one person who knows how it works leaves – because those problems very often get ignored until something goes wrong!

MiPaaS allows the end customer to forget these headaches.  Sure, there might be an initial setup fee, but often the monthly recurring fee will be a flat monthly rate, or at worst a simple-to-understand sliding scale.  After all, it’s in the provider’s interests to make it easy to understand.  So the overall total cost of ownership is known in year one, two, three and onwards.  Small ‘fair use’ changes are often covered in the fees and a MiPaaS provider should be well placed to be responsive and supportive as the business needs evolve.  It’s what they do.

And finally… something that sits with both the commercial and technical considerations is when one of the apps that the integration is connecting with changes.  Vendors often update their APIs as their own services evolve, sometimes with little communication beyond their own partner community.  With little or no warning an iPaaS solution might stop working and it’s a race against time to understand why and how to get it back up again.  Suddenly development or IT are facing an un-budgeted, time-critical piece of work (hopefully not a rewrite) to get the business back in action, through little fault of their own.  Other projects might be impacted and there’s probably a re-learning curve for someone to climb in a hurry.

It’s a MiPaaS provider’s job to be on top of this.  They will be part of that vendor’s community and will likely know of the changes and has tested against them and changed their platform as necessary.  The end customer should almost never notice.  Nor should they need to care; they’re paying their MiPaaS provider to take the problem away.

Recursyv are one of the few providers who have invested in MiPaaS, providing managed integration services, advising and supporting numerous customers around the world across a varied set of applications and scenarios.  Recursyv believe that a true managed service should mean that the customer has freedom and control.  Freedom to concentrate on their business while having precise control over their integration needs when they want it.