How do we define open and replicable solutions?

Hi everyone!

I would like to open up a conversation here on the community about how we define open and replicable solutions.

SCORE is about making solutions that are scalable, reusable, and adaptable to solve different problems.

How do we ensure that the solutions we build in SCORE have these properties? What are the critical points we should focus on (beyond open source code)?

@boris - you will be in Sofia next week at the SCC-EIP together with Bo - could you ask about how they did it in the OS2 foundation? Barcelona and cloud4cities might have some good insights here too?

@brynskov - any sharable frameworks or methodologies from Synchronicity?

Perhaps we should set up a ‘technical forum’ to tackle this (building on the draft principles of quality code and the solution discussion template Joran and Hugo are working on)

(Apologies for the multiple posts)

I would propose from the city side: @HansF/@pjppauwels as techies from Digipolis, @Boris as SCORE’s open source manager, @h.niesing as WP4 lead, @turegjorup as techie from Aarhus
with support from universities: @dhaval and/or @m.worring & @srudinac
+anyone else who wants to join

@Boris something you could chair? Either a physical meeting or telco? I don’t have enough feel for the content to assess what is required.

Happy to help. Maybe involve @brynskov who maybe has experience with Synchronicity.
There they are more SME focused but I like their MIM definition:

Minimal Interoperability Mechanisms (MIMs)
• Open APIs
• Common data models
• Objective: interoperability, replicability, reuse

We could have this as part of the WP6 work. In several other initiatives, there similar activities going on (we had a whole session on it in Bilbao).

Only issue: summer is starting. When should a baseline be defined?

I could definetely chair this, and I’ll also ask Bo about this. I think that @h.niesing and @JoranVD might have made some progress on this as well.

However, in my optics, if available we should use an existing framework from somewhere else, so if the Synchronicity framework offers us enough for what we need then I’d love it for us to adopt that. Alternatively we can define one ourselves and I would love to see how we can embed our values in something like this.

@claus: What kind of things do you think we need beyond Open Source, Open Standards and Open Data?

Agreed we could adopt the MIMs/Synchronicity framework.

Perhaps one additional point:

How do you build a solution that it is not only geared up to solving just one specific problem, but is adaptable to (at least) a few problems. What process/tools/methods can facilitate the discussion/design process/consensus building between multiple cities(/departments) that want to solve similar but slightly different problems?

here I think OS2 and Barcelona experience would be extremely useful

Not just adopt, but build on top of. Synchronicty (IMHO through what I learned in the open call) is focusing on SME’s that have business and IP interests. I feel that SCORE goes beyond that as it is city-driven and thus Open Source and Open Data have more meaning and impact in this consortium. It is about sharing, openness, transnational development, building component that serve multiple purposes in stead of one trick pony’s.

A very readable way is approaching it like the criteria of the Gov.UK Digital Service Standard:
https://www.gov.uk/service-manual/service-standard

You could try to make a set of criteria to be able to speak about a (S)CORE solution.

I agree that SCORE should try out AND influence the MIMs. They’re all open and free license-based, as this is the only thing that the cities will accept, exactly because they’re not supposed to be static but evolving, always with the Council of Cities in OASC to adopt or reject new releases.

The focus of OASC is not on SMEs, it’s on cities. But the focus of the SynchroniCity open call is to ensure that SMEs can get a foothold in the market. Cities doing in-house development are treated as supporting in the case of the open call, as this is by far the most common case, in Europe and globally. But the OASC MIMs are for everyone, exactly so that your free to choose who dose the actually development and operations related to a (micro)service.

For the supply-side, (1) reusability and (2) replicability is key. But for most cities, it’s not the main features they seek, it’s (3) replaceability (to avoid vendor lock-in) and (4) comparability (to facilitate choice). Cities doing in-house development obviously would seek all of them, as they play both roles. However, in many cities, different departments may even have different views on this. Therefore, the replicability goes both ways: you can not only change vendor but also out- or in-source.

The OASC MIMs simply (seek to) enable all of that. And leave the politics to, well, those who influence such choices, which is a complex matter.

And SCORE can provide a certain approach to setting up a whole service devops ecosystem based on a shared (?) vision.

Good conversation. That’s probably a good starting point or at least element for next Tuesday’s landscaping exercise: what are the (a) initiatives, (b) technical frameworks, © approaches, (d) ???.

In the IoT Large Scale Pilots, we’re trying to understand which “marketplaces” (catalogues with terms and mechanisms for use and exchange) that exist and should be developed further, eg. around data, (micro)services, components (software) and hardware.

Cheers,

Martin

