Version 1.1
The Manifesto for Agile Standardization (MAS) describes the 7 best practices of Agile Standardization
- Don't just standardize, be agile and standardize
- Do not reinvent the wheel
- Normalize real cases
- Be open
- Don't be overly specific
- Flat not Deep
- Sustainability is key
This zeroth best practice aims to remedy or at least differ from the classic standardization in terms of agility. Whereas in classical standardization, velocity is measured in months and years, in agile standardization, velocity should be measured in terms of days or weeks. This fundamental best practice implies that activities must be as automated as possible and, with the least amount of human intervention possible. As humans, in addition to our valuable contributions, we tend both to introduce errors (which will cause problems in automated processes) and to delay decision processes, something that goes against the principle of agility.
The first best practice states that, whatever is already commonly used on the market and has an open license should not be standardized again. Here it is worth emphasizing the use of the market, beyond the pure generation of theoretical standards. Too often standards (in the form of ontologies and vocabularies) are created that are looking for users, rather than solving real world problems and identifying the entities and attributes that are really needed.
The second best practice states that agile standardization should only be based on real cases that have already proven their usefulness in market situations.
The third best practice is simple - given that in many cases agile standardization is based on regulations with an open license, it would not be consistent to release the results without an open license, if possible. Any such open license has to allow free reuse, modification and sharing of modifications.
The fourth best practice is that of generalization. Although data models have to solve real world market problems, it is far too easy to start from a very specific use-case. Agile standardization must reach a consensus in order to make the model cover as many cases as possible, for example by limiting the number of mandatory attributes, without introducing complexities in the generated data models. Remember that what is mandatory for you could be optional for others.
Models should be self-contained where possible. A model referencing another model which references another model may be ontologically correct, but real world use cases prefer to access their data from a single location if possible
The last best practice is that of continuity. The agile standardization initiative shall only create models with continuous use and improvement in mind - this is not a "one and done" project-driven effort. Therefore, a sustainability mechanism should be in place to allow for the modification of the model as the market changes.
Alberto Abella
Jason Fox