Mobile shock: Too much change in a short period of time
In this post, we link a few seismic enterprise technology trends that collectively are driving and exacerbating what we like to call mobile shock.
The future always comes too fast and in the wrong order.
- The advent of cloud-client computing
- The unprecedented pace of mobile technology adoption
- The consumerization of B2B software and the resulting proliferation of B2B SaaS mobile service providers
- The shift in technology spending from CIO to CMO – which has been dramatically accelerated in mobile
The advent of cloud-client computing
The advent of cloud-client computing sets the stage for the mobile fragmentation problem. Peter Levine of Andreessen-Horowitz does a nice job of laying out cloud-client computing and the resulting evolution of the mobile app:
Our mobile devices have become supercomputers in our hand. The processing power and storage capacity of these devices are now 100x more capable than PCs of 20 years ago. History has shown that as processing becomes available, new applications and architectures happily utilize the excess capacity. Enter the new world of cloud-client computing where applications and compute services are executed in a balanced and synchronized fashion between your mobile endpoint and the cloud.
In order to maximize the potential of our handheld supercomputers and provide the best possible experience for users, developers predominately write native applications using Apple’s Xcode or Eclipse/ADT for Android. Peter rightly points out certain consequences of this:
But native apps are a pain: they typically require separate front-end engineers, there is little code shared between apps, and there is no concept of coordination with the back-end (cloud) services. All of this work must be handcrafted on a per app and per OS basis, rendering it costly and error-prone.
For mobile apps, one critical set of capabilities that typically gets handcrafted on a per app and per OS basis are those required to adopt mobile services such as analytics, push notifications/mobile marketing automation, attribution, crash reporting, and monetization. Developers embed each of these services’ software development kits (SDKs) – essentially third party code libraries – in each of their apps in each of their apps’ OS. Integration happens on a point-to-point basis, by writing software code. This is arguably a massive step backward: developers are embedding third party code libraries into their apps, writing and maintaining multiple code bases against those libraries, and ending up having to release the resulting hairball across massively distributed apps and app platforms. The result is that multiple versions of the app and it’s embedded SDKs are in production at any given time.
This is painful for everyone, but especially for enterprises with multiple apps and enterprises with huge install base apps. Developers end up writing direct integration code on a per app per platform basis. This mode of operation results in enterprises sending one of their most critical assets (their data) to various endpoints with little governance around the process.
The advent of cloud-client computing is a perfect example of how sometimes making progress in one area can mean regression in others.
The unprecedented pace of mobile technology adoption
I’ve written about this before and the stats by now are well known. Choose your favorite analyst or Mary Meeker presentation. Mobile adoption is absolutely exploding and quite possibly moving faster than any other technology adoption curve in human history. The future is coming at us at an incredible pace and in true Future Shock fashion, it is happening in the wrong order. Many needed technology infrastructure and technology management capabilities for mobile are being vastly outpaced by the rate of mobile adoption. In addition to lack of enabling technology infrastructures, the demand for mobile software engineering and business human resources far outstrips supply. Mobile apps are like Formula 1 racing cars tearing along a dirt cattle trail because we are not able to build roads fast enough. How much faster could we go if we actually had roads?! This incredible pace also means that nearly every business and technology trend is accelerated in mobile, and both good and bad consequences of the model are significantly exacerbated.
The consumerization of B2B software and the resulting proliferation of B2B SaaS mobile service providers
The consumerization of B2B software is a driving force for many SaaS business models and manifests across multiple dimensions: deployment of consumer technologies in the data center, emphasis on software design, collaboration, and workflow features (e.g. making the adoption and user experience consumer-esque), and the advancement and commodification of key pieces of the technology stack which allows B2B software startup firms to get to a minimally viable product (MVP) quickly and iterate.
So why does this matter for Mobile Shock? One of the results of all this is that B2B mobile service providers have proliferated. You can’t swing an obsolete flip phone without hitting half a dozen mobile analytics, push, or attribution service providers or a mobile ad network. The growth of mobile and the ease of getting a B2B SaaS firm off the ground creates a rapidly innovating and rapidly evolving app ecosystem for mobile app owners. Yesterday’s winners are today’s losers. New and innovative B2B SaaS service offerings for the mobile ecosystem are seemingly springing up weekly. In the vast majority of cases in order to realize their value, you have to incorporate their SDK. And of course, your B2B mobile service providers are not necessarily incentivized to support deployment of their offerings via other means because many of them believe that having their SDK in your app(s) makes them more “sticky.” You’re back to writing, maintaining, and massively distributing software code, much of which exists in third party code libraries that you didn’t even write but are now responsible for because they are in your app.
The shift in technology spending from CIO to CMO – which has been dramatically accelerated in mobile
In 2011, Gartner predicted that within five years marketers would spend more on technology than IT would. This is now becoming reality. However, it has been a reality for enterprise B2C firms in mobile since the beginning. B2C mobile app business objectives are disproportionately driven out of marketing functions: obtain users, engage users, retain users, facilitate commerce with users. As a corollary, many of the most widely adopted SDKs in mobile apps today are deployed in order to support marketing functions. Furthermore, traditional CIO org technology skillsets around mobile first design, architecture, and engineering are incredibly scarce. Talented mobile app architects are more likely to be found in emerging medium and large app development firms such as Bottlerocket, Prolific Interactive, Branding Brand, Willow Tree Apps, Fueled, Pivotal Labs, and others. CMOs are scrambling to follow their customers to mobile and the promise is significant: they are able to engage and service customers anytime anywhere, and in return, they receive an incredibly rich dataset that they can leverage to drive continual product and service improvements. Forward-leaning CMOs and enterprises have understood that with the mobile wave, lack of speed kills. They don’t always have the luxury of going the formal, CIO org-driven technology procurement and management route if it means slowing things down and missing out on acquiring and engaging their customers on mobile where they live. If they can’t service their customers in mobile, someone else will. So in the rush to follow customers to mobile, mobile app technology procurement and ongoing mobile app management activities more often than not have bypassed some or all key CIO org technology planning, implementation, and control functions and gone directly from CMO function to outside technology vendors. Those CIO control functions sure can be cumbersome, right? Sure – but they also provide for critical infrastructure requirements development, application framework standards, data governance, and integrated/reusable architectures. For many B2C enterprises that has gone out the window for mobile apps and the result is a near total lack of standards and the fragmentation of data across a myriad of applications, all of which must be maintained through their lifecycle. CMOs wanted pervasive instrumentation as part of the mobile promise, what they got was pervasive fragmentation, increased total cost of ownership, longer time to market, and increasingly reduced ROI.
Now what?
Alvin Toffler was right – the future is coming too fast, and in the wrong order. Mobile Shock is happening and the first wave has hit the enterprise app development and marketing functions – I haven’t even touched upon the challenge of aligning marketing and app engineering! Each and every app has multiple third party SDKs and data ownership and leverage ends up becoming an enigma. The ability to turn on new marketing and other app services becomes constrained by the app development and release cycle because code has to be written and distributed, diverting valuable development resources from working on actual app features. Understanding and engaging with customers across apps and across app platforms seems a distant reality. And we’re only getting started – as thousands and thousands of new apps get built and B2C enterprises begin to mature from simply adopting mobile to figuring out how to build sustainable businesses off of mobile, the impact of Mobile Shock is further amplified.
So what’s the prescription for Mobile Shock when the future is approaching so rapidly and is so difficult to predict? The good news is that we have the benefit of hindsight on the trends driving Mobile Shock and some well-educated guesses about where we are headed. The mobile platforms wars are arguably over, for now: Apple and Google have won. The time is ripe for mobile app infrastructure technologies that enable businesses to scale out on mobile platforms and provide some degree of app architecture future proofing. The prescription for Mobile Shock, just like Future Shock, is to accept the rapidly evolving reality and address the challenges head on – even if we have to do things in the wrong order.
Starting with highly fragmented, point-to-point SDK integrations and no universal means of app instrumentation and data collection is arguably the wrong order. Mobile shock has given us many mobile service providers, but no real interface layer that provides a level of services abstraction. In a perfect world, the interface layer for mobile service providers would have been introduced before any service provider came to market of course. Properly realized, a services abstraction layer allows businesses to move at the same speed as their app users, service providers, and the underlying platform owners. Reducing the friction and fragility brought about by our increasing fragmentation complexity also fuels ecosystem resiliency and growth.
Mobile shock is a reality today for many enterprises, but it doesn’t have to be. Mobile app services are finally starting to be properly abstracted and businesses are starting to take advantage of nascent mobile service interface layers with great results. Maybe it hasn’t always been in the right order, but when it comes to the next phase of building sustainable businesses on mobile, it’s time to start doing the big things right.
