Construction principles for the IT architect (11) Device-independent development

The desire from the business architecture has consequences for a number of choices to be made in software development (in addition to choices about device management, infrastructure, security and updates, knowledge at the helpdesk, etc.). For example, a choice is needed about which operating systems should be supported (derived from the devices – also known as terminal devices or user devices – for which the functionality must be used). Of course, as an organization you can choose to only support Microsoft Windows as an OS/platform, but in practice you can't escape iOS and Android because the Windows smartphone and tablet are simply not the market leader. Being able to support multiple platforms or ecosystems is therefore becoming a requirement. The choice for device-independent working means; working platform-independent.

Another important aspect is the design of the screens (UI and UX). The screen size of different devices differs, so how can you scale them by device without endless scrolling and zooming?

If device-independent means that your platform must be able to operate independently, then the consequence is that you have to develop the functionalities for each allowed platform. This is where the desire to be able to develop platform independently comes from, otherwise you have to set up multiple development lanes.

The good thing about cross-platform development is that developers can reduce development time by writing code once that can be used for multiple platforms. You only have to develop once; The code is reusable "cross platform"!

It is therefore a form of decoupling between software and platform.

One solution is to choose a development framework that allows users to write applications in a dynamic programming language (the most popular is Javascript, although many frameworks also support Ruby or Python). With a dynamic programming language, the frameworks will compile with the libraries of a specific platform and produce an application (the so-called "native app") for each platform that the developer has chosen. For deployment (app store), testing and management, you still need to double the time.

Another solution is to opt for a "web app". A web app works in any browser, regardless of platform, so you only need to develop, test, and deploy it once. Of course, the web app must be optimized for the different devices on which it will be used. A good responsive design is crucial for a good user experience and that can also take considerable development time. In addition, you have to make sure that the web app is independent of the browser used and does not require any plug-ins, otherwise the end user will have to install something.

A variant of the web app is the use of a secure web environment such as Citrix to make the application available.

Nowadays, an intermediate variant is also emerging; the hybrid app. You can download this app from the App store, but the basis for a hybrid app is a web app, which is then made suitable for the desired operating systems. The choice between these three ways of efficient development again depends on whether the mobile device requires a "native app" in terms of function or not.

With specific interaction between the OS/device and the software, you often can't avoid a native app. Think of using the sensors or specific buttons of the device and, for example, push notifications.  This works differently for each device and platform, which necessitates that the software is also made specific. The big difference between native and web apps is that a native app speaks the language of the phone perfectly. A native app is therefore often faster, more efficient and feels better. If device-specific hardware, user-friendliness and speed are important, choose native. The requirement to be able to continue working offline, for example, also leads to native. After all, a web app only works if you have an internet connection!

The biggest advantage of a web app is that it is easy to access. This is because the user does not have to download and install the app first. In addition, the development time is often shorter and the costs are therefore often lower. In addition, a web app does not have to be approved by an Apple or Google play store, which involves extra work and takes more time. An update will be instantaneous. Finally, with a web app, there is also no data storage on the device, which can be an advantage.

The hybrid app is somewhere in between and broadens the options.

As an IT architect there are therefore a lot of considerations to be made when choosing the possible solutions. To this end, the Netherlands government has written a handy assessment framework that you can find here.

1. Meaningless identity designation, read here.
2. Decoupling points for complexity reduction and flexibility, maximizing independence of components, read here.
3. Language consistency, read here.
4. Clear distribution of responsibilities and functional separation for administration, read here.
5. Delegating decision-making authority as low as possible, read here.
6. Detaching authorization from identification/authentication, read here.
7. Single registration of master data, read here.
8. Separating data and metadata in storage and processing, read here.
9. Applying standard patterns without deviations, read here.
10. Separating application function from data storage, read here.
11. Device-independent development, read here.