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.
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.
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?
Got SaaS? Salesforce? ServiceNow? Workday? Zuora? Amazon Redshift?
What about on-premises apps? SAP? Oracle? Microsoft Dynamics?
Don’t forget social media, big data, identity management, online storage and cloud analytics solutions…
I summarized 5 signs you need to re-think your cloud integration strategy on the SnapLogic blog today. Here’s an overview: