This is the third posting in a series on architecture standards. In the previous posting we presented some basic terminology. Most importantly, we distinguished between standard rules, and standard components. In this posting we pick up the thread and zoom in on the documentation of standards. In order to do so, we kick off this post with an analysis of how/ where standards are used, and “derive” a template from that.
Using standards in architecture work
Requirements for standards documentation
- A standard document should contain a rationale (why did we decide to make this a standard) as well as a SMART statement of what is actually being standardized.
- We strongly recommend that it should be made explicit how governance will take place: who will check what, and when in order to make sure that the standard is followed? This will provide much-desired clarity for projects actually using the standard.
- Since we have different types of standards, relations between standards must explicitly be documented. This means, for example, that standard rules contain “pointers” to associated components and specification.
- Last but not least, the usual “meta data” should be in place: when does the standard expire, who owns it, what domains does it belong to, etc.