Mobile: The CIO Heartbreaker

Last year, huge investments were made in mobile apps and solutions by companies of all sizes. This trend is continuing to accelerate - but some critical insights are emerging as the apps grow more complex. CIOs stated that, for an enterprise to build a feature-rich, scalable and secure app, roughly 60-80% of the total investment was dedicated to building the “back end”. For those who don’t live and breath mobile apps, this means a majority of the costs are not related to the cool screens and front end development. Instead, a significant portion of the costs are hidden in:

• building an Application Programming Interface (API) layer
• architecturing server infrastructure
• configuring web servers
• populating databases
• implementing middleware
• and writing service logic

Backend Challenges

The backend is what powers the apps that increase our productivity and simplify our lives. Without a well-engineered backend, Google maps would never have the latest traffic. Siri would never learn new answers and bank accounts would not display up-to-the-minute account information. The backend powers real-time features, data and ultimately the “experience” in the apps we love.

Marketing groups (and Chief Marketing Officers most often) ask their IT organization -

“why does it take so long, and so much effort, to build a backend for an enterprise mobile app?”

The answer is often more a factor of an organizations IT history, rather than ability to deliver actual solutions. The last enterprise innovation cycle includes infrastructure from two initiatives, either Service Oriented Architecture (SOA) or Web 2.0. Both initiatives failed to meet some of the fundamental requirements and best practices associated with mobility.

Why SOA fell short for mobility

SOA made organizations think about how to share data with others - a necessary predecessor to mobility. An initial solution to this data problem was often a large investment in Enterprise Service Bus (ESB) software, which created a uniform point of entry to data and logic across all lines of business.

Unfortunately this was done with a vision based on batch process rather than explosive dynamic load, a requirement when millions of users attack the API for real information via mobile. So, many SOA initiatives resulted in very heavy and internally expensive services. These services, when used by mobile clients, slowed down the device and made for an overall negative user experience. Simultaneously, the enterprise servers were rapidly bogged down within the internal infrastructure and created a road-block to normal business operations.

These SOA solutions now look inefficient, monolithic and archaic to the ideally architected mobile backend.

Web 2.0, another miss

Web 2.0 represents the last big enterprise public facing initiative before mobile came fully into view. In this case, a few companies modified their web presence to increase overall feedback and usability. Game changers like Facebook and Google were masters at building a website that didn’t require a whole page refresh - but used technologies like AJAX to load pieces of the User Interface (UI) as needed.

However, over time these AJAX calls have failed to adapt to mobile requirements in several ways:

1. Limited - Most AJAX calls were specifically created to solve a web page user interface feature. Being feature oriented means that it will fail to implement a core reusable business process for a mobile enterprise app.
2. Hidden and proprietary - it’s likely impossible to find documentation on the AJAX calls for others to reuse them.
3. Required statefulness - Web 2.0 was built on monolithic web application servers that managed every users sessions and keep track of where they were in transaction. Many AJAX calls leveraged this state and now are trapped from ever being highly scalable in cloud like infrastructure.
4. Reject cross-site usage - in other words, they are unusable by anyone but the website itself. New mobile apps and partners are restricted from using them.

How is mobile evolving currently?

From these previous initiatives and their shortcomings, mobile enterprise architects have evolved the Application Programming Interface (API) layer. It is now the fundamental communication layer between a backend system and all its possible clients - including mobile devices.

In context, iOS developers generally know little about where the data they use comes from; however, they are quick to consume a well documented API. To developers, APIs serve as standard web calls that either create, update, read, or delete data without an actual web page to support it. Today - general expectations of mobile APIs are,

• Scalable - open to the public and ready for immediate success
• Lightweight - use JSON structures to keep payloads short and readable
• Secure - use encryption, authentication, and check authority
• Smart - enforce best practices of the mobile developer - like paging
• Documented - API should be easily consumed
• Auditable - able to be tracked and available for future analysis

What does this mean for management?

Unfortunately, the reality for CIO’s is that they have no architecture readily available to implement with the above characteristics. At a technical level I most frequently see this evidenced by

• no use of caching in the middle tier
• no readiness for cloud servers to balance the workload
• no sessionless behavior to allow services to run in isolation
• no ability to rapidly develop services and get them into production
• unoptimized or underpowered databases
• databases that fail to handle consistency requirements
• limited or complete lack of any audit trail
• ESB’s that are unable to scale

In an effort to overcome these challenges, CIOs and CTOs are left to rebuild existing architectures or build new. Common strategies for this often result in a new layer named the “Mobile Backend” This mobile backend needs to be scalable enough to handle the highest performance load and flexible enough to run public / hybrid and on premise environments.

Why a Mobile Backend works

A mobile backend drives mobile communication by utilizing cloud practices that leverage front end load balancers to make service calls into a stateless server runtime that can perform data interactions and business logic execution. Originally these services were being written in Java but today we see that workload being transitioned to Node.js, or a cloud friendly languages like Golang. To optimize the loads we see caching strategies involving Reddis or Memcached to reduce hit rates on databases. We also see things like message brokers working to add real time like behaviors using a publish subscribe model. (IE - for chat) Finally we see those same companies providing connectors to the original systems, often through their original SOA calls or ajax calls.

This strategy, although correct, is fraught with risk. Efficiently bringing so many new elements to an infrastructure takes time and skill that typically doesn’t exist internally. Very often companies begin building redundant home grown systems to compensate for better mobility while simultaneously experimenting with their production environment. These new homegrown mobile backends share many implementation characteristics from enterprise to enterprise.

Much like the SOA initiatives of old that transition from home grown solutions to ESB solutions, some organizations have begun to look at middleware as the solution for their mobile backend requirements. Middleware designed to handle this problem effectively allows organizations to simplify their operational costs and mitigate their risks. Ultimately, it also allows them to focus on business objectives like focusing on user experience, productivity and retention.

Takeaways

In all future scenarios, enterprises will either continue to march down the mobility path or simply get left behind. The frustrating part for many companies is that while the fun and glory exists in the visual portion of the mobile app, the real work ahead lies in implementing a backend.

CMO’s will continue to demand a stronger mobile presence focusing on time to market and customer acquisition. They will (correctly) leverage mobile design shop specialists. And finally, they will continue to demand their organization IT provide points of engagement.

Meanwhile, CIO’s will continue to push their organizations down the mobile backend path to meet these new demands. The solutions they choose should be complementing the marketing strategy by focusing on a solution that integrates their current environment, scales to needs beyond today, supports security best practices, and all the while, is readily consumable by their existing IT organization.

The first wave of build your own backend has already started at top companies. Some have had brilliant engineering and are secret success stories. Others have failed, with CIOs readily looking to the marketplace for answers. Today there are backend software offerings in the market working to meet this need (ClearBlade shameless plug here). These offerings have different strengths and vary on things such as pricing, deployment, use of standards, depth of integration and flexibility of implementation.

My prediction - ultimately enterprises will move to mature middleware solutions to solve their mobile challenges, but the CIO will need to act quickly to get educated on the options, find the right solution and make it available to the organization.