Choosing iPad or browser at RiskChallenger

Will you go for a web application, Android, iPad or Windows after all? Having chosen a platform, you need to start thinking about how to build your system. How do you build it? How flexible do you want to be? Where do you store all your data? You not only have to think about functionality and interface, but also about the technology you use.

Developing an app or website requires important choices.‍

When RiskChallenger was developed in 2016, the decision was made to develop an iPad-only app with the idea that this platform exuded security. The app exuded this, but this way of developing it also had a major limitation. The app could only be used on an iPad and not everyone has one. Quickly opening your laptop and getting started was out of the question. What we want is that everyone, always can use RiskChallenger. So it should work on both Windows and Apple and also on laptops and tablets. In this blog, I will try to explain simply how we developed the current application from the iPad application, what choices we made and the structure of our applications.

Browser choice

So the app for iPad alone was not deployable enough. So what kind of application can we make? We can roughly distinguish 2 types of applications: native and web. A native application is developed specifically for 1 platform such as iOS, Android, macOS or Windows, for example. Web applications are developed to work as a website in a browser. Native applications often feel faster and are better integrated with the device than web applications. However, developing a native application is more expensive as it has to be done separately for each platform, while a web application works on any platform with a browser.  

We would like RiskChallenger to work on all types of computers and tablets. At the same time, we do not have unlimited development capacity to quickly develop software for many different platforms. For these reasons, we opted for a web application.

Structure of the apps

Once a web application is chosen, we look at its structure. When developing the application, we can distinguish 2 components at a high level: frontend and backend. Frontend is the application and interface that the end user works with and thus, in the case of RiskChallenger, enters and edits his/her risk file. At RiskChallenger, we have 4 frontend applications: the RiskChallenger app, the vote app, the brainstorming app and the admin app (managing organisations and environments).

The backend takes care of all the things that happen at the backend, such as storing the data in the database, ensuring that only logged-in users can access the data et cetera. In the backend, we distinguish between the API and the database. The API (Application Programming Interface) is a way for two different applications to communicate with each other. In our case, it ensures that the different applications of RiskChallenger use the same data and that this data is stored in the database.

The RiskChallenger app and admin app communicate with the API to store the data entered by the user. When voting or brainstorming, there is direct communication between the voting app or brainstorming app and the RiskChallenger app. Voting and brainstorming happen in real-time, which is why those have direct lines to the RiskChallenger app and do not communicate through the API.

Apart from the fact that our own RiskChallenger app needs to be able to view and store risk files, there are other, external, applications that want it. There are customers who work with Relatics, PowerBI or another proprietary software package, for example, and would like to use the risk file contained in RiskChallenger in those as well. All these external applications can also communicate with the API. To do so, however, they need an organisation-specific login to show who they are and that they have access.  

To ensure that all our applications and the data we all process are secure, everything is online at Microsoft Azure. Azure has the necessary certifications, including ISO-27000, so we can be sure we are not at unnecessary risk. We could also have put our applications online and done the server management ourselves, but that carries all kinds of risks. "Shoemaker stick to your last" they sometimes say, which also applies to us.

Conclusion and the near future

So RiskChallenger can be used in any modern browser (i.e. not Internet Explorer as some still like to use). We have seen how our applications are set up and that all data is securely stored at Azure. A stable base is in place.  

We are now working on beautiful new functionalities. These include adding files and dashboard functionality. In addition, we are also busy linking our clients and its applications or helping clients so that they can build a link with RiskChallenger themselves.  

Want to know more?  

Do you also have an application with which you want to edit the data contained in RiskChallenger and need a link? Send us a message and we will see how we can help you.

‍