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.
- It is necessary to develop a set of server-side web services that makes it possible to communicate with the platform from HTML5/JavaScript based applications via Http Web Services that respond using either XML, JOSN or CSV/TSV formats.
- Finally, it is necessary to build JavaScript client library that makes it easy to invoke remote procedures in the platform from custom client applications.
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.
What the platform does NOT do is build the end-user applications. This constitute two important constraints for the client -side JavaScript API:
- 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.
MICKA will be used to power the metadata system, LayMan will be used to ingest data and HSLayers will be used as a basis for the client-side JavaScript library. Each of these products rely on a number of basic technology components, meaning that the platform will be a quite sizable chunk of different software components and libraries, several of which have interdependencies. This, in itself, is not a problem as the solution is not meant to be maintained in a decentralized manner – only as part of a centralized Cloud solution. It does however add complexity.
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.
Traditional, locally sourced spatial technology with an emphasis on content – all machines need fuel…
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…
