My conclusion was that "in many ways, Gartner's iPaaS reference model (in all its complexity and ambitiously broad scale) is everything you DON'T need to know about Cloud Integration to be successful".
In contrast, this article is a pragmatic approach to integration - "Everything You Need to Know to be Successful with Cloud Integration".
No dogma, no philosophy, no agenda - simply the key things you need to know to be successful with your Integration project. The fastest and most direct path to sustainable Integration success.
Pragmatic Cloud Integration - no Gartner iPaaS Required
As I mentioned yesterday, "By that I mean that you cannot buy any single product that even remotely begins to incorporate all of the capabilities specified by Gartner Research as "iPaaS"."
So, let's talk about something useful when it comes to Cloud-based Integration.
For those of you who are spending time digesting the iPaaS reference architecture, mapping numerous products and their capabilities to the legion of iPaaS requirements and trying to figure out how all that relates to your needs - your competition will be finished and successful with their Cloud Integration project before you are finished with your intellectual exercise.
Everything you need to know about Cloud-based Integration can fit into three bullet points totaling 25 words (if you really crunch it down).
You'll be surprised at how simple Cloud Integration can be when you focus on the only thing that matters - what do you need to do to be successful with it.
Cloud-based Integration is quite straightforward. Seriously, it is. 25 words simple.
I'll use more because ebizQ pays me by the word. By each and every single word. Every one that I type in my Cloud Integration articles. Seriously. Every one. For real.
What to do about Gartner Research's iPaaS
Forget about Gartner iPaaS's and CEIP's. If you want to be successful today - right now and for the foreseeable future, worry about these three things. That's "pragmatic".
So, here are the things you need to know - in the form of questions:
1) What are you trying to do? Alternately stated "what are you trying to accomplish?" Hopefully you already know the answer to that.
2) What type of integration is the "best fit" for solving your problem?
There are 4 popular types of integration that you can choose from - it's usually a pretty easy choice. If you don't know what those 4 forms are, keep reading, I describe them in the FAQ below.
3) Which Cloud Integration product (for the particular type of integration you need to do) is the best fit for your company and your project?
Popular Cloud Integration products such as Dell Boomi, Informatica Cloud, MuleSoft iON, SnapLogic (in alphabetical order) to name a few focus on particular types of integration (such as Data Integration or Application Integration).
Narrow your focus to the vendors who do your particular type of Integration well and pick the one you like the most.
Follow these three steps, and you will be Cloud-Integrated and reaping the benefits of Cloud Integration while your more analytical brethren are still busy creating their iPaaS and CEIP PowerPoint charts with hundreds of little check boxes and debating whether Product X deserves a half check or a three-quarter check for some capability they'll never actually use - a capability that's applicable for some integration type that they don't have any need for.
My best wishes for your pragmatic integration future.
pragmatic [prægˈmætɪk] adj
1. advocating behaviour that is dictated more by practical consequences than by theory or dogma
2. (Philosophy) Philosophy of or relating to pragmatism
3. involving everyday or practical business
Frequently Asked Questions
For those who have questions, I've assembled the answers to a few FAQs.
I'm happy to answer other questions if you leave them in the "comments" section of this blog or you can always email me (hollis at softwareanalyst.net)
Q: What is Cloud-based Integration?
Cloud-based Integration is software that runs "as a service" in the Cloud. It is subscription-based and "pay as you use".
There are a fair number of "pretenders" out there - they claim to be Cloud-based Integration solutions, but in reality they're just technology comb-overs. Their websites and PDFs and PowerPoints are loaded full of cloud pictures.
But they offer few of the benefits that Cloud-based Integration brings to the table.
It's important to identify any "pretenders" up front. Just because I can compile a bunch of 25 year old code and make it work on Amazon's EC2 doesn't make it a real Cloud-based solution.
I've written some articles - such as "Is Your Integration Stack a Dinosaur" that may help you discern the real-players from the re-treads.
Q: What is it used for?
Cloud-based Integration is used to "connect" multiple applications, data sources or data files to make them more valuable for the organizations that rely on them.
Q: What Kinds of Cloud-based Integration Are There?
There are a number of different models of integration out there - 4 common ones.
These different models serve different purposes and they have different product architectures- just as minivans serve a different purpose than motorcycles or school buses. They're not necessarily better or worse per-se - it's just that some problems are appropriate for one architecture, and some problems better handled by another.
They are very different, and accomplish very different things. There is no single product that does all 4 - it's a bit of a contradiction in terms. IBM, for example, has various different products for addressing the different integration models. Sterling, for example, does Managed File Transfer (but doesn't do the other 3 kinds).
You may have a need for multiple different Integration types - that's not unusual for enterprises or for very large projects. You may use one vendor for populating your data warehouse and a different vendor for automating order-to-cash business processes on your ecommerce system. My next door neighbors have a Honda Odyssey minivan and a cute little 2 seater convertible of some sort. Having 2 different kinds of cars is not unusual, and neither is two different kinds of Integration.
Q: How Do I Choose?
The key thing is to understand what you want to accomplish with your integration.
A quick overview of the popular integration models usually helps people identify very quickly which one they need, so in alphabetical order:
Application Integration systems are typically "real-time" and event-based in nature. These integrations are typically business process oriented - that is to say, as soon as "something happens" in the originating application, for example, when a customer orders a product, it triggers the integration platform to do something -for example, submit the credit card charge to the payments system. It's the automation of a business process that spans multiple operational systems, and the real-time guaranteed and transactional nature is often very important. As such, they tend to be optimized for near-realtime delivery of small transactions.
Data Integration systems are batch-oriented in nature - that is to say, they move data between systems on a scheduled basis. That schedule might be once a month, once a day, once an hour, or every few minutes. But it's not done in real-time. It may also transform, cleanse, standardize or enrich the data along the way. As the name suggests, these integration products are focused on the data.For example - I recently spoke to a company who uses Cloud-based Data Integration to copy data from SalesforceandZenDeskseveral times a day into a Cloud-based Business Intelligence/Dashboard system - one of the most common use cases for this type of product. As such, they are optimized for chugging through large quantities of data.
Data Integration and Application Integration are the most prevalent integration forms - and are often confused.
Application Integration is concerned about the completion of a business process - for example, the information about one particular customer and an associated order gets sent to a payments/billing system, where the process of billing that customer's credit card is invoked.
Data Integration is unaware of processes and worries about the underlying data. For example, copy all new orders from yesterday into the customer support database. The following graphic may help:
Federated Data Integration:
Sometimes this is called Enterprise Information Integration (either way it's third on the list) and it is about providing a layer of abstraction so that various different kinds and sources of data all appear to be as one. And the data are "retrieved" from all those different sources and brought together "on command". If you need "up to the second" current information for a management dashboard, this approach is for you. If you run a lot of big historical data reports with information from multiple places, this method isn't for you.
Managed File Transfer:
This is technology for securely transferring, managing, tracking and monitoring the transfer of computer files (rather than data) from one place to another - often between businesses. Key features include reporting, notification, non-repudiation, auditability, global visibility, automation of file transfer-related activities and processes, end-to-end security, and performance metrics/monitoring. If you're thinking that it sounds an awful lot like EDI, well, it does.
Q: You mentioned CEIP - What's That?
Please don't ask me that question.
I sort of (but not really) answered that it in yesterday's article - about half way down and just before the "The Cost of Waiting for an iPaaS for Cloud Integration" section.
Q: Do you really get paid by the word?
Heck no. I like the idea, though.