If the web was the disruptive technology of 20 years ago, mobile is the equivalent today. But while novelty means mobile is ripe for innovation, it also means that mobile is still chaotic and looking for definition.
Take application development. Many apps require very similar or identical APIs for universal functions, such as connecting to the back-end in an organisation. But because of the lack of coordination across the industry, the same API or app feature ends up being developed again and again by different developers.
"I was recently talking to financial services executives and asked them what they did for mobile; they built it all themselves," Cathal McGloin, vice president of mobile platforms at Red Hat, former CEO of FeedHenry which Red Hat acquired last year.
"Now the top three or four banks have all built their own solution to manage the back-end. But two years down the road, they’re going to be supporting and maintaining this proprietary software.
"Because mobile crept into the enterprise, everybody just did their own thing and there were no standards. In the same way, when the web came out, there were no standard products for, say, web servers and everybody built their own."
According to McGloin, this problem can be solved by what he and Red Hat call mobile back-end-as-a-service (MBaas).
"Eventually over time, standards emerged [for the web]. We think the same will happen with mobile. There were initially no standard architectures for the enterprise because mobile came from the consumer world. So everybody was building their own solution for mobiles to connect to back-end systems.
Content from our partners
"That was great for one or two apps, but as people got to 20 or 100 apps, they found they needed a more efficient way of managing these things and a more efficient way of sharing problems that had been solved in one app so the solutions could be used in other apps.
"That’s the role, I think, of mobile-back-end as a service. It’s a set of features that have been solved that make it easier for client-side developers to build on.
"Just as the web was like the Wild West when it started and we now have standard web architectures, mobile is a little bit like the Wild West at the moment but we will eventually have standard architectures there."
McGloin describes several areas where these standards could be applied.
"Push notifications have been solved once; people don’t need to rebuild push notifications. Data sync occurs again and again across industries; that’s a good mobile back end-as-a-service.
"The two biggest barriers we hear to app development are always data security and back-end integration. They are the two things that keep popping up and the barrier to growing from ten apps to 100 apps.
"I think on the security side there is a lot of work being done and to be done in providing more secure connections to the back-end systems and providing encryption on the device. Encryption is a good MBaaS API; ensuring the data on the device and in transit is encrypted and integration to the back-end is safe. That’s a good one we’ll see.
"In addition, standard integrations to the main products like Salesforce are good basic APIs to have, as well as single sign-ons and access to cloud services.
"So there’s a whole range of these things. If the mobile developer knows that these features exist, they can build and innovate much faster and cheaper on those devices for the client-side.
"That’s what mobile back-end will become: part of the reference architecture for how good mobile is done."
McGloin stresses that flexibility will be a key part of these standards, particularly in security.
"The problem we have is that these devices are on the public internet, accessing devices on a private intranet that we thought never need to be exposed to the public internet.
"One customer said he wants the data on the mobile device to be shared with two apps. Let’s say I have a big file that one app is using and I have a second app that has the same kind of data; I want to be able to allow the two apps to talk to the same data.
"I have another company saying that they want no apps to talk to each other, with each one containerised, so that personal apps can’t access proprietary data. There are two different requirements both conflicting. At the end of the day, what it comes down to is how a particular company uses that or wants to use it.
"You can do so much with the devices to reinvent business processes that it could be customised for each company. The way to do that is to set up standards and architectures that are capable of being flexible and dealing with security."
Certainly this standards approach will be a boon for developers, who will be able to innovate on top of these standard frameworks to build apps more quickly and with less investment. But who will lose out from this approach?
"I think the people that are losing out are the traditional proprietary software companies," says McGloin. "That’s evident from a lack of growth in those companies."
"The world is very definitely moving away from wanting to spend hundreds of millions on proprietary software and tens of millions on support and maintenance. Open source is more cost-effective and more standards-based.
"The losers are proprietary software companies, the winners are those that adopt open source and build for the cloud.
"There’s a general move from buying software to buying a service that software gives but not having to operate and maintain the software."
