Skip to content

Happy Mobile New Year


It’s a new year and therefore it’s time to throw some rapid-fire mobile architecture concepts at you to help improve your mobile enterprise systems.


  • For starters, developers and IT Pros involved in mobility need to start thinking holistically about backend systems, data transports, and mobile endpoints.  Working in the mobile enterprise space doesn’t mean you just get to be a “device guy.”  Remember, your CIO wants to empower her employees by moving data from any backend system out to any device.
  • Here’s my obligatory statement on keeping things simple.  Large enterprise mobile systems will get complicated enough on their own without you contributing to the chaos.
  • Take the idea of Mobile SOA seriously and wrap your enterprise in a Web API.  Your various backend ERP, CRM, and custom systems use a variety of proprietary wire protocols to communicate.  You need to make all those backend systems “mobile friendly” by having them all speak a device-agnostic language.  You all know I’ve been a REST guy for more than a decade so it’s no surprise that I want you to map those proprietary APIs to RESTful APIs.  REST is lighter then SOAP and works with all mobile devices.  For your coarse-grained APIs that send larger payloads of information, make sure to serialize that data as JSON.  JSON is lighter than XML and works with all mobile devices.  The other litmus test here is around simplicity.  If a webpage with JavaScript can consume your REST/JSON API without needing an SDK to interpret your wire-protocol, then native apps will find your API simpler to work with than a system that requires an SDK.  Remember, you’re not just building this API for mobile devices.  You’re building it for developers.  If it’s not super-simple to work with, they may not use it.
  • Some backend systems that you’re building Web APIs for are designed for serious web-scale, but most are not.  If a particular backend package already has the performance and scalability to handle millions of devices, then have your middleware Web API servers sit directly in front of them and map REST API calls directly to their proprietary APIs.  For the the majority of backend systems that are wholly incapable  of handling an onslaught of millions of devices, you need to give them some help.  You’ll need to create a server facade in front of them via a database server that includes EAI adapter capabilities along with the ability to scale out via replication.  You’ll use an adapter designed specifically to interface with the backend system in question to prefetch data from the proprietary APIs and put that data in staging tables in the database.  You’ll then shard this database via replication to scale either complete databases, tables, or parts of tables to n number of “shared-nothing” database nodes on different servers.  In this scenario, your middleware Web API servers will make calls to the various database shards to return cached data to mobile devices in order to solve your scalability problem for backend systems that need help in this department.
  • Common sense tells us that if you make your backend systems faster, then the user experience on the mobile devices will improve because users won’t be waiting around for data to arrive to fill their screen.  The first and easiest thing I want you to do is switch all your spinning hard drives to solid state drives (SSDs).  Moving all your backend systems, database servers, middleware servers, and web servers to lightning-fast SSDs will instantly boost the performance of your entire system without writing or changing a line of code.  This is a no-brainer.  The next thing I want you to do is take better advantage of cheap RAM and in-memory operations.  I want every mapped API call between your middleware Web API servers and backend systems to be cached in-memory.  If you’re using a server facade in front of backend systems, ensure the EAI/ETL capabilities of the database support in-memory data movement operations.  Likewise, I want you to use database servers that support in-memory OLTP.  All the Web API calls between your mobile devices and the middleware servers also need to be cached in-memory as well.  Last but not least, the native and web apps on your mobile devices need to cache data offline in a local data store so that users can keep working without needing to constantly call your Web APIs.
  • Implement a lightweight Enterprise Mobility Management (EMM) system in your organization.  It needs to provide things like an enterprise app store, security policy enforcement, and things to make an employee’s life easier like the simple provisioning of Wi-Fi, VPN, and email profiles.  In order for mobile apps to access the Web API you’ve built, your EMM should also support a secure gateway to access internal corporate servers via single sign-on (SSO).
  • Finally, keep investigating HTML5.  It’s the world’s most important shared technology that isn’t owned by any one company.  It works with the browsers on every mobile device and makes things like app deployment and updating easier than equivalent processes with native apps.  It supports offline operations and even includes two options of local data storage.  Web pages no longer submit/post data to themselves or other pages but use JavaScript instead.  Mobile web apps can make AJAX calls to you Web API and easily work with the JSON data that’s returned.  Mobile browsers keep getting faster and use optimizations like hardware acceleration and JIT-compiling of JavaScript to blur the lines with native apps.

Happy New Year!

Sharing my knowledge and helping others never stops, so connect with me on my blog at , follow me on Twitter at and on LinkedIn at

Sign Up for my Newsletter and get a FREE Chapter of “Mobile Strategies for Business!”

[mc4wp_form id=”5975″]

2 thoughts on “Happy Mobile New Year”

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.