Wednesday, August 19, 2015

What Has Happened to Enterprise Mobility - An Update

My colleague and mobile expert Peter Rogers, shares his insights into the fast changing world of enterprise mobility, and his fondness for acronyms with us today.  Please add your thoughts and comments!  Enjoy!

Peter Rogers
Cognizant Mobile Expert
Four years ago, if you asked me for recommendations on the best solution for a mobile application on multiple platforms, I would have doubtless told you to use a MEAP (Mobile Enterprise Application Platform) or a MCAP (Mobile Consumer Application Platform) depending on the business case. Three years ago, it would have been a MADP (Mobile Application Development Platform)  solution because the two terms merged. Two years ago, I probably would have told you that the merging of the terms was a bad idea and to use an MCAP solution with an BaaS (Backend as a Service). Last year, I would have told you to use an MCAP solution, pure native or an HTML5 based solution combined with a Mobile App Platform as a Service / Mobile Platform as a Service that combined API Gateway functionality. You can see that things are starting to get a bit nebulous here in the terminology stakes and the definitions, boundaries and business cases are looking a bit wobbly. So the burning question is what would I tell you this year?

In the last six months around 5 major events have taken place defining the new enterprise mobile space.
  1. The first is the introduction of consumer grade wearable devices has driven the IoT market and given developers opportunities to look into new non-mobile propositions such as: Watch Apps; Augmented Reality Glasses Apps; Fitness Bands; and Virtual Reality Apps. This has not proved to be a massive disruption in the marketplace, yet but it has provided a non-Mobile-First mindset. It kind of shows us that the whole term "Mobile-First" is too rooted in a single technology. We should really be saying "Client-First" or "Device-First". This means that we design a solution around device-specific client-rendering capabilities as opposed to just rendering everything on the server. I would argue that the current MVW (Model View Whatever) frameworks in the web space (Angular, Meteor, React, Polymer, etc.) are probably closer to the money.  Angular in particular due to its focus on testing and Angular 2 on web components. We are talking about client-side templates that offer device-specific rendering and pulling the data we need from secured disparate APIs.
  2. The second major thing that has happened is a move away from the term "Mobile-First" into the more general term "Digital". Traditionally reserved for marketing focused activities the term Digital now seems to encompass Mobile, Web and IoT. Companies are now grouping together their teams to form Digital Centres and the results are certainly impressive.
  3. The third major thing is the stability of mobile platform vendors. I was quite shocked this week to learn that one of my favourite MBaaS (Mobile Backend as a Service) vendors had closed for business. I look around at recent acquisitions and struggling fortunes of some of the MADP/MBaaS vendors and I have to pose the question of what happens if they go under or their new owner completely changes the technology direction. Combined with the continued rise of HTML 5 and the imminent arrival of ECMAScript 6 / 2015 then you seriously have to weigh up your development options these days. Most modern Web Apps can accomplish the same goal as a mobile app without a download. A prime example being the Google Maps website.
  4. The fourth is the rise of Test Driven Development. The days of "Build an App in 24 hours" are definitely gone. Most companies with a few years experience of mobile development are now asking for: test driven development (or behaviour driven development); unit tests with 80-90% code coverage; some form of automation for testing and deployment; and at least consideration of moving towards continual integration / continual development / continual deployment. Mobile, Web and IoT applications need to be supported by comprehensive testing, diagnostics, debugging and other similar tool sets.
  5. The fifth is Apple continuing to change the goal posts to make cross platform development effectively more difficult. WKWebView broke Cordova last year and it will be interesting to see how the new iOS 9 Safari View Controller works in practise. iOS 9 introduces App Slicing, Bitcode Submissions and on-demand resource loading. It also adds a great deal of demand for on-device system testing with its new multi-tasking capabilities on tablets.