Correction: Therefore, the *replaceability goes both ways: you can not only change vendor but also out- or in-source.

Hi community,

We had a meeting about this (lead by Martin from WP6 + representatives from the other WP leads).

My notes below:

Two key steps/discussion points are key for SCORE to proceed:

• Common technical baseline (data formats, APIs, etc) for all partners/solutions to adhere to
  • This could be done per solution, per ‘waterfall’ in SCORE, of for SCORE as a project
• Convergence around challenges/solutions between cities

There is also a complex ecosystem of existing projects which SCORE could build on, that are working on common technical baselines and convergence: OASC, Synchronicity & other IoT Large Scale Pilots, Smart Flanders, Eurocities, SharingCities + other EIP-SCC Lighthouses (particularly their data task group), IoT Forum…

Practical next steps:

1. Agree on a handful of solutions to start with

• Confirmed: IoT Registry (Aarhus and Amsterdam + others)
• Pending: Water group, Traffiken.nu, DrukteRadar, Taxonomy Tool, Travel Time
• Try break these down into separate components (ie all will include map interface and visualisation of geolocalised datasets)

2. Conduct an initial baseline research into the above listed projects to identify what is already in motion

• Including OASC reference implementations, data models & Minimal Interoperability Mechanisms (MIMs), standardised and open APIs, Pivotal Points of Interoperability (PIPs) and data models

3. Secure required resources to build solutions

• This can be internal commitment, or external (incl synchronicity call which covers many of the same issues as the working groups, or the upcoming EIP-SCC1 call)

4. SCORE should participate actively in relevant events and communities

• Including Smart City Expo in Barcelona, OASC’s CSCC in Brussels and IoT week in Aarhus,…

5. SCORE should develop a series of informative webinars over the next year to build a common understanding

• Including w/ OASC on the work it is doing (early october) and about open source and open data in general

Future items:

• How can we package the SCORE requirements (technical baseline above + open source and open data elements) into practical procurement guidelines so that cities without internal development capacity can also participate?

Additional “Knowledge nuggets”

• Standards are absolutely essential for mainstreaming common technical baselines and allowing these to be applied in procurements & contracts. However, these must be ‘minimal’ and ‘ergonomic’ so they remain useable and practical.
• Breaking down solutions into generic or ‘micro’/’baseline’ services and components is key to ensure a solution’s replicability (eg not focus on building a solution to help delivery vans find spaces to unload, but build a map, a free space monitoring system, and notification system about free spaces)

Here @pjppauwels’s notes reflecting on the same meeting:

SCORE’s baseline could be Bart Rosseau’s quote: Think local, Code Global. (oppositish from Think Global, Act local, with emphasis on: Build things for your specific city (service), but think about how other can re-use that code for their benefit or usecase.

A double diamond could help think about solutions:

1_plChYNkaj7TWsLPImkB41A1600×900 134 KB

• Diverge (on a challenge level): Look for real world challenges amongst cities.
• Converge (on a challenge level): Translate into common challenges and translate into solutions (start of second diamond).
• Diverge (on a technical level): Based on the commons challenges translate to technological solutions and diverge back to what frameworks, open source code bases, technology stacks, open standards do already exist.
• Converge (on a technical level): Choose a mixture of what works for the cities and converge into an service platform upon which cities can build their specific final city service / usecase / solution?

Learnings for Ghent: We’re in a difficult place right now. We’re keen to start developing and in september will have a dedicated employee working with us on this project as a project manager, as well as a developer. But on the other hand it hard to get buy-in on the city side for the 5 current working groups as they are not really aligned with the common challenges we put forward back before the kick-off. We’re trying to abstract projects and see how they can serve a purpose beyond the specific solutions that are being presented in the working groups.

These were our five original ones:

Can this be linked back to impact of events on mobility in which we use IoT devices to measure changes in traffic patterns due certain events?

Can the travel time tool app be used to help people with psychical disabilities to visualise how hard it is for them to get from point A to B in minutes and what actions would mitigate the time gap between citizens with disabilities and citizens without disabilities?

Can we use the basis of the IoT register to create a private green space register?

Due to soil sealing the city is facing urban heat island challenges and cannot absorb water on a district level leading to a number of negative effects.

Can we use the drainage working group to think about not only measuring drainage issue, but translate them into urban planning where green space is also a way for water absorption?

I imagine when you would look at the working groups, not as fixed end to end solutions, but as higher level abstracted clusters of baseline services, you would be able to fit in these scopes and make sure that the same technology stack serves multiple use-cases.

And that for me the biggest challenge within SCORE. It’s not necessarily about does the solution fit with in my city, but does the technology that supports that solution is useful in my city as well?