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.

Introduction

In pure science, many research papers seem to start with “assume we have a model for X”, after which a lengthy discussion follows. In practice, we do not have such luxury, especially in the field of architecture standards. If we as an organization want to be successful with standards, then we better put in the work to make that happen.

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.

Life cycle

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:

The basic idea is simple: first, standards need to be developed. After an idea has been articulated and while it is being developed, the state of a standard is draft. Once it is ready for approval, it is offered to some board (typically the Architecture Board – AB). The state then changes to under review. Let’s assume the board approves it.

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.

Process and templates

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.