March 26, 2013
Architecture standards: Life cycle
This is the fifth posting in a series on architecture standards. In previous postings we discussed the standards terminology and the documentation of architecture standards as well the embedding of the standards practice in the organization. In this posting we discuss the life cycle of standards.
More to the point: standards cannot be “magicked into existence” once a need for it has been identified (e.g. top-down or bottom-up, see the previous post in this series). It takes time to develop a standard, and once it has been developed it must be properly maintained and eventually it should be retired when it has served its purpose and is no longer useful. The “circle of life”, so to speak.
Setting up a proper life cycle and supporting process may seem simple at first glance. There is a bit more to it than just tracking which standards are still in draft, which are active, and which are retired, and this has everything to do with a pro-active governance process. The following diagram shows the various states and transitions that we found to work well in practice:
Here we introduce a first trick: there may be valid reasons to hold back the publication of a standard for a bit. For example, we want some IT component to become the standard for some functionality, only the project that initially implements the functionality has yet to start. Therefore, we must distinguish between an awaiting publication state, which merely states that the board agrees, and a subsequent active state which means that the standard has actually been published and is now valid. The active state is actually composite as it encompasses several sub-states as illustrated by the following diagram:
First we hit the pure active, published sub-state. This means that the standard is out there, being used etc. After a while (typically time-triggered), the standard must be reviewed by the board. The state then becomes active, under review. This leads to an update (active, under revision), immediate re-approval (active, awaiting re-publication) or a decision to scrap the standard because it is now outdated. The latter means we’re moving out of the composite state to the Archived state.
In order to effectively manage the transition between the different states of standards, two things are needed: first of all, standards must be clearly tagged with respect to their state. This can either be done in the document itself, in a document management system, or otherwise.
However, this is not the most important part. In order to be successful, the organization must look into standards approval processes as well as roles and responsibilities. This ties directly into the world of enterprise governance which is the topic of the next posting in this series.