Choosing the right mobile app architecture
By Nuno Pereira May 11, 2015
- Traditional approaches to app development and delivery are fundamentally inadequate
- 4 questions you must ask when choosing a mobile app architecture for your enterprise
THE idea of mobile application development for the enterprise is rapidly catching on, as mobile apps are now an obvious (and critical) path to both generate revenue and improve the customer experience for today’s modern businesses.
However, churning out mobile apps isn’t really as simple as 1-2-3. According to a study by Opinion Matters, 85% of companies have a mobile backlog of between one and 20 applications, with half having a backlog of between 10 and 20 apps.
Of course, depending on your requirements, you can either opt for off-the-shelf solutions (typically Software-as-a-Service or SaaS) offerings which let you get up and running quickly, but don’t take into account the unique needs, processes and requirements of a business.
Then there’s also the issue of the long-term view for your enterprise mobile apps: How many update cycles are planned? Did you take into account operating system upgrades, or even device updates?
MGI Research suggests that most mobile apps will experience, in a two-year timeframe, at least four major update cycles stemming from operating system and device updates.
This also means that buyers often find themselves having to set aside additional budget every so often to keep up with changes in mobile operating systems and devices, and not to mention feature additions, bug-fixes and tweaks along the way.
According to Forrester Research, the cost of building the first version of a native mobile app is about 35% of the true two-year cost of the app. If you’re developing multiple apps, the overall cost can easily balloon beyond initial estimates.
One way to mitigate headaches such as these is to have a clear understanding of the different mobile application architectures available.
Many organisations that have gone down this path have quickly discovered that traditional approaches to application development and delivery are fundamentally inadequate to keep up with the realities of enterprise mobility.
The use of integrated mobile and web platforms can go a long way in helping solve enterprise mobility problems, while also addressing application development and delivery challenges.
Here are four questions you should be asking when deciding on the right mobile application architecture for your enterprise:
1) Who will use the app?
Organisations build mobile apps for three main groups of people: Customers, partners and employees.
It’s important to note that customer-facing apps usually require more thought and planning around image and branding.
For employee-facing apps, the presentation can typically be simpler, though it is still a critical part of the UX (user experience) that drives adoption.
2) How many screens are needed?
Will the app consist of a single screen with a lot of animations or sounds? A classic example of such an application is a game, or even augmented-reality applications.
Some apps may consist of a combination of screens with standard functionality, and screens with complex user interactions such as animations or sound.
Apps that utilise standard screens are great candidates to be developed with the mobile web in mind, though more specific features such as interactive 3D models would likely necessitate native development simply because the performance requirements are essential.
3) What functions do you really need?
While a good number of device sensor functionalities are now available to mobile web apps built on HTML5 (think camera and geolocation sensors), more specific functions such as the ability to read barcodes usually require native functionality.
In addition, do you need access to custom native functionality? If the functionality required has been implemented by a third party, no sense in reinventing the wheel when you can use a native shell to cut development costs and time.
Of course, if what you need isn’t available out of the box, then investment into a customised solution will be necessary.
4) What will you do to brand, distribute and support the app?
The app discovery process varies depending on the specific mobile operating system i.e. Google Play versus Apple App Store. More often than not, users find apps via their device app store. You can also easily access an app from links sent via email, or shared through social networks.
Branding is obviously necessary for customer-facing apps, but not usually a firm requirement for employee or partner apps.
If branding isn’t an issue, the use of a third-party hybrid shell can help save time and effort required to build (and maintain) your own shell.
Will your development team be required to support devices of varying hardware specifications and performance levels? Older devices may not have the horsepower to support complex user interfaces running in the web browser, so native implementation will have to be considered for those cases.
The same also applies to different operating systems (and by extension, different operating system versions i.e. iOS 7 versus iOS 8), as the cost of native development directly affects overall development cost.
Native, mobile or hybrid
Once you’ve gotten the basics sorted for each app, you should have a clearer idea of which mobile application architecture to consider, whether native, mobile or hybrid apps.
The road to deploying the right set of mobile apps for your enterprise can be a rocky one, but with the right planning and not to mention the right tools, the process can be made much faster, easier and more efficient.
Nuno Pereira is the Asia Pacific director at Atlanta-based enterprise software company OutSystems.
Best practices for easing into enterprise mobility
Enterprise mobile developers stuck in old mindset: Analyst
Developers and the struggles of enterprise mobility
Shadow IT: 80% of employees use unapproved apps at work
For more technology news and the latest updates, follow us on Twitter, LinkedIn or Like us on Facebook.
Author Name :
By commenting below, you agree to abide by our ground rules.