Why standardise? The business case for the adoption of cloud standards. Views and recommendations from the CloudWATCH Summit

CloudWATCH2 organised a panel-driven conversation about the business case for the adoption of cloud standards (and standards at large) at the CloudWATCH2 summit 2017, which at the same time marked the project’s final event on 19/20 September 2017.

Setting the scene with a shortened version of the original presentation given at the EIT-Ditigal “International Industry-Academia Workshop on Cloud Reliability and Resilience" the panel featured renown experts in the field of standardisation crossing the areas of academia, public authorities, and open source:

  • Wolfgang Ziegler, SCAI, OGF and StandICT.eu

  • Cedric Thomas, OW2

  • Arthur van der Wees, Arthur’s Legal

  • Bruno Chenard, CEN/CENELEC

 

The experts provided the following input regarding the standardisation process:

Balancing standards & the freedom to innovate  - How do we find the right balance between standardisation and the freedom to innovate?

  • Innovation comes first. This normally only occurs where there is no open source tool or service already available. The innovation then becomes widespread (or dies out) and becomes a product(s) or service(s). It is at this point that standardisation tends to emerge together with Open Source solutions.

  • This cycle closely resonates with the business innovation cycle, and Simon Wardley’s “Climatic pattern: Peace, War and Wonder"

 

Standardisation process & timing – What is the right process to follow in developing standards? And when is it time to begin the standardisation process?

  • There is no single one right process; it entirely depends on the context (public domain/international, or commercial).

  • Standardise as soon as possible vs. standardise late in the market: Fast-moving markets mean that industry pushes ahead with new deployments that are not interoperable (i.e. the freedom to innovate). Building a strong network is key for consensus, which is prerequisite for successful standardisation to cake place, but this takes a long time. Consensus building – through influencers – early in the market as a means to build the foundations for formal standardisation means that we can help accelerate the process and drive the market.

 

SMEs vs. Corporates – What are the advantages and disadvantages of having standards in cloud computing? Are those advantages and disadvantages different for a large company compared to a startup? If so, whose interests should be prioritised?

  • Standards penetration rates in industry are appallingly low but there is no clear reason why. Do we need to re-fit the way how standards are developed, published, and defined? Or is this linked to the inertia of change often seen in organisations large and small?

  • Is there a correlation between the cost of switching in non-standardised ecosystems and the cost of implementation (or, for policy/process standards, compliance) that governs whether and at which rate standards are adopted?

 

Recommendation

  • Standards are useful, but cannot be seen as the broker for progress. They are closely related to innovation, and together form a perpetuating cycle of innovation and standardisation that follow in each other’s footsteps.

  • We are also facing new challenges as the landscape becomes more complex with the digitisation of industry, bringing in different cultures and different speeds. Early roundtables can facilitate consensus building as part of the long-term, voluntary efforts, which encourage collaboration for standardisation.

  • There is no single correct way of how standards develop or emerge. Standards cover both the technical domain, and the policy domain being closely related to regulation and law – highly similar in process how both types of standards emerge and then initially develop.

  • From emergence though, technical standards and policy standards will then take different routes as they are generally trying to attain slightly different goals: Technical standards aim to simplify and allow higher level functionality to become the differentiator, whereas policy standards are aiming for simple unification.