Four Critical iPaaS Requirements You Can Ignore Only At Your Own Peril (Part 1)
The concept of integration platform as a service (iPaaS), as defined by Gartner, Forrester, Ovum and other analyst firms, has gained significant awareness for enterprise IT organizations facing a new set of challenges posed by rapid cloud adoption. There are a number of options to consider once you recognize that you need a cloud integration strategy, most of which cater to the classic requirements of:
- Metadata-driven integrations
- Drag and drop user experience
- Pre-built connectivity (no coding necessary)
- Management & monitoring that includes comprehensive error management
- Transactional support
- SOAP and REST API support
- Data transformation and other operations
- Hybrid deployment model
In my conversations with IT leaders over the past few months, two recurring themes are clearly driving the urgency of iPaaS in the enterprise:
- “Cloudification”: Cloud expansion has hit a tipping point and most IT organizations are either running to keep up or trying to get ahead of the pace of this transformation.
- Agility: Business users? need for speed stemming from mobile, social and SaaS expectations.
As a result, four new iPaaS requirements have arisen:
- Fluidity in hybrid deployments
- Minimal lifecycle management of the platform
- Future-proofing for the world of social, mobile, analytics, cloud, and internet of things (SMACT)
In this series of posts, I?ll cover each one of these requirements in detail while highlighting the importance of each, starting with Resiliency today.
Changing business requirements has always been the norm. Expectations of IT responding to them in real-time is a much more recent requirement. More often than not, these changes result in data changes that end up impacting the integration layer. The most common changes on the application, data and API side are additive, where a new column is added to the table or a field to an API to record or deliver additional information.
iPaaS technologies built in the last decade are strongly typed. This means the integration developer must define the exact data structures that will be passing through the integration flow while designing them. Any departure from this structure results in the integration layer breaking down. If you want to see what I mean, run a simple file-to-file integration using a product built in 2000s. Now, edit the source file and add a couple of more unexpected fields to it, and run the flow again. The integration will fail because it cannot recognize these additional fields. This brittle integration layer can bring your business to its knees before you know it. Hence, you should expect your iPaaS to be resilient enough to handle such updates and variations in its stride. Of course, there are going to be situations where you want to enforce strong typing. A good iPaaS provider will include a data validation step just for that. But the default way of initially handling such changes should certainly be a lot more resilient.
By adopting a modern iPaaS, customers benefit greatly by negotiating these new requirements gracefully. There is tremendous cost saving and business risk containment benefits that arise from avoiding downtimes resulting from changing API and data structures. A resilient iPaaS will keep your business running even when unexpected changes occur. A high degree of integration agility equates to greater business agility.
In my next post, I?ll talk about Fluidity in a Hybrid Architecture. You may also want to check out how the SnapLogic Integration Cloud handles the broader set of iPaaS requirements in earlier posts and in this technical whitepaper.