part of blogseries
Why cloud business applications will change your custom build application development
A lot of custom build application development in organizations is organized around applications or development skills. But for cloud development, this should be changed. In part 1, I explained why cloud vendors want you and organizations to think about custom build applications development on a cloud platform. With the move to the cloud, organizations should become more agile, can adopt innovations faster, can control project cost by starting small and scale up fast so they will have more freedom to implement own practices to support their digital transformation. I explained the freedom of program language development and how this will influence custom development within organizations in part 2. Within organizations, often own practice is implemented with custom build application. This part will focus on the impact of freedom of user interface devices.
Traditional Business Applications
In ‘traditional’ business applications, the user interfaces (UI) are strongly coupled to the business logic. Most UI and business logic is written in one code line and only available for device-specific UI frontends. This means that these applications are stuck in their existing UIs and not agile enough. This restricts the possibility to personalize and simplify the UI and prevent adding innovative capabilities.
For business applications, with a cloud mindset, the UI logic is decoupled from business logic. Business logic is provided as an API and multiple UIs can be built on top of the same reused logic. This makes it for software vendors possible to build user interfaces with the end-users in mind. And when they do not fit, the customer can build their own.
Multiple Device Types
Nowadays to fulfill a business process, customers need user interfaces for different device types, like desktop, laptop, tablet, phone, wearables like watches, glasses and clothing and edge computing devices for IoT and home automation without changing the business logic behind. Based on the device type, they need to adapt device-specific UI features to determine needed information automatically by using sensors. The user interfaces can be simplified even more. The requested information from an end-user can be minimized by automated enrichment of device information with cloud business services. This automated determination of requested data can be hidden from the end-user in the user interface.
Cloud business services will become smarter in time by using machine learning and artificial intelligence. In the beginning, these smart business services will advise the end-user with proposed values, but over time, they will hide these values in the user interface so they can execute the process without user interaction at all.
3rd generation web application
The many different flavors of device types and devices force a lot of cloud vendors to choose 3rd generation web application called HTML5 to support their UI in a modern browser. HTML5 technologies are based on open standards. The application is based on one web page, which is dynamically modified at runtime based on templates, data, scripting, stylesheets, and assets. The browser will collect all the pieces necessary for the current screen and will request the server for additional pieces when the end-user navigates through the application. These html5 standards are packaged in frameworks like SAP UI5 & Open UI5, Google Angular, Facebook React and Vue, to speed up and simplify the development of business applications.
The approach of 3rd generation web applications will fulfill most of the requirements for business applications in the cloud. It runs in a browser, will make use of open standards and is supported by most device types. But there are some cases where this will not fit.
As mentioned before, you want to simplify the user interface for the end-user by making use of device-specific features. This can be done by running the HTML5 application in a container as a native application. This so-called hybrid container acts as a browser for the HTML5 code, which adds native device capabilities to the application. As mentioned before the html5 application is dynamically built at runtime. So, if it can recognize the hybrid container, it can make use of the native features to collect the data and hide some fields on the screen or change even the screen flow.
But for security reasons and lack of openness of the device, not all features are available in a hybrid container. Some device types don’t have a browser or hybrid container support at all, like wearables. And in some cases, the latency of the network or latency of the interaction with the screen is that important that HTML5 or Hybrid applications will not fit.
In all these cases you need to build your application natively in the supported programming languages, available libraries, and capabilities of this specific device. The right to access device-specific capabilities, like sensors, native applications, and communication channels through well-documented API libraries are key values of native applications, but applications have to be built multiple times to support different device types.
This freedom of user interface devices changed the way of UI development completely. Some companies changed their device management to a bring your own device (BYOD) policy. This is only manageable for generic HTML5 supported devices and applications. For innovative HTML5 applications and hybrid or native frontends, it’s better to have guidelines which describe which browsers and devices will be supported. Additional guidelines should describe when applications should be built in HTML5, as a hybrid application or as a native application.
Freedom of user interface devices is one of the key drivers for custom build application development in the digital transformation of an organization.
The original blogpost of the blog series can be found here.