D 4.6 Agile solution development

At the WP lead meeting we agreed development models shouldn’t be too closely defined in beginning. Iterative process starting small and testing different ways to see which works best. With vary based on partners, their resources, the challenge and solution, how much overlap/work there is to do

Collaboration can include face to face to keep community active, but it should be structured so that different developers, partners, and non-SCORE cities can easily incorporate themselves after projects have started to continue working on solutions.

We should have a community manager for developers. This includes communication portal (slack?), have overview of who is collaborating with who, and monitor mutual quality assurance process. Also answering questions about the charter/guidelines on data publishing, etc.

We could use Docker, Heroku and micro services containers to facilitate collaboration, and include a designated space for code-sharing. This means people can deploy software without having to set up own servers which avoids having to reconstruct specific environments, at least for the QA, test and prototype production.

Two possible governance structures for solution development:

1. Leader/follower
   One city pioneers, and actively develops solution with support of other subscriber cities. Pioneer helps subscribers to also integrate in their cities
2. Full collaboration
   Full collaborative development between cities

Three possible ways of developing together:

1. Working on the same solution at the same time
2. Working on different components which can later be integrated into a single solution
3. Work on alternative approaches and solutions to solving the same problem

This is a core component of SCORE - how would you set up the collaboration structure?

Here in Ghent we’ve embraced openshift. I know it’s enterprisey and such, but to obtain something sustainable we need support on the base images. So that patch mgmnt can be centrally managed. This way we can quickly develop and iterate, but the image produced fits into a corporate structure of the rest of our IT infrastructure.

With the use of https://github.com/openshift/source-to-image we create images.

Seems better this way , instead of producing X dockers which can need particular updates at our most inconvenient times.

Ideally we’d all work together on the same solution.

Unfortunatly this seems a lot of overhead.

So would go for Leader/follower and Working on different components / Work on alternative approaches

One of the main risks that I identify with leader/follower is that what the leader produces will be developed too specifically for their own infrastructure and legal context. Although quite some more overhead is involved Full Collaboration or collaboration based on components does force the collaborating parties to develop software that is at least portable across different contexts. Often this can mean that one-common core is developed and that perhaps different partners have to make their own docker-images etc.

I’m hoping we can use the diversity of developing parties to force at least a bit of ‘abstraction’ and necessity of re-use.

Thus I think the choice of using a specific architecture is a choice that should be made on a project level based. A project might for instance be a library.

Or am I thinking to general and can we restrict this further?

Architecture: sure , it can be library as well… openshift is not meant to be restrictive. It just ensures me low effort to get something live and keep it running , so for us it’s a more a sustainability thing.
IF it’s a general docker fine, that’s also ine but we need to put some more effort in replication since wen need to do the source to image thing.

I understand your concerns about making software too specific, and I agree that we should look out for this. The other edge of the sword is the feature creep of too many captains on a ship.
Second: we should build our tools generic enough so that they can be broadly applied, if not for other cities, then in any case for our organisations.