The Trouble With Choice…

Choices, as the old British adage goes, are rather like buses – you wait patiently for one to arrive and then, annoyingly, several of them arrive at once.

So true is this, that in my continued observation of our beloved tech industry, it appears to be the present day case for enterprises feeling their way around “strategic choices” for things such as cloud management software, smartphones, phablets (what?), software defined networks, API gateways and, perhaps more concerningly, the topic of today’s blog – mobile platforms.

As some of you may already know (and may have seen from a recent video showcase) mobile applications have played a significant role in the advancement of our products & services to support the work we do around the world, but, somewhat akin to our defunct and ultimately rhetorical public vs private cloud debate, I see a lot of enterprises (us included) approaching the new question of native vs mobile web with the same amount of confusion and tumult.

Well, as engineers, we love a good crisis, don’t we?

To understand where we’re going with this new debate, it’s probably worth understanding where we’ve been. At the peak of the great public vs private deliberation, I postulated via this blog post that most enterprises are stuck in a juxtaposition of wanting to move to public cloud but being prevented in doing so by a combination of existing application architectures and a lack of investment opportunity to “throw the whole smash away and start over”.

The reality of running two parallel cost streams (managing legacy version and developing new version) is pretty daunting and in many cases, is tantamount to an impossible sell to the internal bean counters and purse string holders. Period.

You may well be asking – what’s that got to do with mobile? Here goes. For enterprises looking to extend the useful life of today’s enterprise legacy applications (irrespective of whether they ended up private or public clouded), mobile offers a pretty compelling lifeline.

It does so via the concept of an “Enterprise API Strategy” where existing data sources are “tapped” for their rich content, with corresponding business logic and authn/authz honored as part of the magic, and surfaces such content in RESTful ways to be consumed by systems (M2M) and of course, by people, via mobile devices, including smartphones, tablets and…umm…ok…PHABLETS.

Although this may sound simple, let me provide a soupçon of harsh reality – a caveat emptor – if you please. In many cases, it feels like the expression of “putting lipstick on a pig” (1) ought to have its etymology firmly rooted in the results of the War of Irritation of trying to expose functionality or content of crapplications via RESTful APIs, where GET is your closest ally and PUT is your worst enemy.

(1) To put “lipstick on a pig” is a rhetorical expression, used to convey the message that making superficial or cosmetic changes is a futile attempt to disguise the true nature of a product.

Acknowledging that the results of the Enterprise API Strategy are worth the scars of battle places the Enterprise in a very powerful position and your APIs become a very useful currency indeed.

Onward then, to the crux of the today’s challenge, and, with that, the drawing of yet another parallel.

It’s often said that history doesn’t repeat, but it certainly rhymes. How to take advantage of a paradigm shift without attracting duplicate cost or effort? But this time it’s about which mobile platform to develop applications against, not just which flavor of cloud to deploy applications upon.

I struggle to believe there is an enterprise in the world that can make a serious financial / RoI case for developing mobile applications that have individual code bases to support the Big 4 platforms – iOS, Android, Blackberry & Microsoft.

I also do not subscribe to the notion that one can go “all in” on one platform over another, including a strategy based solely on mobile web (HTML5), especially if that enterprise plans to make those applications available to BYOD users (yeah, let’s grasp that nettle shall we?) or other external parties in their ecosystem or supply chain.

The real punch-line is in the rhyming of history. Two years ago, Adrian Cockcroft, Chris Hoff, Simon Wardley and I had pretty much the same discussion albeit on a different topic. The advice at the end of that is as sage now as it was then – understand what it is you’re trying to do, be clear on your objectives and use the right tool for the right job at the right time and the right cost.

The native vs mobile web conundrum is a burgeoning one and is, I believe, on the minds of Enterprise CIO’s everywhere. I’ve read a lot of expert opinion recently, telling me exactly the things I should think about and the steps I should take to arrive at the decision of whether to build native or mobile web, most of which is subjective and insipid, yet I have heard wisdom beyond comprehension from our own guys in the trenches ……“the API is the asset, the UI is simply throwaway”.

Wonderful. Just let that sink in for a moment or two.

bam

(Cross-posted @ The Loose Couple's Blog)

LinkedIn Twitter Facebook
Christian currently serves as Manager of Product & Demand Management at Bechtel Corporation, working in a niche position between the business and technology delivery teams to help identify opportunities to drive worldwide innovation in the mobile and cloud computing areas. Prior to this, Christian was Principal Technology Architect at Manager of Global Systems Engineering at Bechtel. Having gained hands-on experience in 15 different countries designing and managing complex IT environments in support of worldwide project execution, Christian brings a wealth of enterprise experience and led a team that architected and deployed one of the world's first true private cloud infrastructures. Christian is one half of The Loose Couple Blog team and his disclaimer can be found here.