I wrote a post on the SnapLogic blog this week about the wave of innovation that is happening in the data and application integration market and introduced two new data management acronyms (like we need more, I know) – OETL and OEAI:
- Old Extract, Transform, Load
- Old Enterprise Application Integration
There’s no shortage articles (and books) on disruptive innovation and why it’s so hard for on-premises software vendors to transition to the new era of social, mobile, analytics and big data, and the internet of things (SMACT). Here are 10 reasons (some unique and some applicable to all mature technology vendors) why legacy data integration and middleware vendors are struggling to re-invent themselves:
- Cannibalization of the Core On-Premises Business
- Heritage Matters in the Cloud
- EAI without the ESB
- Beyond ETL
- Point to Point Misses the Point
- Big Data Integration is not Core…or Cloud
- An On-Ramp to On-Prem
- Focus and DNA
You can read the entire post here. Let me know if you agree / disagree – I clearly have somewhat of a bias.
Here’s a powerpoint I worked on in 2007 that continues to be appropriate today.
Search “IFTTT for the Enterprise” and you’ll see that almost every week now there’s a new cloud service/vendor being launched that has cracked the code of balancing data integration simplicity with power. Search “Data Preparation” and you’ll see a new category of vendors that are now positioning themselves as ABETL (Anything But ETL). You even see SAP embracing simplicity, but many long-time customers and pundits certainly see that as mission impossible.
I wrote a post last week about the rise of the Citizen Integrator on the SnapLogic blog now that “simplicity is the new black” in the new world of DIY data access, integration and management. Here are a few requirements that I think are going to be essential ingredients:
- Single Sign On- If you want more people using the tool, it’s going to have to be as easy to access as other cloud applications.
- Cloud-Based Design Environment – Many of the integration tools out there continue to rely on eclipse-based developer tools or last generation’s on-premises tools. These are hardly going to attract the new breed of Citizen Integrator.
- Create, Edit and Schedule – Citizen Integrators are going to expect to be able to drag, drop and connect.
- Broad Connectivity – Maybe this goes without saying, but integration tools must be able to connect to cloud and on-premises applications, databases, files, and big data sources.
- Extensive Deployment Options – Cloud to Cloud, Cloud to Ground and Hybrid deployments must be supported.
- Configurable, Re-Usable Patterns – Don’t make me re-invent the wheel. Give me some starter templates and allow me to share them with others.
- Mobile Monitoring – There’s an app for that! As Salesforce1 now allows me to run my business on my phone, integration should also be turned into an app for specific use cases.
- Online Training, Tutorials, Community – It’s no secret that SaaS and community go hand and hand. DIY developers are going to want to find what they need with a few clicks.
In a series of recent posts on the SnapLogic blog, I’ve been reviewing the primary requirements of a modern integration platform. In this post I outlined some of the key principles behind SnapLogic’s Elastic Integration Platform, as well as the most popular posts on the blog. (Not surprisingly, 3 of the 5 most popular posts were written by the company’s Chief Scientist.)
The presentation below provides an overview of 7 things you should know about SnapLogic’s elastic integration platform as a service (iPaaS):
In 2009 I worked with data and application integration guru David Linthicum on a whitepaper called, “What to Look for When Evaluating Cloud Integration Solutions.” The 6 requirements were:
- True multitenant versus hosted offering
- Ease of use
- Try and buy / rapid deployment
- IT or LOB usability
- Vendor viability
While I don’t think I’d change this list too much in 2014, I’ve been putting together a series of posts on the SnapLogic blog summarizing the requirements of a modern integration platform. Now commonly known as integration platform as a service (iPaaS), the 6 primary requirements are:
- Fully-Functional Cloud-based Service (based on a Software-Defined Architecture)
- Single Platform for Big Data, Application and API Integration
- Elastic Scale
- Built on Modern Standards (REST, JSON)
- Broad Cloud and On-Premises Connectivity
- Self-Service for Citizen Integrators
Let me know if you agree or disagree with the list. I’ve embedded a demonstration of the SnapLogic Elastic Integration Platform below if this is an area of cloud computing that is new to you.
For 5+ years this blog has focused primarily on the topic of integrating cloud applications like Salesforce.com, Workday, ServiceNow, Zuora, etc. with each other and with on-premises applications like SAP and Oracle. Occasionally I’ve written about the shift to cloud-based business intelligence tools and platforms, but it’s been mostly all things software as a service (SaaS) and integration platform as a service (iPaaS).
Thanks primarily to YARN and some of the advances in the Hadoop 2.0 platform, this week SnapLogic announced SnapReduce 2.0. Cloud application integration has expanded to big data integration. Here’s SnapLogic’s Chief Scientist Greg Benson discussing the news.
Last week I hosted a webcast that reviewed the results from a recent SnapLogic TechValidate survey on cloud integration. You can download the complete results of the research here. The webcast also featured a deep dive demonstration of the SnapLogic Integration Cloud. I’ve embedded the recording below.
This week Maneesh Joshi from SnapLogic posted an article on Wired Insights called: Why Buses Don’t Fly in the Cloud: Thoughts on ESBs. It’s a pretty deep post, summarizing the vision of a services oriented architecture (SOA) and why the concept of the enterprise service bus (ESB) has reached its limits in the era of Social, Mobile, Analytics, Cloud and the internet of Things (SMACT). Here are a few snippets:
“Long implementation cycles, inability to absorb change, and high costs have made it difficult for these ESB solutions to keep up with fast evolving business requirements and often resulted in unmet expectations.”
“The ESB as an agile integration layer has been exposed as the long pole in project plans and customers are looking for alternatives.”
“On-premise ESBs or cloud integration platforms that are natively XML-based but apply translations to JSON at its extremities to keep up are going to fall short in the world of SMAC.”
“REST and JSON together are increasingly replacing SOAP and XML, making ESBs less relevant in today’s enterprise SMAC architecture.”
“Sticking with legacy technologies such as ESBs will only hamstring organizations from innovating rapidly and capitalizing on emerging opportunities.”
Do you agree? Do you see integration platform as a service (iPaaS) as complementary or a long-term replacement of the ESB as more and more of the applications and platforms are delivered in the cloud?