Cloud Integration Redefined: A Q&A with Elias Terman of SnapLogic
by Ron Powell
Originally published April 30, 2012
BeyeNETWORK Spotlights focus on news, events and products in the business intelligence ecosystem that are poised to have a significant impact on the industry as a whole; on the enterprises that rely on business intelligence, analytics, performance management, data warehousing and/or data governance products to understand and act on the vital information that can be gleaned from their data; or on the providers of these mission-critical products.
Presented as Q&A-style articles, these interviews conducted by the BeyeNETWORK present the behind-the-scene view that you won’t read in press releases.
This BeyeNETWORK spotlight features Ron Powell's interview with Elias Terman, Director of Product Marketing at SnapLogic. Elias and Ron discuss the why integration is so critically important for today’s cloud solutions.
Elias, can you give us a brief overview of SnapLogic for those in our audience who are not familiar with the company?
Elias Terman: SnapLogic is a cloud integration platform. Basically, we provide an easier way for enterprises to connect, transform, enrich and deliver data across on-premise applications and ESBs, enterprise and consumer clouds and big data. We also connect the different cloud services to each other whether it be Salesforce, Workday, or Facebook and Twitter. What we're finding is more SaaS [software-as-a-service] applications are being adopted in the workplace, and SnapLogic helps enterprises weave these newer cloud services into their existing systems.
Elias, what do you see as the biggest customer integration challenges for companies today especially with the cloud, and how does SnapLogic address these?
Elias Terman: I think the biggest integration challenge today really centers around connecting these newer cloud applications with on-premise systems that were purchased in the last computing era. We often see enterprises struggling to use their legacy ESB and EAI systems for cloud integration. The reason they’re struggling is that these legacy systems were originally designed to integrate just a few mega-apps, all running behind the corporate firewall. These were typically large multimillion-dollar projects with a few large data feeds optimized for batch processing. With these older systems, the cost and time required to add a new connector or to make a change is very high. We're seeing enterprises struggling to use these older systems because it’s just slow and cost prohibitive relative to these newer cloud applications that they're trying to integrate. So this old model doesn't work when you have dozens or even hundreds of applications. SnapLogic was designed from the ground up to handle thousands of applications and data sources. SnapLogic makes it a lot easier to address this environment where you have a burgeoning number of new cloud applications and data sources out there.
Well you make a good point. When I look at the early days of data warehousing and data integration, the biggest impediment was hand coding. In addition, we now have all these other disparate data sources. Can you provide an example of a customer implementation that moved from hand coding to SnapLogic and tell us what kind of results they were able to achieve?
Elias Terman: Oftentimes we see that hand coding is sometimes the result of just wanting to get something up and running quickly. They say, “Well, I'm not going to use my on premise ESB or EAI system because it's just too involved and too expensive to do it.” So they turn to hand coding. It can be seductive because the developer can open up a big IDE and just start coding the integration. That can work okay if you’re doing a point-to-point integration. But what’s going to happen is you start connecting more things, and a point-to-point integration becomes maybe five different integrations. And if you change one point in the system, you actually have to change 15 different integrations. It becomes very cumbersome to maintain it, and we see this situation often.
One example of a customer is OSI Restaurant Partners. They have Fleming’s Prime Steakhouse, Roy’s, Outback Steakhouse and other restaurants. They have more than 85,000 employees across the country. As you might imagine in the restaurant industry, they’re onboarding and offboarding employees all the time. Previously, they were assigning all these enterprise resources to their employees via hand-coded scripts. A busboy doesn't get an e-mail account but, obviously, a manager would. They need to be setup in all different systems – ADP, ExpenseWire, Active Directory, things like that. All the business logic and the rules for how employees were to be setup were buried in this hand code. There was really no visibility. By taking all that logic and putting it into these visible, reusable, integration pipelines in SnapLogic, they were able to automate a lot of that process. And then if there's a change, instead of having to peel through 20 pages of code, they can actually just pop open the designer and make a quick change through their browser. We created a lightweight integration hub that orchestrates all these business processes across about 20 different cloud and on premise systems. They’ve drastically reduced the number of internal support calls and completely automated the onboarding and offboarding of employees. This basically led to increased efficiency and lower costs as they are able to provision and de-provision employees in near real time.
SnapLogic is built on a RESTful architecture. Can you tell us more about REST and what the value is for potential customers?
Elias Terman: REST stands for representational state transfer, and this refers to the architectural style as first described by Roy Fielding’s doctoral dissertation (2000) at the University of California, Irvine. Basically, what Fielding explained was that the World Wide Web could be used as a platform to connect services on a global scale. His work showed that the Web itself is an application platform, and that REST provides the guiding principles for building distributed applications that scale well, exhibit loose coupling, and compose functionality across service boundaries. A RESTful architecture is simply an Internet style of computing. It's basically a mode of interaction where each request is independent of any other request. This is important for web-based applications since a request may be routed to any number of servers.
For example, if you type a URL into your web browser, you don't really know or care where the servers are that provide the underlying service. SnapLogic is the only integration platform based on a RESTful architecture. What this means for customers is that users, infrastructure, and data can be anywhere. When you create an integration workflow in SnapLogic, it’s instantly available as a Web service. It has its own URI, also known as a URL, so you can actually call up that integration workflow from any HTTPS point – for example, from an iPad or mobile device. Using this standards-based approach provides access to nearly any cloud-based application. Virtually all of those applications are already supporting a browser-based interface. In addition, what’s great for enterprises is that we have a Snap Software Development Kit that allows enterprises to actually make their old on-premise legacy systems RESTful. In that way, we help enterprises embrace and extend legacy apps into a cloud future. Then you can get at these approved data sources and do whatever you need to do with them very easily.
You have an ecosystem of applications that you call a SnapStore. When was the SnapStore created, who creates contributes to it, and how would it help our audience?
Elias Terman: The SnapStore began in 2010. I’ll start by explaining Snaps a little bit for those that are new to SnapLogic. Snaps are simple intelligent connectors that interoperate with each other – kind of like Legos. You might buy a Lego set for a truck and another for train. While these are two different systems, you know you can build things with them because they both share a uniform interface – the Lego interface. Snaps abstract the complexity of the underlying application, data model and service. They’re intelligent, and they introspect the underlying application, which in the world of SaaS can change rather quickly. For example, our Salesforce Snap not only renders standard objects and fields, but also custom objects and fields.
The way the SnapStore works is that you download a Snap, and you can do this in a matter of seconds, kind of like the Apple Apps Store model. We put every Snap through a rigorous QA process that includes a line-by-line code-level check. There are Snaps for database connectivity, on-premises enterprise systems, SaaS applications, social media, and more. When you download a Snap from the SnapStore, you immediately have browser-based access to a rich palette of modular components that you can drag-and-drop onto a visual canvas to build your integrations.
And again, we're using a common standard here, a browser for our designer, which helps encourage the widest adoption. And as you’ve seen with both the iPhone and Android marketplaces, enterprises are building their own private mobile apps, and the same is now happening with SnapLogic customers who enjoy being able to “app-ify” their approach to integration by leveraging the SnapStore model. So they're regaining control and lowering the cost of application integration. You can buy a Snap from a SnapStore, or you can make your own. This type of open market really reduces vendor lock in.
If you go to the SnapStore, you can see many of the Snaps were built by ISVs. A lot of times, they will build their own Snaps and put them there at no charge because they want to remove integration as an obstacle in their own sales cycle. System integrators often charge for their Snaps. In those cases, like the Apple model, they keep 70% and SnapLogic takes 30%. The growth has been amazing. In just two years, we’ve amassed more connectivity than many companies have in ten years.
The other day I was talking to Canonical, one of our customers. They make the Ubuntu operating system. One of the developers there informed me that he had built and developed a private Snap for OpenERP, an open source ERP system. He banged it out in his spare time. Of course, he could have asked SnapLogic to build it or one of our partners, but the point I'm trying to make is that with all these new applications out there, people want options.
The Snap Software Development Kit includes Eclipse and NetBeans plug-ins or you can develop using Python. There are six million Java programmers out there and an exploding number of Python developers. So gone are the days of struggling to find scarce consulting resources with deep expertise and some closed proprietary integration system to build a connector. People just want options.
Does SnapLogic stand behind the connectors that others build?
Elias Terman: We stand behind anything that's in our store. Now a lot of enterprises build their own Snaps. They build a Snap for some unique application that they've had for years. Obviously, that’s not going to go in our store. It’s unique to them, but they still can benefit from the same platform that’s been battle tested in the commercial environment, just like enterprises build their own private mobile apps.
This is wonderful. Elias, I really appreciate you bringing us up to date on what's happening at SnapLogic. You’re really helping people connect with the cloud.
Recent articles by Ron Powell
Copyright 2004 — 2018. Powell Media, LLC. All rights reserved.
BeyeNETWORK™ is a trademark of Powell Media, LLC