One mobile platform to rule them all?
Mobile platforms promise to help creating and running mobile apps. Mobile apps connect to the mobile platform, consume services and backends made available by the platform. They are offered by several vendors. For instance, SAP offers SAP mobile services in the SAP Cloud Platform, Oracle has mobile hub. It’s an all-in-one go-to-solution for mobile apps. Oracle Mobile Hub offers a set of platform APIs. These APIs encapsulate the functionality of a defined set of capabilities: storage, offline sync, notifications, location, connectors, etc. SCPms is not much different.
These offerings follow the classic platform approach. That is: they offer a defined set of functionalities the mobile app can use and serve as a central entry point. The idea is that all mobile apps go through the platform. Ideally all mobile apps go through the same instance of the platform. Ideally, a mobile app is not able to connect to any of these services and backends without connecting to the platform first.
This approach offers several benefits:
- Central administration makes it easy to build knowledge and gain insights.
- Developers learn how to code against one platform and reuse their knowledge for a series of apps, lowering development costs.
- Innovation happens together with the platform: updates, upgrades, new features are made available to all apps.
- Unified access to resources as e.g. backend connect to the platform and not to the app.
- Easy enforcement of corporate policies and security.
Via the platform approach companies can manage apps and access by a central tool. Once the developers know how to consume the platform, it is easy for them to develop apps. Learning one SDK allows to focus on what the platform offers and not having to learn the underlying concepts, e.g. push notifications or offline storage. The SDK abstracts, the platform runs it. If this is such a good approach, why write a blog post about it? One problem is that it rarely stays at a central platform. Ideally, you have one for the whole company.
This looks obvious to do and the benefits are easy to understand. Remember that having one platform, if it is down for maintenance or some other issue, all apps are affected. Besides having to manage request from all around the world. It is rather comprehensible to understand that the one central mobile platform approach can reach its limitations fast. You might opt to have one for each country or subsidiary. For multinational companies with subsidiaries this can become even more complicated. What if you have 10 subsidiaries? Do you then run 10 central mobile platforms? What if you have one for each country or region? With 20 countries or 6 regions it is definitely not a central platform.
The one per country approach does not scale very well for true multinational companies even when regions are used. In both cases, the benefit of a central platform is gone. You might use line of business as the separator. This makes sense as each LoB is then able to innovate on the mobile platform in their own speed.
With 5 LoB’s you have 5 mobile platforms. That’s again not a central platform for the company, but at least each LoB has a central platform and can get insights into their portfolio in a central place. The apps are grouped by a functional topic. Many resources are already shared: (functional) knowledge, developers, key persons. It may get worse in case every team gets its own mobile platform. In reality, there is a push from functional areas / teams inside a LoB to be able to run their own mobile apps or platform. Why? Because many times the teams are formed to solve a business problem, and these cross several LoBs. These teams do not work for a single LoB, but for several. The LoB approach limits their ability to innovate on fast speed. If these teams are now using their own mobile platform, you end up having a huge number of mobile platforms running, some with very few mobile apps on them. This is counterproductive to the whole platform approach.
As you can see with above examples, the central approach looks very good on paper. In reality it is very easy and common to have many platforms. Instead of central, it is a de-central platform. That’s when the benefits of a platform approach turn out to be a disadvantage:
- Management effort of several platforms.
- No central insight into apps and usage.
- No single platform to drive innovation.
- Disperse knowledge and hard to manage developers.
- Hard to manage onboarding of new developers and functional teams.
Adding to this is the general problem with platform development: you bind your resources to create solutions for a single product. You link your app development knowledge and success to a platform from a single vendor. You end up developing not mobile apps that help running your business process but developing apps for a platform and have business processes selected for mobile solutions that the platform can support. Wag the dog. Some 8+ years ago, when mobile platforms started to gain traction, rule of thumb was to use a platform when you have at least 3 mobile apps. This number was not selected based on scientific evidence, but because at that time the number was high enough to show companies that they are going to reach this number fast, while at the same time mobile apps were still rare. A company was maybe just using one or two apps, or even none.
With the platform approach coming from a trend almost a decade ago, is this still the right approach for cloud native architecture and modern mobile apps? If the vendor is investing and innovating the platform, you get great benefit by following this approach. In case the vendor halts innovation, removes functionality or even the product itself, you get into trouble. SAP mobile customers are currently partly experiencing what this means. SAP decided to pull the plug on the hybrid SDK Kapsel for their mobile platform. This takes away the pillar of hybrid app development. This hurts even more as SAP Fiori apps are HTML5 apps and it was very simple to transform them into hybrid apps. If you follow SAP’s decision and go for native app development or low code with their MDK, you are still good and benefiting greatly from SAP mobile investment. And when SAP decides to stop investing into the native Fiori SDK for iOS and Android? Or decides that low code isn’t the way to code mobile apps? Remember: MDK is not the first approach by SAP to offer a low code tool. Of course, this is not just SAP. Those that bought into Microsoft Azure mobile platform face the same problem with transition to Azure app service. The path is going from an all-in SDK to use Azure services dedicated for a specific purpose. For App Center, the push functionality is replaced by Notification Hubs, same procedure applies for authentication and storage.
Is there a better way to deliver mobile apps than using a central mobile platform? It is not possible to decide this in a generic way. As always, it depends on the situation. For companies that can run a single central mobile platform, that can strictly follow the strategy the vendor is communicating, that do not use any other functionality than the one provided by the platform: go for it. Everybody else needs to take a closer look and decide if the model works for them. In case you have cross functional teams that span two or more LoBs, regions, companies, with the need to innovate and integrate services that are not core to the mobile platform it is unlikely to get benefit by using a traditional mobile platform from a single vendor.
In my next blog I’ll describe an architecture approach for modern mobile apps.