Taking all this into the picture then I am going to make some bold predictions for 2016 and get ahead of the curve here:
  1. Mobile-First is dead. The term Digital shall refer to Mobile, Web and IoT henceforth.
  2. Mobile-First investments will dry up. Instead we will see more generic Digital Integration Platforms that offer Client-First / Device-First solutions across the proliferation of devices from watches to virtual reality. These shall include more generic PaaS (Platform as a Service) solutions (Amazon, Heroku, etc.) and API Gateways with device specific adaptors. Flexible integration with diverse devices and virtualisation of portable server-side environments will be the key, as opposed to targeted device specific solutions.
  3. Developers will increasingly turn to pure native or pure HTML5 solutions due to increased demands of UX and the diversity of mobile operating systems. iOS 9 will prove a major turning point in this direction.
  4. Testing and traditional software practices will finally become mandatory in the mobile, web and IoT spaces. 'Write an App in 24 hours' and 'Cowboy Coding' will not fly anymore in this day and age, and digital work will move to more professional outfits as a result.
  5. Re-usable components shall become exceptionally powerful with the arrival of Web Components and many companies juggling multiple mobile projects at once (as opposed to just one, two or three projects last year). The traditional arguments around expiration and failed maintenance of re-usable components shall be expunged using Flow Based Programming architectures (more on that one in a bit).
So what was that "Flow Based Programming" architecture comment that I just threw out there? A man by the name of Paul Morrison decided it would be a good idea to invent a new way to construct computer programs. It's called FBP (flow-based programming).

FBP defines applications as networks of 'black box' processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.

This means that we can construct software programs entirely out of reusable components. We can also use real-time swapping of expired components from an online component repository that is actually kept up to date. The main problem with reusable components is that swapping them in and out proves too difficult, component maintenance, and nobody communicates their progress, feature set or release date in time to be used in projects. If we look at the movement towards component based models then FBP provides us with visual tools (that are great for business analysts, architects and developers) for constructing pipelines of components that can be dynamically altered using simple visual tools. Throw in developer collaboration tools based around program management - to get the component developers and the project / program managers talking and the components can actually be ready in time for upcoming projects.

One company who are probably the closest to this in the mobile space are Mendix. They offer a visual application designer tool that can be used by business analysts and architects. Please note this is slightly different from a typical WYSIWYG tool because this is modelling business processes as opposed to visual artifacts.

The current defacto implementation actually lives in the web space though and is called NoFlo ( This comes with visual application design tools and a rich set of components that can be swapped in and out. Just recently NoFlo again became popular after a Kickstarter fund to upgrade the solution produced Flowhub ( My only stipulation is that the output from a visual FBP tool must offer access to the source code. One of the major limitations of MADP are the lock down to certain customizable widgets or UI components. To offer truly world class UX then a developer needs to be able to have full access to the source code to implement the best native UI the design team can imagine.

Why do I think visual FBP tools are the future? If you can look at the rise of pure native or pure web solutions and their movement towards reusable components and the increasing diversity of Apple and Android platforms then the cost of MADP maintenance is going to be too high and the lack of reusable component integration is going to be too limiting.

You could of course argue that the old operating systems are moving out so the cost of maintenance is stabilising. The problem is that the new operating systems are offering very diverse new capabilities and features like multi-tasking place an increased demand in on-device system testing and diagnostics. Likewise you could argue that native component libraries can be wrapped or MADP specific component libraries used, but this is never as simple as it sounds in practise. Its clearly missing that ease of use that FBP offers.

I am currently leaning towards a pure native / pure web solution with a highly configurable set of reusable components using FBP that includes software collaboration tools allowing component developers and project / program managers to work together across a whole enterprise. I would also include APIs in the solution so that subscription models for various APIs can be included in the visual design along with traditional components. Notably MuleSoft (who acquired ProgrammableWeb) are probably closest in the market to the successful monetization of APIs.

I think given around $5 million  I could probably build the perfect Digital Integration Platform using: visual FBP; re-usable components; API monetization; device-first rendering techniques; diverse device integration; environment virtualisation; and a native or ECMAScript 6/2015 core. It would, however, be completely different to anything that came before it because it would not be mobile-first and it would not be cross-platform. That is not something I would have said before the last 6 months to answer my original question.

Kevin Benedict
Writer, Speaker, Senior Analyst
The Center for the Future of Work, Cognizant
View my profile on LinkedIn
Read more at Future of Work
Learn about mobile strategies at
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.