Building the SDI4Apps Cloud includes three different steps
- It is necessary to establish a virtual machine platform and to install the basic server components in this platform.
The value proposition of the platform is that it outsources the operation and running of the platform to SDI4Apps instead of each organization having to install and maintain the software on their own servers.
Furthermore, the platform will be preloaded with a number of common, shared datasets such as OSM base maps, meaning that it reduced the repetitive work required by each individual instance by doing it in one place, once.
- must be powerful enough to attract technically sophisticated actors who might otherwise consider running their own infrastructure
- must be simple enough for less advanced actors to build spatial-enabled applications without prior specialist knowledge on GIS.
Overall, the platform must also be an affordable alternative to running a private infrastructure, otherwise… Well, need I say more?
Now, given these constraints, we had to evaluate the best way to move forward. We started off by looking at the technology components that SDI4Apps partners bring with them into the project.
During the code camp in Plzen, we started off by agreeing on a working methodology and then set out to divide the work into manageable chunks that we assigned to individual developers and scheduled according to development milestones.
Our business idea is to offer services, not to sell software, thus it was decided that the entire development will take place in an open environment using the ‘social coding hub’ GitHub. Git also implies a workflow that can be more challenging once working in a team that is heavily distributed. In the case of SDI4Apps, developers reside in five institutions in four countries. However, the idea is to do the development as a variant of Scrum, where each group applies it to their specific subset of the project work.
Now, I have highlighted the importance of thinking ahead and keeping an eye on the fact that we are trying to establish a workable platform that can be commercialized at some stage; another equally important issue to think of is that of testing.
Testing is often done in an ad-hoc manner. Code is changed, a qualitative test is conducted to see if something accidentally broke and if nothing is seen at first glance, everything is assumed to be ok. Another typical test scenario is that the performance thresholds that a test is measuring a solution against are determined after and independent of the implementation of the solution.
That means that a service designed to perform at 100ms may later be expected to perform at 50ms – something that either isn’t technically possible or that isn’t possible due to implementation choices that may – or may not – be valid.
We therefore set aside a portion of the agenda for discussing testing during the code-camp to make sure that the developers are aware of, and indeed have the chance to impact, the expectations at a time when it is still possible to make design choices related to the implementation of services.
Until next time…