Architecture standards: Governance

This is the sixth posting in a series on architecture standards. In previous postings we discussed the standards terminology, the documentation of architecture standards as well as the embedding in the organization and the life cycle of architecture standards. In this posting we pick up the thread and dive into the governance of standards.

Introduction

Architecture standards can be incredibly valuable, if they are properly managed and used in practice. This may seem obvious, but unfortunately we have seen several cases in practice where organizations develop a (large) body of standards and fail to manage and use it properly. Over time the standards base gets outdated, degrades, and loses its value at which point it will sit on a shelf collecting dust.

From this analysis, we learn that processes related to keeping the standards body up to date and processes related to governing the use of standards are two sides of the same coin. Both must be in place if we strive for effective standards management.

Keeping the standards body up to date

Keeping the standards body fresh, active, and up to date sounds simpler than it really is. At first glance, it may seem that all we have to do is to make sure that standards get a periodic review, and make sure that we have some mechanism in place to receive feedback from others on their usefulness in practice. There is, however, more to it than that. Here are some typical things to worry about based on our work in several organizations:

·         Who actually approves and effectuates a standard, and who is bound by its use?

·         Who owns and is responsible for maintaining standards in a certain domain. Is that one person, or a whole group?

·         Do we want standards to expire after a certain amount of time (i.e., we have to schedule a review cycle for each standard), or do they only expire when some stakeholder in the organization complains that it is out of date?

·         How do we make sure that our standards stay aligned with strategies, roadmaps, and policies of other groups in the organization?

Our experience is that a simple approach, in line with the TOGAF practice, tends to work best in this respect. In this approach we distinguish a number of roles in the standards management practice:

·         The architecture board (AB) owns the body of standards and drives its development and is responsible to keep it up to date. Members of the AB should be sufficiently high up in the organization, typically at the director level. They take care of approval of standards and delegate work packages related to the development of standards to domain leads. This is also where expiry of standards is tracked, typically by means of an automated system that triggers when a standard is about to become outdated. See also part 5 of this series where we described the management of the life cycle of architecture standards.

·         Domain leads are responsible for making sure that standards in a particular domain (such as integration, or security) are aligned with regulations (policies, strategies, roadmaps) etcetera. In posting 4 (embedding) of this series we described some guidelines and best practices on how to achieve this alignment. Domain leads are typically also subject matter experts.

·         Subject matter experts (SMEs) do the actual work of developing standards. Typically an SME receives a work package to develop or update a standard after which it goes via domain lead to the AB for approval.

One other thing should be mentioned here: developing and maintaining standards take time. It is not something that typically can be done “in between other jobs”. As such, work related to standards should be managed as mini projects with proper time codes, delivery and so on.

Standards use

In theory, standards are developed as best practices and people want to follow them because they make sense. In many cases this is indeed the case. We have seen several examples where standards around complex security services were followed automatically by everyone in the organization because they made so much sense: figuring out other ways to implement security requirements that are covered by the standard would just take too much time and hassle and thus no one bothered to do so.

In other cases, though, we see the exact opposite. 

Unfortunately this typically tends to be the case with standardized technology. Exaggerating slightly: it appears that every project wants to reinvent the wheel and bring its own specific new and cool toys into the organization rather than using the standard. 

We have seen cases where organizations have several different database platforms, ETL tools, and even ESB’s leading to a dispersed landscape as well as high cost around licensing and maintenance.

The key to success in this area is to make sure that everyone in the organization understands that standards management only makes sense if we maximize the return on investment by actually following them. This may require a lot of evangelizing and collecting of hard data. In the end it is worth it! Eventually the goal should be to make sure that following standards is second nature for all key stakeholders (sponsors, project managers, business owners and so on), while still taking into account that exceptions to the rule do occur in practice!

There are also several practical things that can be done to be successful in this area:

·         First of all, every project deserves an architectural intake. The goal of the intake is to figure out which of the standards apply to the project and whether exemptions are applicable. We briefly mentioned the selection of standards for a project in part 3, where we also mentioned that it is important to keep track of which standards were selected for a project.

·         Be careful of “thou shalt!” architecture in that respect: focus on how to help the project achieve its business goals effectively.

·         During the course of a project, actively monitor and help with the use of standards.

·         Especially for IT-related standards: develop a strategy for handling standards compliance of systems that are in production. Some rules (i.e. security) must always be followed. However, it may not be a good idea to upgrade the entire application landscape to the latest version of a standard platform.

Getting started

Last but not least, a few tips on getting started with standards management. First of all, experience shows that it is best to “think big but start small”. Start in a small area and start showing value, building the standards practice as you move along. Indeed, it seems that IT standards may be a good place to start. Get an architecture board in place as soon as possible. This will improve visibility of the initiative and provides a good linking pin to the rest of the organization. Last but not least: communication is a key ingredient of being successful.