WHAT IS SOFTWARE ARCHITECTURE?
Software architecture comprises the fundamental structures of a software system and the creation of these structures. Similar to building architecture, it sets the blueprint for the design, in this case of the software, establishing the tasks the team must execute at each stage. Good architecture ensures the team is building a robust project, which will stand on its own while allowing the addition of new features and developments.
The goals of the 121 project have been are guiding the creation of specific software architecture. Our approach to building this project reflects the way we choose to work as a team.
WHY IS IT IMPORTANT?
Software architecture, like organisational culture, emerges in every project, with or without deliberate choices to define it. Conscious choices are preferable in order to create a functional organisational culture; the same applies to software architecture.
The product is delivered via a technological platform that supports the registration, inclusion & distribution tasks of CBA. As such, software architecture is essential for meeting the project goals.
WHAT ARE WE WORKING ON?
The 121 software architecture is built to have these four characteristics:
121 will be a free software, granting users “the freedom to run, copy, distribute, study, change and improve the software”.
The aim is to provide all humanitarian organisations a way to use the software and change it to their will, without charging money and without having to ask us for permission first. To achieve this, we will distribute the software with an open-source license, which we are in process of determining. The open-source technology is used in the tech stack only, excluding the need to purchase software licenses.
CBA and humanitarian programmes dealing with identity are diverse, thus the need to create a ‘flexible toolbox’ of modules anyone can use as needed rather than a ‘one-size-fits-all’ system, limited to one use case. For example, the identity part of the software is separate from the payment part.
We want people to be able to operate the 121 platform independently from our own operation. The two options we are currently weighing are for every programme to have its own server, thus its own database and software version, or to run multiple programmes from one instance.
We envision 121 as a foundation that will become increasingly valuable as more people will use it. Specifically, we decided to use a specific, open-source technology for self-sovereign identity (Sovrin) rather than create one. Once a digital identity is created through 121, People affected will be able to use it in other programmes as well. And vice versa: a digital identity created in another programme can also be transferred to 121. This field is very much evolving, and we are in the process of the testing the feasibility of this ambition.
HOW DO WE WORK?
A central aspect in the way we work is the focus on delivering a Potentially Shippable Product every sprint. Our Scrum Master Diderik van Wingerden oversees the optimization of the Scrum processes.
WHO DID WE PARTNER WITH?
WHAT HAVE WE ACHIEVED SO FAR?
Important achievements in the 121 software architecture so far are:
- Having a 100% open-source tech stack
- Successfully integrating two components developed by TYKN for the 121 platform
The 121 team is currently working on the following:
- Choosing the optimal open source license, as mentioned above
- Redesigning and refactoring the architecture toward a modular system
We will soon start the integration of the Disberse API for banking and payments.
WHEN & WHERE DO WE WORK?
We began researching the system for 121 in 2017.
The ultimate goal is to develop a system that can adapt to any type of disaster, in any location.