DIY Guide to Back-end System Integration for Mobility

Have you ever stayed at a house where you had to reach into the back of the shower stall to turn on the water and got a blast of cold water before you could retreat? This happened to me recently and made me swear before I was able to laugh it off as poor design.

In the world of beautiful apps and websites, our tolerance for poor UI and UX is very low. We just expect things to work, be easy and fast. These expectations have permeated from the consumer world into the enterprise and from millennials to the rest of us.

Designing a great house is not dissimilar to building a great enterprise app, but it is not a job for the average DIY handyman. Fortunately, there are building industry regulations that require us to build a foundation for our home, separate grey water from black water and keep power switches above the reach of babies etc. But there are no such regulations for enterprise apps, building the foundation layer, separating customer data from logistical data and putting key resources within reach.

Which are the best back-end system integration approaches for mobile?

If you have a business process that gives your business a competitive edge, you will want a single mobile app for that business process. This may require an enterprise app with back-end system integration that needs to be built to last and built for scale.

It is important to optimise back-end systems for mobile access because the efficiency gains tend to multiply. Business units are developing a voracious appetite for mobile apps and a sensible, re-usable approach to back-end systems integration will help to ensure that the overheads of each mobile application are minimised.

I have never built a house but my company (Mobile Mentor) builds enterprise apps and we have learned a few things along the way which I am happy to share. With a vertical stack in mind, I have presented a list of 10 considerations ranging from the top of the stack (the mobile app) down through the middleware layers to the back-end integration with existing enterprise systems.

10 Key considerations for Backend Integration

1) Plan for continuous improvement and constant change

Demand driven – Internal users, customers, partners will demand and expect constant evolution of your capabilities and the pace of change will only increase over time. This defines the new parameters of competition where the fast eat the slow. Amazon is the world’s largest retailer but instead of behaving like a big corporation, it performs over 2,000 product releases per day. What can we learn from Amazon?

Insight driven – This is often only gained once a solution is released and used. Users will identify changes, optimisations and enhancements once they start using a solution and often these insights are not available during design and testing. Take note of this and plan for continuous improvement.

OS driven – Apple, Google and Microsoft never sleep. As soon as you have achieved stability with your current version, there will be another major OS update. The rate of change is mobility is much faster as the traditional rate of change in a legacy Windows desktop environment.

Data driven – if your app has hooks to capture performance metrics (log collection/analytics/crash reporting/etc) there will be a ton of data points that show how the app is performing and what your users are really doing, which may be different to what they were designed to do.

Mobile Phone

2) Separate internal and external APIs

APIs become the building blocks that enable developers to assemble, re-arrange and deconstruct mobile apps, web-app and the underlying micro-services. We strongly recommend de-coupling API’s that access your systems and API’s that clients such as mobile apps can access.

“Experience” API’s deliver an experience to a user. They are designed from the outside looking in by defining the user story e.g. “I want to start my shift, see my list of delivery addresses and perform a pre-start check of my vehicle”.

These external / experience APIs can be created and consumed in an agile manner, serving the needs of a mobile app, SaaS application or an external partner.

External / experience APIs also enable the company to embrace the ever-evolving landscape of SaaS applications. Rather than taking a fragmented and siloed approach to SaaS applications, APIs enable companies to integrate SaaS applications to existing processes and swap SaaS vendors as business requirements change.

“System” or “Internal” API’s are those that expose your legacy systems. These API’s are designed to speak in the language of your systems , need to be managed tightly and follow strict a change control process. These API’s are not typically exposed publicly.


3) Choose a cloud mediation layer

Rather than creating point-to-point integration for each app, a cloud mediation layer takes the time and hassle out of the integration work in the long run. Many vendors provide various ‘connectors’ or ‘adaptors’ for popular back-end systems and they may have a web service layer runs in the DMZ to secure the entire infrastructure. The integration between back-end systems and the mediation layer is done only once and can be used again and again.

A good mediation layer will enable developers to build apps that run on different devices, online and offline and provide options for caching and queueing to minimise latency. A good mediation layer will also play nicely with other tools for development, testing, deployment, analytics etc.

Consider IoT, AI, ML and any other leading-edge technologies as dynamic building blocks that will be consumed as-a-service from the leading technology vendors. These need to integrate with your other services so invest the time and effort to choose a good cloud mediation layer.

4) Create RESTful APIs

RESTful web service-based API’s specifically designed for mobile apps are the most desirable approach.

