- Adaptive Enterprise
Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
In the previous posting we have explained the benefits of having a good standards practice in place, especially in the context of enterprise architecture. In this posting we set the scene for our framework on standards management by introducing terminology that we will use throughout this series. This terminology has been tried and tested in practice, in both business and IT-related settings. We have found that standardized terminology around standards management greatly improved effectiveness of our work.
The word “standard” means different things to different people, ranging from “a statement of direction” to a very detailed instruction manual on how to do or configure something. See for example the Wikipedia page on this term. Similar terminological confusion arises over words such as “technical specification”, “policy”, “strategy” and “roadmap”.
To complicate matters even more, the question of what is what is often a matter of perspective. To illustrate that point from an IT perspective, consider the following example: the fact that certain types of platforms are in use as well as selection criteria for picking the right platform would be a useful standard from an (enterprise) architecture perspective. From this perspective, all technical data on how these platforms are configured etc. are too detailed. However, from an infrastructure perspective, these details are an essential part of the standard!
A standard can loosely be defined as the agreement that from now on some thing or best practice should always be used, most likely because its success has been proven in the past. This definition is general enough to apply to the standardization of e.g. processes, types of technology, or even dress-code if necessary.
In order to make standards useful for projects, the set of standards should be very specific and to the point. The collection of standards (the standards base) can be seen as a “deck of cards”, where each card is one standard. For each individual project we will select those “cards” that are applicable to the project. By adhering strictly to the deck-of-cards principle, the actual standards are kept short and to the point which in turns has two main advantages:
1. A smaller set of standards and selected for relevance is less likely to “scare off a project”
2. Governance is easier when standards are SMART
Considering the set of all architecture standards, two subsets can be distinguished:
Since we are developing standards as a “deck of cards”, these rules and components should be short and to the point; details are documented elsewhere as visualized in the following diagram:
The specifics of a standard rule are documented in a standard specification. The following example illustrates this. In a standard rule named “data specification” it is asserted that an organizations specific naming convention should be used when making data models. The actual lists of names that are allowed are documented in the standard specification that is associated to that standard rule. There is an extra advantage of separating between the “core” of the standard, as documented in the rule, and the details, documented in a specification. If some detail changes, this change can be processed in the specification without having to put the actual standard through a whole process of revision. We will elaborate on this kind of processes in part 5 of this series.
Some of the standard components are actual tools. We tend not to use these tools “out of the box”, but we configure them in a specific way. Therefore, these configurations may be associated to standard components. For example: the standard component for architecture modeling is a tool called BiZZdesign Architect. This tool can be configured to automatically follow certain naming conventions, layout options etc. That is why a dotted relationship between a configuration and a specification is depicted in the diagram above.
Some of examples of standards at the enterprise level are:
The technology components are configured in such way that it meets the security standards and all the detail of it as documented in the various specifications.
If you’d like to know more, please contact the authors directly at email@example.com/ firstname.lastname@example.org, or leave a comment. The next post in this series covers the documentation of standards – a topic that was briefly touched upon already in this posting. It is scheduled to be posted on the 23rd of January 2012.