Architecture standards: Terminology

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 term “standard”

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.

Deck of cards principle

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.

Rules and Components

Considering the set of all architecture standards, two subsets can be distinguished:

• First of all, there is a set of “things” that are mandated to be used in certain situations. Examples are standard tools, platforms, models, and software components.
• The second subset of standards can be thought of as rules: things you should do or properties that systems should have. A typical example here is the fact that sensitive data must be encrypted with certain algorithms and a specific key length. 

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.

Examples

Some of examples of standards at the enterprise level are:

•  Enterprise Security Standard:
• Rule: All solutions and applications should comply with the enterprise security standards such as identity management, access management, auditing and monitoring, and information control.
• Details of each of the security domains mentioned could be documented in separate specifications.
• Also relationships to standard components that support the security standards can be created. The standard components refer to physical technology components that the organization chose to adopt.
• 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.
• Enterprise Integration Standard:    
• Rule: All solutions and applications should comply with the enterprise standards for service oriented architecture (SOA). All interfaces from and to software components should comply with the enterprise standards for interface definition.
• Details and specifics of how the interfaces should be defined can be documented in separate specifications.
• Relationships to standard components can be created. These components describe specific platforms and tools that support the enterprise SOA strategy. For example service repositories and the technology used for routing and transformation (i.e. the service bus).