Action-SC-2017-60 Circulate a proposal on pilots to SC

[rogers492]

@remygiraud Put the proposals regarding pilots into email and circulate to SC.

[rogers492]

Hello, Following our discussion today regarding the discussion of pilot projects funded by the association, here is a more detailed proposal.

Each Partner is invited to present pilot projects under the theme "Imagine WIS 2.0". Each project should illustrate a particular aspect of what could be the WIS 2.0 for the users. E.g. use of google like search engine, a publish/subscribe mechanism to access data, ... The focus is on what user will see not on the technical nitty-gritty below the hood. The project would :

• have demonstrable results by TECO 2018 (March)
• have a designate project manager from a Partner
• receive a grant of 25k euros from the Association (the leading Partner would have the opportunity to had extra funding if required) The proposal (a 1 page document) would describe what is expected by this pilot and how it could fit into the (likely) WIS 2.0 solution. Each pilot can use existing ressources such as:
• the 24h cache
• the catalogue
• available WMS services already proposed by members
• ... Among the proposal the TC selects up to 5 pilots projects. Through eg the planned developer conference the TC will prepare a more elaborate proposal (it may include architectural or technical requirements). These (up to) 5 proposal will then be submitted to the SC which will then select 3 or 4 of them.

There is no need for a shared technical environment (architecture, programming language, framework, ...) for the pilots. It is unlikely that these pilots (in the way they would have been developed for this "Imagine WIS 2.0" action) will be part of OpenWIS 5.

The upcoming board meeting would have to agree on spending up to 100k on this and will delegate the actual spending on the SC.

The SC planned for septembre 14th is the target date to select the pilot projects.

Hope this make this proposal more concrete. If SC agrees on this (by correspondance), I am happy to attend an upcoming TC to get the ball rolling.

Regards, Rémy Giraud

[rogers492]

From Kari Sheets: • From a software design/engineering perspective you usually have at least a beta of the next version before you enter into maintenance mode, so maintenance mode with the only date I've heard for next version being 2020 (2.5-3 years away) concerns me • Having been the last member to do a full install and knowing we have 2-3 interested new partners maintenance mode for version 3 could prove really interesting as they try to install on new infrastructures as it is a very hardwired and bandaided system (why I thought we were headed to version 5 as more modular and as "infrastructure" independent as possible. • The cloud is here, so regardless of how WIS 2.0 specs end-up I think there are some basic IT industry tends we could develop according to and will put us at a better place to do a dot release for WIS 2.0 than waiting until the spec fleshes out to start changing our software design & architecture. In my ideal world we would go ahead with 5.0 redesign of the core OpenWIS software to be modular and capable of being installed on VMs or cloud instances o I led a migration of a VM based system to a cloud system, it wasn't trivial, but it can be done, so I don't think OpenWIS 5.0 needs to be as tied to WIS 2.0 as others on the call indicated in order to make it "cloud friendly" • Pilots - again this is what my tardiness probably left me the most in the dark of - my concern is that we're going to end up with 6 independent iterations if there's no common code base/guidelines for them to need to "plug and pal" into.

[rogers492]

If we do go the route of independent pilots, I would expect each to have its own charter – especially if Association money is paid out, so I’d wait for the Board decision.

I suggest those of us that appreciate the value of a plug-and-play architecture organise our pilots around a common framework and then maybe we don’t have to throw our pilots away later.

[rogers492]

From Jeremy Tandy: I'll try to respond to your concerns in line below...

From a software design/engineering perspective you usually have at least a beta of the next version before you enter into maintenance mode, so maintenance mode with the only date I've heard for next version being 2020 (2.5-3 years away) concerns me

The point here is that the OpenWIS Association will not be prioritising any functional enhancements of v3. Clearly, we will be responding to operational needs for bug fixing and patching. We also discussed today that if a member/partner wants to make a functional enhancement, they'll need to do that at their own cost, but the TC will work with them to migrate that enhancement into the Trunk. So the software will evolve, just on a slower pace.

Really, the "maintenance mode" for OpenWIS Core 3 is a reflection that we have limited resources, and we want to focus on supporting the evolution of WIS to WIS 2.0. Future looking.

