The SDOs / SSOs you are working with at the moment

DIN committee "Electronic Business" 

Your main field(s) of activity

e-Invoice, document formats, machine readable specifications, automated testing of specification data, generation of human readable standards by the machine readable data.

What ICT Challenges are you addressing in the ICT standardisation area?

Agile Standardization: the aim is to close the gap between agile software development and the long roundtrips of creating their blueprints (standards) at working groups. Providing machine readable data (e.g. XML) embedded into the PDF in contrary to standards as paper & PDF now.

How, if implemented will this make a difference in a specific context ?

Standards could be far easier applied and tested by end-users, if their data can be accessed by automation (machine readable). For instance, there are over 200 pages of tables with data within the EN16931-3 (e-Invoice - Syntax Binding) only provided to the end-user by paper or PDF. A human have to read and copy the data manually, which is time consuming, error prone and boring.

Are there any best practices that you are aware of that put into practice these challenges described ?

While in the 80s software development had delivery cycles of often a year or more, nowadays by automation software releases are being made even multiple times a day. For instance, we do not notice that the chrome browser is being updated at last every 2 weeks during a sprint (the milestone of the software team). Processes of standardization should also embrace better tooling and automation to be able to react faster to the feature requests from their users (being software implementors).

What future actions or further specifications work would be necessary to undertake within an ICT Standards context?

I would suggest to have a better transparent processes and tooling based rather on open-source than on proprietary software to allow everyone to improve standards and the tooling software being used. Other:
- OpenSources Tests should be available at standard-level to proof the feature support of implementations .
- Standards should provide the difference to the previous version not by human readable erratas, but machine readable data, ideally to allow automated transition of existing implementations.
- Development by editors on standards should not involve exchanging the full document, but their changes.

Otherwise it would be as sufficient as software developers exchanging zipped source code repositories for collaboration instead of changing diffs for collaborations. In order to maintain a single document the changes of all editiors have to be merged and the question "what have you changed" is not answered by providing a full document (not even with change-tracking, which requires manually copy/paste and is not error resistant).