“We don’t use THE CLOUD at my company, everything is on-premise.”
This is what an IT person told me as I spoke with them at a recent conference. After asking a few more questions, he admitted that their custom SQL application did actually call out to a web service to get tax rates…and then he continued:
“…and that’s right, we do track our expenses in an App.
…and I guess we outsource our payroll in the cloud.
…and I suppose we do get our currency exchange rates from the cloud also.”
What a difference from the first statement! I asked how they connected all of those cloud systems to his on-premise ERP and Custom system. He indicated that they had written custom code for each of these integration points and wished he could just use one API to connect to all of them.
So, when did everyone start using cloud apps to go along with their other systems? We can inspect that transition by looking at a brief history on cloud applications.
The Shift to using Cloud-Based Applications
We are all using something from the cloud that needs to be integrated with some other system. Why do we have this need? To answer, we must look at the progression of software over the last 20 years. Just 15-20 years ago, if you wanted a system for tracking Employee Expenses, you would have created a customization or purchased some specialized software package that installed inside of your on-premise solution. It would have either cost you months of internal development time or more than $10,000 USD for a pre-built solution.
Move forward to the 2000’s, the software industry started to make web sites that could do some of the cloud functionality. Many of these web sites had horrible interfaces and you were lucky if you could extract data out of the system, even to a text file. But then something happened, smart phones and tablets rapidly changed the landscape. Suddenly, a plethora of small, inexpensive or free apps arrived. These apps brought simpler interfaces and laser focus on exactly what task was accomplished. Gone were the days of having a unified interface to every piece of the software as it was now normal to use several apps (often with vastly different user experiences). The present situation gives us “Best of Breed”, Inexpensive (or Free) and simple apps that may only cost $10USD/month instead of $10,000USD.
A Snapshot Progression of Cloud Usage
How do we know businesses are adopting Cloud-Based applications? This is the point where I could put in an unsubstantiated statistic that says cloud app utilization has increased 157.4% each year for the past 8 years but I won’t do that. Instead, I would ask you, “What are you using personally?” I store files in online repositories like Dropbox, OneDrive, Box, Google Drive, etc. We use applications like Timely, Harvest, Toggl, etc to do simple time tracking and others like Zendesk, Freshdesk, Jira Service Desk or LiveAgent as Help Desk software. For me, it is very difficult to indicate how much the market has grown over the past decade but I can give you a concrete example. We attend tradeshows and user groups to promote SmartConnect (our integration tool), and at one of these conferences the usage of a Customer Relationship Management system that had previously had Cloud usage of only 10% now has over 60%, in just three years’ time.
So, now we have the scenarios like the following: the Mobile Sales team has been using a great app for keeping notes on their accounts and now needs to update the Customer Relationship Management system, the Accounting department needs to get information to reimburse employees for expenses from the app in the cloud and the eCommerce Web Site team needs pricing and quantity available updates from the Inventory Management system. Someone needs to get all of these apps and systems talking.
How do we connect to the Data sitting in the Cloud?
The task of getting data out or even back into a Cloud-Based system was (and still is) a major problem. For most developers of early Cloud-Apps, this wasn’t a point of emphasis or at the very least was a phase 2 or phase 3 approach to design. This has changed in the last few years as many apps are designed from the ground up to return or receive data. But the question remains, how do we get at the valuable information in the cloud without reentering the data in another system again?
Traditionally, this requires the services of developers but we will discuss other options as well. When you want to connect to a cloud app you will hear the developer mutter under their breath words like: API, Web Service, REST, SOAP, Export, Report, Custom Dev. This is a process that a developer must go through each time they are tasked with connecting to another cloud app. If your organization is trying stay away from custom code you do have other options that we will discuss below.
The InApp Integration – This can be a great option for standard integration points between systems. It is often free or has a minimal charge and requires no development. The downside of this approach can be the malleability of the solution which can make it difficult to customize the integration to your business needs or custom systems.
The Manual Approach – A strategy like this may be intentional to avoid a development process or maybe the only option provided by the cloud app. Typically, the ability to export to a text file, xml file or even some type of report is offered for little to no charge in solutions. When you take this approach you will still need to have some kind of process to get the data into the system on the other side of the equation.
The Middleware Tool – Integration using an existing tool can often take some of the complexities that require a developer and bring them down to a business analyst that can take an understanding of the processes between systems and simply map them without writing code. There are many options to choose from in this category (spoiler: We have one called SmartConnect) and they vary in complexity and configurability and of course cost. One of the biggest advantages to this approach is the ability to start from a set of templates and make changes based on your business process. Another advantage is being able to quickly adapt to process changes or modifications to Cloud APIs.
The I-Really-Need-a-Developer Method – There are times when your business requirements are so specific that no packaged solution will work. Also, I have seen some crazy APIs/Web Services that require a developer to manipulate the data that is actually returned. This can be a very expensive and time consuming option but at the end of the day you should get exactly what you want. The downside is that every time your requirements change, it may take just as much effort to make the changes while a middleware tool may allow much quicker changes to business process changes or even changes to a cloud API.
In my next blog, I will give you my recommendations when you are looking at integrating data from/to cloud apps. Can’t wait that long? Comment below and I’ll connect with you directly.
