Welcome to the Think Tank with Frank Kenney
With decades of analyst and integration industry experience, Frank Kenney is fountain of knowledge on all things tech. Now, he aims to share that awareness with you. Come back every other Thursday for your biweekly dose of thought leadership in this blog from one of technology’s most insightful thinkers and gain perspective on a variety of topics ranging from what’s happening in integration today to what’s on the horizon, poised to disrupt the integration space going forward.
I want you to think of a painting. One painting in particular – The Advocate by Ernie Barnes. If you aren’t familiar, I suggest googling it. Trust me, it’s worth your time.
If we ignore the underlying meaning and significance of the work, we simply see depicted a man reading a book, a legal pad in his left hand scribbled with notes, a pencil between his teeth, and an understanding that this is how we used to work. But times change.
Every morning I wake up in a miraculous world full of Anything as-a-service (XaaS) offerings that, so very much unlike the antiquated world of paper, have let me personalize my experience. Just enough so that I feel I have some measure of control, but not so much that I end up having to manage the infrastructure tax that comes with heavy customization. Today, my morning coffee is going well with a generous helping of SaaS from a few high-profile XaaS providers:
Coffee → Gmail → Reddit → more coffee → Salesforce.com → Outlook 365
What is XaaS?
XaaS or Anything as-a-service, refers to the increasingly popular form of delivery and consumption of software, storage, computing, infrastructure, platform, and even business and industry services versus traditional models. Or in the simplest of terms, cloud-based versus on-premise, respectively.
We are spoiled. Or at least I am. All of the tools that I need to work with every day are cloud-based. No double-clicking on fat clients and waiting for the interfaces to load. No updating applications outside of the ones that power my experiences such as my browsers and chat clients. Life is good in a cloudy world.
Now, add to this XaaS world the integration platform as a service (iPaaS) coupled with the mindset of self-service and you set the table of expectations as follows:
- All accessible via a standard browser
At this point you might ask yourself, are these expectations the same as requirements? At least you should be asking yourself this question. Above all, integration is important to every aspect of the business.
Why the Easy-to-Use Expectation is Setting You Up to Fail
This is the expectation that many in the market have when it comes to integration technologies. Recent Gartner surveys have expressed the desire that companies have for “easy-to-use” technologies. In fact, ease-of-use is more important than fit-for-purpose when it comes to how companies narrow the field, select, and purchase integration platform as a service technologies. And that makes perfect sense.
After all, the easy-to-use experience starts my day. From the time I sit down with my first cup of morning coffee, ease-of-use dominates most of my interactions with technology. Thereby, XaaS exposure creates XaaS expectation, even when we want something that’s easy to do really complex and difficult things.
Now for the purpose of making a point, I’m going to exaggerate. Do you remember the Easy Bake Oven? I had to look it up on Amazon for the details, but it was a popular kid’s toy in the 1980’s. It used a light bulb to bake cookies. Sure it was easy to use – it’s made for children. But if you want to serve a chocolate soufflé to a party of dinner guests, you’re going to want a real oven.
Take for example the concept of ecosystem enablement. Here at Cleo, we’ve made giant leaps in the ability to onboard and manage all aspects of ecosystem and partner onboarding, and enabling continual management. And while the experiences we offer feel like all of the other XaaS services I use every day, when you deal with ecosystems, you are dealing with complexity.
There are many aspects of ecosystem enablement and trading partner management that don’t lend themselves well to operating in a browser. While it might be very easy to drag-and-drop lines from one element to another in a browser-based development environment, it’s quite another thing to create and map hundreds of nested elements and objects within an EDI or XML schema.
Further, the personas that consume those technologies aren’t looking to simplify or clutter their development environments. No, they are looking for ways to use their existing environments in their future integrations, orchestrations and mapping endeavors. Simply put there is a finite point that technology providers reach when cloud enabling their products and services.
Do you want a browser-based EDI mapping tool? How much functionality would you give up for it? In my world, the mapping and development environments are divorced from my production environment. And my production environment and related processes are in the cloud. I create maps on my laptop, and sometimes my iPad, and those maps are executed someplace else… Far enough away that I do not incur capital costs of servers, etc…
We can get so caught up in the importance of having an “easy-to-use”, “self-service” environment that we don’t consider the “functionality cost” of moving to that type of environment, in my case, the richness of the development environment: Extensibility, simulation and instantaneous code validation and testing. While no one can argue that doing things in a browser can greatly improve the experience a user may have, what is the functional cost?
Every once in a while you have someone that will stand on the stage pull out an iPhone and say, “This is the form factor that the world is moving to!” Every once in a while you’ll read an article that will challenge the reader to embrace all-cloud, everything. You’ll even hear from the occasional analyst who will point to the consumerization of IT and demand that everything should be deployed with consumerization in mind.
And for the most part, I agree except when the functionality cost is too high to pay.