As I write this latest post, I’m somewhere over the US, cruising at 35,000 feet and hastily making vapor trails toward attendance at my first Gluecon event in Broomfield, Colorado.
And you know what, I’m pretty excited too.
Not only has Gluecon got a great lineup for 2011 and a promise of being an excellent event thanks to the organization skills of @defrag and the quality of the attendees (including many of my esteemed members of the Clouderati) but for me personally, it signifies another interesting shift in my daily focus – away from the murky underbelly of bare metal, speeds, feeds, virtualization, automation – hell, even away from all *aaS in general – and to a place where I never thought a classically trained infrastructure guy 1 would operate.
1 – That’s where I spent most of my career, growing up.
This week, my new world is that of the API – touted by many as an important part of the fabric of the next wave of internet innovation – and in the same way that one experiences the immediate delight upon landing at a foreign airport for the first time, it feels good, yet quite strange to be here.
I’ve written before about my assertion that to make fundamental changes in technology adoption to support new business paradigms, organizations must equip themselves with change agents, employees who ooze a professional curiosity from every pore and possess a hedonistic attitude to want to render their current skillset effectively redundant, all in the name of progress.
Well, what do you know? Here I am walking the talk and looking for yet more change.
In a recent post entitled “If You’re API And You Know It” I posited my initial thoughts of how a well planned and well executed API strategy might be a trick that is being overlooked by traditional enterprises as they embark upon their individual cloud strategy. The always engaging Lori McVittie recently sounded out her thoughts around performance metrics of APIs and her post sparked me back into life – I’d been contemplating writing this one for a few weeks.
I’m lucky to be able to talk to a lot of different companies about their plans for future IT environments. Unsurprisingly, many of those large enterprises that I talk today are at various stages of their next generation IT planning efforts, wrestling with a myriad of choices from virtualization to automation and private cloud to SaaS.
I don’t envy them, having been there and got the scars to prove it, but most interestingly, I hear many of them talking about “clouds” of one form or another but I don’t hear many of them talking about “what happens when my applications are cloudified?” and specifically, not many at all are talking about how they will enable the information from the traditional, hugely complex, monolithic application stacks or even from newer applications which have been architected for cloud to be put the hands of increasingly savvy and impatient users who will drive that demand from a growing number of different, yet always connected mobile devices.
Are enterprises truly gearing up for how they will deal with meeting the demand that will inevitably come from the burgeoning consumerization phenomenon?
My somewhat educated guess, today, is “no”.
Could it be then, that an API strategy such as I previously hypothesized may serve as an enabler of a new, agile and information driven business in which APIs can be used to expose functionality and content while providing the basis for new, lightweight applications to be written quickly and simply in either native languages or HTML5 for almost any mobile device?
Probably. Now I’m in full Gluecon mode.
It’s a safe bet to suggest that most enterprises have had at least some kind of mobile strategy, for the last 10 years or more, pretty much ever since RIM burst on to the scene and enabled the first widely adopted mobile email and application platform. However, that approach was certainly pre-consumerization, very much modeled in the Draconian style of “IT defines the policy, secures the whole environment, makes no distinction between corporate and personal data and in most cases owns the device”.
Many traditional MDM (Mobile Device Management) tools have, in my opinion, taken an “all or nothing” approach, reflective of the “command and control” mentality of restrictive IT departments, hell bent on throwing a containerized ring of steel around the device, the applications and the data all in the name of compliance, risk management or some other coat peg to hang the blanket strategy on, the more restrictive the better and whatever it takes to make the CIO feel comfortable.
I believe this model is not sustainable. It’s in need of a serious re-think.
As consumerization takes a vice-like hold and user demand grows exponentially, the proliferation of devices will come fast and without warning. These devices won’t always be corporately issued, standardized or controlled and the applications and data that reside on them won’t always be third party delivered by external marketplaces – in fact, a growing number will be applications (enabled in some cases by your API strategy) that you write, you deploy, you manage, you choose the appropriate levels of security for and more amazingly, you provide the storefront for.
Now we come to an interesting space. The Enterprise Mobile App Store. Or lack thereof.
To highlight the gap between consumer and enterprise, and the challenge of providing your very own enterprise mobile app store, let’s consider the consumer experience of Apple’s App Store versus what the very same company provides in the way of anything at all useful for enterprises to use as an equivalent. See? Unless I want to go through the pain of getting my application into the official Apple App Store, I’m pretty much limited to an essentially worthless Over-The-Air capability that, in and of itself, masks the horrid complexity and tedium of the mechanisms forced on enterprises by Apple relating to their Developer Program and the ludicrous Enterprise Provisioning Profile fan dance that must accompany every iOS application that you wish to distribute internally (even if you could do so with any finesse).
I’m not fruit bashing deliberately, but I’ve long held a suspicion that Apple really doesn’t care about enterprises and in fact, does just enough in the enterprise space so that they don’t suffer total organ rejection.
This problem isn’t unique to Apple, however. With slightly less effort, I could probably create an Android application and get it on to a Marketplace of one kind or another. Not trivial but not too hard. I’m not so sure about Windows Phone 7 apps or RIM apps or whatever mechanism will come with the advent of WebOS apps, but I’m still perplexed by a couple of burning questions.
Why would it be pre-supposed that I actually want to put my internal applications, specific to my business, on an external app store – can I not provide a enterprise mobile app store to manage entitlement and access to cross-platform, native or HTML5 applications with a combination of Mobile Device and Mobile Application Management driven by flexible and adaptable security policies to support the next generation of mobility in the enterprise?
The reality, per the graphic below, is that it is likely that enterprises will need to consider a strategy to deal with MDM and MAM for at least 5 major platforms by 2012 – I would add the capability to provide a cohesive enterprise mobile app store that emulates a consumer-like experience and simplicity is undoubtedly going to be a major factor in any successful go-forward mobile strategy.
graphic courtesy Ojas Rege of MobileIron – thanks dude.
There are a couple of startups that are doing some very interesting things in the enterprise mobile app store-meets-MDM and MAM space (and although I am not at liberty to name them a brief Google search may yield good results) and although each of them are initially focusing on the iOS and Android platforms, it is a very young market but one that if my positive vibes about Gluecon and the potential velocity around APIs for the enterprise are confirmed, could be a very hot one in the coming months.
