I’ve long since given up the perennial quest of predicting “what this year will bring”, skillfully leaving this particular exercise in bland rhetoric to those bold enough to want to suggest whether 2013, 2014, 2015 or 2021 will indeed finally prove be the year of VDI, Linux on the Desktop or herald the arrival of other such recondite concepts like Hypervisors-on-Smartphones (TM).
Instead, for this first post of MMXIII, I’ve opted to provide a single further interested observation from my daily vantage point, betwixt and between the past, present and future of Enterprise IT. Consider it, if you will, a post that delivers a semi-hypothetical “what might happen next”, assuming that you are sufficiently far enough advanced in your journey of change to have put the moribund discussions of “what is cloud, is it secure, should I choose public v private and what’s the difference between IaaS, PaaS and SaaS” behind you and focused on the important tasks of addressing the needs of your business.
The assumption that an enterprise has navigated the first waypoints along the journey of change is broad, yet required for a realistic appreciation of this post. It doesn’t require any technical expertise (thankfully – who needs another software-defined-meh discussion?) but it does require at least an acknowledgement that consumerization is, and will continue to be, a major force in how Enterprise IT shapes itself for an exciting future and, perhaps more importantly, is a willingness to accept that that very same Enterprise IT has already lost control and succumbed to a wave of change that makes it futile to try to put the proverbial genie back in the bottle.
I’ll follow up the last sentence’s revelation with a suggestion that Enterprise IT has progressively been losing control for the last 10 years or so, but, to borrow a well-worn adage, this time, it’s different.
I’ve been around large Enterprise IT environments for more years than I care to remember. I’ve driven change, I’ve seen reluctance to change, I’ve seen new technology come in, I’ve seen old technology stay in, but one thing that I have witnessed that has remained constant is the incredible ability of end-users to circumvent the ball-and-chain approach of many Enterprise IT shops and find their own “innovations” that, first and foremost, enabled them to be more effective in their daily work. Many of these innovations came in the form of snippets of software, or micro-applications, usually created through a combination of necessity, whatever was available on their desktops and sheer bloody-mindedness.
Where I come from, they call it Skunk Works.
The original Skunk Works has it’s genesis deep within the bowels of Lockheed Martin’s Advanced Development Programs of the mid 20th Century and spewed out some pretty incredible hardware, including the U-2 and the SR-71, among other things (many of which you really wouldn’t want to wake up to flying over your house), but, according to Wikipedia, the term has become generalized over the years:
The designation Skunk Works is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects.
In the case of the end-user circumvention described above, it’s the reference to being “unhampered by bureaucracy” that most resonates. There must be a million stories and demonstrable use cases of end-users bypassing the applications they are told to use, abandoning them in favor of a “little MS Access database that I wrote” which fits their work process well enough to get the right results, on the end-user’s terms. The same must be true for “complex Excel spreadsheets we created, with pivot tables, charting and reporting” all created because the end-user was empowered, the tools were relatively simple and the results were equal to, if not better than, those from the cumbersome, complex applications that were foisted upon the end-user.
The smarter reader will already be about to arm-wave furiously and say “yes, yes, we’re also seeing this in the way anyone with a credit card can go out and sign up for SaaS. In fact, we, yes, us, have already “found out” that <gasp> people are actually doing this in our company.” Welcome back to 2009.
That’s all great, but perhaps unsurprisingly, given my recent focus in our business (discussed in this Cloudcast “API” session with yours truly and the erstwhile Sam Ramji), it’s where this same concept goes when we focus on the explosion in mobility, yes, that elusive Post-PC Era, that piques my immediate interest – and hopefully yours too.
Arguably, APIs in the Enterprise context help democratize data. They are the key to unlocking information, but what they don’t do is democratize that information. Today (depending on your position in the journey of change) that’s the job of a new swathe of developers, creating slick and sexy mobile UIs – native or web – for the provision of information and updating of data. Tomorrow, I suggest, there will be a shift toward the empowerment of end-users, providing a mechanism for the self-same approach to “giving me what I want versus what you tell me I need” but with a strategic, unprecedented welcome.
BYOA will mean Build Your Own Applications. That’s powerful stuff. Funny how history doesn’t repeat, but it definitely rhymes.
There are a number of subtle, yet key differences in our Skunk Works of today versus that of tomorrow. Yesterday’s efforts were powered, almost exclusively, by Microsoft Office applications on the desktop. On-ramps were relatively small and technical barrier-to-entry low. Tomorrow’s efforts will come in a myriad of shapes and sizes, and on across a plethora of mobile device platforms – iOS, Android, WP8, Ubuntu…and whatever comes next, but today, the technical barrier to entry is relatively large and barrier-to-entry high.
To a large extent, leveraging the true power of an Enterprise API today in the form of an app for a mobile device requires the skills of a developer. Not many of the end-users that are able to create MS Access databases for their own purposes have the required skills to code HTML5, Xcode or Java and are not familiar with how to interpret a JSON payload.
As we’ve seen time and again, the complexity of any sufficiently new technology paradigms eventually becomes obfuscated by simplification. In turn, user friendliness grows and ultimately drives adoption. We’ve seen this in many cloud IaaS services (remember ElasticFox?) and in the emergence of MBaaS (Mobile Backend as a Service).
We’re also beginning to see the shoots of this in my newly defined “BYOA” space with services such as Tiggzi – which is providing a very slick drag and drop interface, with pre-built REST connectors / plug-ins that allow connectivity back to Enterprise APIs. One of the real benefits of an approach like this is that not only are the end-users ultimately empowered, but they are able to use the APIs to effectively guarantee that their “home built” application is connected to the latest data from the underlying source – something that further works to assure the quality of the results. Tie that to the capability to track application and API usage (we’ll leave “Information Accounting” for another post) and the landscape looks pretty exciting.
Are we there yet? No, of course not. There continue to be challenges around application deployments, provisioning profiles, all kinds of things that would be alien to even the smartest end-users, but my hypothesis is that these will be addressed in the not-so-distant future, providing pretty much all of the toolkit necessary to address the question of “Make An App?” in the diagram below.
Let’s see if my non-prediction proves to be right.