The key questions CIOs will have about rapid mobile app development – and the answers
With many core IT functions either becoming a commodity or being outsourced to the cloud, the job of the CIO is quickly evolving. It has become a much more people-centric role as suggested by the recently published 2016 Accenture Technology Vision report claims that the business world is in a state of “digital culture shock.”
The abundance of technology available, on its own, hasn’t helped technology leaders harness it for positive material impact to their business. The trick, the report asserts, is to focus on people first: “Winners will create corporate cultures where technology empowers people to evolve, adapt, and drive change.”
Many CIOs perceive enterprise mobility as an opportunity for driving innovation in their company, and it has steadily ascended to the top of the list of technology investment priorities. But simply throwing more technology at a user population that is already overwhelmed has not been paying dividends.
So to “go big”, CIOs are having to think small. People are demanding lightning fast access to the right data in a very personal way. Gone are the days of monolithic apps that are everything to everyone. A good CIO has to create a machine that makes incremental gains quickly and with scale.
The concept of developing many small, one to two function enterprise apps personalised for each user’s job is new to most IT departments. Most are unprepared for the task in both concept and ability to execute. This backlog of app requests has driven the IT market to seek out faster, simpler ways to create mobile apps for employees. Thus, rapid mobile app development (RMAD) was born.
Rapid mobile app development is defined as “the use of code-free programming tools to speed the process of creating applications for mobile platforms.” CIOs, however, are reviewing these new RMAD tools with a healthy dose of skepticism. Before embarking on a RMAD implementation, CIOs should make sure their bases are covered in terms of strategy, security and people – and with three questions every CIO should ask before partnering with a RMAD vendor.
We need to protect our internal systems. How can this help maintain that confidence that my data is protected?
RMAD is supposed to make developing apps easier, and that means being able to efficiently scale security as well as app creation. If an RMAD solution does not have built-in security for all apps created with the platform, security risks compound with the release of each new app.
As with any tool created to access enterprise data, an RMAD platform should use a closed security approach. A closed security approach ensures that only bits and pieces relevant to that person’s job will be accessible in the app’s user experience. Other factors that increase the security credibility of an RMAD platform include a metadata-driven data model, and the ability to keep data stored in the on premise enterprise and in the cloud rather than directly on the device.
We want to develop apps in-house and I already have a large team of enterprise developers. What’s the point?
RMAD’s primary goal is to accelerate development by removing the expenses and productivity hurdles associated with coding. However, for enterprises with skilled developers, they will still desire complete and powerful customisation of the app on both the back-end and front-end.
In keeping with the theme of empowering employees to innovate, their desires shouldn’t be ignored. RMAD platforms should be able to enable quicker creation of apps, but also have the flexibility and open architecture to integrate with standards-based approaches. It is unlikely that RMAD will cannibalise all development in an enterprise. Rather, it should be viewed as a supplemental tool to help tackle the app backlog, increasing the pool of available talent that can create apps.
I don’t want to buy a new strategic platform every year as different devices proliferate. How does RMAD prepare me for future technologies and device types?
When thinking about device fragmentation, it’s hard not to think about the early days of Android. Due to its open architecture, hundreds of versions of the Android OS quickly multiplied on hundreds of different devices types with different screens, form factors and input capabilities. This was just a small phenomenon compared to the the coming storm of the Internet of Things.
Though no RMAD platform may be truly “future proof,” there are characteristics to look out for that can help indicate its scalability in the future. For example, if an RMAD generates code, how is that code managed? All that new code may lead to a larger maintenance obligation in the future. Additionally, how do users gain access from different devices? Unified endpoint management, for instance, goes a long way in managing mobility in a world where laptops are still as relevant as other mobile devices.
CIOs interested in RMAD must ask the tough questions to ensure selection of the right technology partner. More importantly, the toughest question will be the question the CIO will have to ask him or herself: am I enabling my people with strategic tools to position them as innovators in the company, using the existing resources we have today?
Editor's note: Catavolt is hosting a webinar on June 16 entitled 'Tough Questions from the CIO: Rapid Mobile App Development'. You can register for your place here.
Interested in hearing industry leaders discuss subjects like this and sharing their use-cases? Attend the co-located IoT Tech Expo, Blockchain Expo, AI & Big Data Expo and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam and explore the future of enterprise technology.
- » Gartner CIO survey: EMEA organisations getting to grips with digital but remain vulnerable
- » Using AI to secure the modern world – where enterprises are particularly vulnerable
- » Samsung launches Galaxy enterprise edition with UK focus
- » Why improving endpoint security needs to be a primary enterprise goal in 2020
- » How the CIO can win over the most tech-resistant and tech-reluctant employees