Having been the last member to do a full install and knowing we have 2-3 interested new partners maintenance mode for version 3 could prove really interesting as they try to install on new infrastructures as it is a very hardwired and bandaided system (why I thought we were headed to version 5 as more modular and as "infrastructure" independent as possible.

Agreed. We've all worked hard to automate the deployment as far as possible ... and I recall MF saying that they were planning to Dockerize OpenWIS Core 3 which should help further. That said, in a world of finite resources, we have to make choices about prioritization - and we are recommending to focus on the pilot projects. I suspect that the new members / partners will be interested in those pilot projects as much as the OpenWIS Core 3. Could be wrong. Have been before!

The cloud is here, so regardless of how WIS 2.0 specs end-up I think there are some basic IT industry tends we could develop according to and will put us at a better place to do a dot release for WIS 2.0 than waiting until the spec fleshes out to start changing our software design & architecture. In my ideal world we would go ahead with 5.0 redesign of the core OpenWIS software to be modular and capable of being installed on VMs or cloud instances I led a migration of a VM based system to a cloud system, it wasn't trivial, but it can be done, so I don't think OpenWIS 5.0 needs to be as tied to WIS 2.0 as others on the call indicated in order to make it "cloud friendly"

I think I agree again. In my view, I see the general direction WIS 2.0 is headed (I wrote the technical strategy!) and am willing to take a punt on those industry trends and use our [pilot] implementation to inform the development of the WIS 2.0 Tech Specs. So I see things as being quite iterative. And I see getting the technical architecture right as an important concern ... I need to understand what Remy's motivation is around "not caring about the architecture". I think he raised an important risk that the technical underpinnings may change by 2021 - but I think we can manage this risk. As Paul said, I suspect the TC, or elements thereof, will agree to develop a consistent architecture for the pilot projects. I think this is important so that we can 'bank' our development time and move forward in an incremental fashion.

Pilots - again this is what my tardiness probably left me the most in the dark of - my concern is that we're going to end up with 6 independent iterations if there's no common code base/guidelines for them to need to "plug and pal" into.

Agreed. I want our components to be plug-play-discard--redevelop-playsomemore etc. So we need an architectural framework in place. We also need to design maintainability in from the outset.

So ... I think we're on the same page.

Do you agree?

[6a6d74]

During the Board meeting today, we agreed the road map for OpenWIS Core as proposed by the TC...

Along with managing OpenWIS Core 3 in "maintenance mode", we will establish pilot projects "that move us toward WIS2 and OpenWIS Core 5" - noting Rémy's point that we may choose to discard these pilot implementations rather than incorporate them into an eventual software code base. Our goal is to learn how to do OpenWIS Core 5 properly without (necessarily) trying to build production quality software from the outset.

Building on Rémy's original proposal above revised approach might be:

1. Solicit ideas for pilot projects - noting that successful proposals would be eligible for additional funding support from the OpenWIS Association
2. TC assess and prioritise proposals- advising on the architecture (etc.) to ensure best value for money (Rémy suggested that the pilot projects may not need to have any common architectural aspects so that 'functional' aspects could be prioritised - the TC may be able to suggest implementation proposals that are technically consistent thereby enabling the pilot implementations to be more readily integrated into a single demonstrator ... but such 'architectural consistency' should not be an overriding concern)
3. SC approve the pilot projects at planned teleconf, 14SEP (question: if we aren't allocating funding at this point, do we still need SC approval or can this be fully delegated to the TC?)
4. Work packages relating the the pilot projects would be added to the backlog as per the standard development procedure - using existing committed resource from Members / Partners
5. Where additional resource (not available within Member / Partner budget) would accelerate the pilot project implementation, a Request for Financial Support may be submitted to the SC as per (the newly approved) Rule 12.8

Third parties may be contracted directly by the OpenWIS Association if it is convenient to do so. Alternatively, existing framework agreements such as that between Met Office and EuroDyn may be leveraged to avoid wasting effort on [contract] management overheads.

The Financial Management Rule Supplement describes the approvals process for any financial spend. Due diligence is required for any spend - which may be met by obtaining multiple quotes, or by using an arrangement such as a pre-competed framework agreement.

Expenditure must be approved prior to incurring where required and due diligence should be taken when entering into contracts or incurring expenses on behalf of the association, to ensure the association is getting value for money

We did not set a budget envelope for these pilot projects during the Board meeting- but note that Rule 12.6 indicates that the Board can approve expenditure in excess of the agreed annual budget.

[rogers492]

ACTION REQUIRED: indicate whether or not you support the proposal to delegate to the TC Chair selection of pilot projects not requiring financial assistance.

SC members:

At our Board meeting last week, the Board approved the roadmap for OpenWIS Core (see minutes 1 item #8), deciding:

1. to focus our efforts toward WIS2
2. to conduct three or four pilot projects over the next 12 months

We also had a lengthy discussion about funding for these pilot projects in the light of potential funding being provided via a 'request for financial assistance' as per the newly approved Rule 12.8 2.

During our Board meeting discussion (see para #8.9) we suggested that the TC would solicit ideas for pilot projects, review those proposals and submit them to the SC for approval and potential allocation of funding.

Looking at our planned meetings, the SC is next scheduled to meet on 14 September. Waiting until then to proceed with the pilot projects creates a delay (or hiatus) in the work of our technical teams.

I would like to propose that the SC delegates authority to the TC Chair to select pilot projects from set of proposed projects that do not require financial assistance.

In doing so, this would allow the work of the technical teams to proceed with immediate effect.

Any proposal requiring additional funding will need request financial assistance via the SC for recommendation to the Board, which will likely require the TC to have done some initial assessment of any proposal seeking funding to develop a costed proposal and clarified the outcome / goal of the pilot. Recommendations for projects requiring additional funding could be brought to the SC on 14 September.

I would also request the TC Chair report on the selected 'non-funded' pilot projects at the SC meeting on the 14 September.

The TC are scheduled to next meet on 10 August where meritable proposals for pilot projects will be discussed.

Please will you respond to indicate whether you support this delegation of authority to the TC Chair.

Thank you, Jeremy

(OpenWIS Association SC Chair)

-- Jeremy Tandy Senior Scientific Officer, ITS World Meteorological Organization

[rogers492]

Agreed. However, some additional elements:

• ideally pilot projets should have something to be presented during TECO in March 2018. It might not be the "final" version but being able to present some contribution of the OpenWIS association during the TECO would be a plus.
• the pilot projets should focus on demonstrating the benefit for the users of WIS 2.0. The compared merits of micro-services vs traditional approaches or ... are useful, they nevertheless shouldn't be the sole reason of the pilot project.
• the technical framework of the pilot projects is not imposed Regards, Rémy

-- Rémy Giraud DSI/ISI/DA

[rogers492]

Hi Rémy - I think that these are good caveats. Given that yours is the only response from the SC, I will infer that no one has any objection to the TC Chair selecting projects.

They meet today at 11UTC.

Steve / Paul: can you ensure that Rémy's criteria are considered when selecting the pilot projects today.

Many thanks, Jeremy

[rogers492]

The outcome of the vote was that OPP-6: WIS Djibouti will be taken forward.