An alternative is SOAP, mainly used for general enterprise integration. Although useful, SOAP API’s can sometimes be a bit heavyweight when it comes to mobile.

A third option is direct database access, however this may cause vendor support issues. If none of the above approaches is feasible there is the possibility of screen scraping from existing web application UIs which can be surprisingly effective if done with the right tools.

5) Treat APIs as products

Ideally APIs are discoverable through an API storefront and make adoption easy for new developers. .

Just like your users think “there’s an app for that”, your developers will think “there’s an API for that” and they will find an existing API internally or externally.

Each APIs would be some supporting documentation, a technical owner and there should be a process to request code changes.

Microsoft Intune

6) Bake security into each layer in the stack

The whole internet address range is scanned by bots and malicious actors multiple times a day to look for vulnerable resources that can be exploited.

Having unprotected external API’s, databases or any other resources poses a significant risk.

The entire stack, especially the internet exposed endpoints, should be build with security in mind.

· Require authentication to make API calls

· Protect your data in transit by leveraging TLS

· Do not store credentials in plain text

· Rely on modern authentication technologies like SAML and oAuth to avoid sending credentials over untrusted networks.

· Enforce authentication limits and account lockouts after multiple unsuccessful login attempts.

Microsoft Intune Management

7) Assemble microservices for standard transactions

Use a microservices architecture to break large applications into lightweight apps that can be scaled horizontally. Microservices deconstructs functionality into separate applications that are loosely coupled by JSON REST APIs. For example, you might have separate Java servlet applications that handles users, items, accounts, feedback and transactions. Each of

those logical functional applications is a microservice – a smaller, independently scalable application that is less complex to develop, update, and deploy.

By definition, each microservice needs to be self-contained. Microservices do not share a data layer and each one has its own database and load balancer. Isolation is a critical component of microservices architecture which means individual microservices require different scaling techniques. Some microservices will receive a small volume of requests, some will receive massive volume. It would be wasteful to provide the same database and CPU resources to all microservice. The most important aspect of implementing a microservices architecture is the extensive use of hooks for debugging and monitoring each new interface.

8) Accept that backend systems change slowly

The average lifecycle of an enterprise system used to be 10 – 20 years but clearly this is changing as enterprises embrace cloud services. However, most enterprises have sunk investments in legacy systems which may be around for many more years and many of these legacy systems probably don’t have modern APIs and web services.

In some cases, these legacy systems may only be accessible through brittle, point-to-point, hard-coded interfaces. These may simply need to be respected and used with caution as they can be expensive to fix when things go wrong.

9) Distribute, configure and revoke enterprise apps centrally

Enterprise apps should be distributed to mobile devices using an EMM (enterprise mobility management) platform. This enables the enterprise to manage the user experience, control multiple versions, performed staggered rollouts and push updates as required. EMM platform can also be used to prevent data leakage between enterprise apps and personal apps and consumer cloud services.

The EMM platform can also apply specific configuration settings to the app as long as you have built AppConfig functionality into the app. AppConfig basically grants you the ability to configure the app remotely as long as you’ve built that functionality into the app. For example, you could have a browser app where you could change the homepage remotely or populate favorites. Or you could send tokens/certificates to the app so it can be used to achieve SSO.

EMM and AppConfig tools enable designers to combine security and safety policies to deliver a dynamic experience based on the posture of the device e.g. present the driver with a proof-of-delivery notice ONLY IF the vehicle is moving at less than X Km/hour AND prevent the driver from taking a screen shot of the inventory manifest.

Backend Integration

10) Collect and analyse data from apps and APIs

The volume of data may be overwhelming for some, but the rich performance data available from apps, API calls, database queries makes enterprise apps a science rather than an art form. Each enterprise app is probably worthy of a dashboard showing you and

the business the fruit of yesterday’s investment and posing the “what-if” questions for tomorrow.


When you are looking to develop enterprise mobile apps, whether outsourced or in-sourced, it is vital that you optimise your back-end for mobile app integration. With a predicted proliferation of enterprise mobile apps that will be needing access to your back-end in the next few years, it will be money and time well spent.

A robust stack of loosely integrated layers will free up developer time to focus on the tasks that deliver business value rather than spending time on backend infrastructure. This is the key to cultivating a Continuous Integration / Continuous Development environment where progress is visible and developers, business analysts and users are working together. And surely this is easier than building a house.

Find our more about our experience with mobile app developement