Finally, in 2016, it’s safe to say that the majority of enterprises have at least begun their Digital Transformation journey. Albeit some companies have started slowly by simply completing application virtualization processes for their data centers, while others have moved more expeditiously to modify or rewrite their web apps for use on iPhones and iPads. Then there are the trailblazers: the companies that have chosen a mobile app development platform (MADP) and started building apps from scratch.
The latter, unfortunately, only makes up a minority of the world’s largest organizations. This reality exists because the platform selection decision – especially for those opting for a Rapid Mobile Application Development (RMAD) solution – is often incorrectly perceived as complex and filled with mixed messages.
For example, one of our competitors and fellow RMAD vendor, Capriza, talk about delivering outcomes in minutes. While most B2B buyers know the difference between marketing and reality, there is some merit in a tool that can quickly deliver a simple mobile workflow. Think about an app that approves PTO requests. There are tools that are aimed at just this kind of application or simple workflow.
Some people say that if something sounds just too good to be true, then it probably is. This decades old adage holds especially true when considering an RMAD solution based on the messaging in which companies choose to use.
To assess the risk of making a purchase that sounds too good to be true, buyers of RMAD solutions must ask 3 simple questions:
- Is the workflow you need to mobilize in one application or does it involve multiple backend applications?
- What is the source application for these workflows? Does it even exist?
- Do you need to mobile enable simple new-web applications or does your use case involve old-web, legacy Win32/.NET?
For those that don’t know, RMAD tools (also referred to as “App Refactoring” or “App Transformation”) rely on leveraging existing applications. This is of tremendous benefit because it eliminates the need to rewrite business logic for mobile apps, making them simple to re-use. The problem, however, is that most enterprises have many types of existing applications; Win32 apps (VB, Lotus Notes), custom web apps (think .NET), and of course modern and legacy web applications and in some cases, old legacy “green screens,”
Therefore, choosing a solution that has the inherent functionality to support ANY type of existing application – so you can extract the needed business logic – is essential.
But what if additional data or logic does not exist in any of these apps? Remember, RMAD is not just about leveraging an existing application or workflow and extending it to mobile; but rather, it’s about creating a mobile first workflow, specific to the individual use case. This means that that the ability to connect to other data sources through REST or databases directly is needed.
A Use Case from the Airline Industry
I was talking to a customer in the airline industry a few weeks ago who thought they had a pretty simple use case: take an existing web-based customer service application and extending it out to mobile users on iPads.
However, once we assessed the workflow in depth, we determined that the app would be bringing together both data and logic from multiple backend applications, including their public facing consumer website (if you’ve been stuck in line at a terminal gate, you can imagine the use case for yourself!). Thus, the resulting mobile app would be federating multiple different data sources and applications. Keep this in mind when evaluating RMAD solutions, as it is not just about 1-1mapping of old to new.
Some argue that if an RMAD tool had all of the features listed above, then it wouldn’t really be just a tool. Those people are correct. In this scenario, what you would have is a platform to transform your existing systems of record or to build net new, mobile-first apps with, one that does not require an army of Swift or Java developers to recreate existing processes and business logic.