Architecture standards: Wrap-up and summary

This is the last in a series of postings on Architecture standards. Throughout the series we covered architecture standards from various angles ranging from business value, implementation aspects, and the operation of an effective architecture standards management practice. In this posting we will give a short summary and list the essential take-away messages from this series.

Architecture standards, why again?

The value that enterprise architects can bring to the business is to shape the design of the organization so that its components that the enterprise is broken down into in the most effective way. These components are IT related, such as applications, platforms, databases and servers. But also business related, such as business processes, roles and responsibilities, products and services. This optimal effectiveness must not only exist today, but also in the future along with the changes that an organization has to make to keep aligned with the dynamics in its environment. It is clear that this is a complex and rather challenging task because of the many factors that have an impact on strategic design decisions. A well developed set of architecture standards can be a valuable asset that supports strategic decision making. The key requirement here is that the architecture standards should be derived from corporate goals. We elaborated on how to do this in posting 4, embedding.

The use of architecture standards in change initiatives like IT projects can help to realize goals such as reusability of components and a better interoperability between systems. Well defined and documented standards make architecture governance a lot easier and a more clear process. Architecture standards help projects because it provides them with clear and tangible direction. Also a lot of expertise and know-how is encapsulated in architecture standards.

An overview of best practices

In this section we list the best practices around architecture standards management that were covered in the previous postings.

Common vocabulary

Introducing a common vocabulary has proved to greatly improve the effectiveness of our work. Words often mean different things to different people. We have good experience with drafting an “enterprise dictionary” in which we described the meaning of key terminology. Take for example the word “standard” itself. We defined a standard as the agreement that from now on some thing or best practice should always be used, most likely because its success has been proved in the past.

A clear structure

Some form of a structure is essential to be able to categorize and store standards. The structure should not be too complex but should still be powerful enough. Separating between the key content (including only the title, some key explanation and a short list of statements and properties) and the more elaborate detail has proven to be very powerful in practice. This makes that the actual body of standards looks like a deck of cards, which is easy accessible and searchable for projects. If details of a standard change, the standard itself doesn’t have to be changed.

Documentation

A coherent way of documenting standards improves accessibility and understandability of standards by its users. The templates should support the structure as explained in the previous section. We advise the use of a separate template for a standard component/rule and for a standard specification/configuration. The template for the standard component/rule also holds the meta-information for the standard such as the ownership, life cycle and version management information.

Top-down, Bottom-up

Standards should be aligned with business direction and derived from policies, strategies and roadmaps. But at the same time, standards should be in place to avoid problems that have occurred in the operation. It is clear that architecture standards do not live by themselves, but should be aligned both from a top-down as well as a bottom-up perspective.

Managing the life cycle

Once a need for standards has been identified a structured process to create the standard should be developed.  Once the standard is in place, it must be properly maintained and eventually the standard should be retired when it has served its purpose and is no longer useful.

Making architecture standards work

The success of an architecture standards practice is measured by how well it is perceived by end-users that are involved in change initiatives, projects etc. There are various approaches possible to make sure that the standards are used, ranging from tough governance to begging users to kindly try to comply with at least one standard. Some best practices here that will help socialize architecture standards with its users are:

·         In an early stage of a change initiative, determine which of the standards apply to the project and whether exemptions are applicable.

·         Avoid “thou shalt!” but focus on how to help the project achieve its business goals effectively.

·         Actively monitor and help with the use of standards during a project.

Summary

In this series we outlined what the value of a good architecture standards practice can be. We described a practical structure for capturing and documenting the key architecture standards in an organization. We also described how to manage processes around architecture standards, such as the role of an architecture board in the introduction of architecture standards, and the management of the life cycle of architecture standards. It is very important to consider that having standards is never a goal in itself. Standards should make sense in their context; they should be aligned from both a top-down and a bottom-up perspective. Only then will the enforcement and governance of the standards actually lead to a coherent, manageable and maintainable enterprise and IT landscape.