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: 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.

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.

Architecture standards: Embedding

This is the fourth posting in a series on architecture standards. In previous postings we discussed the standards terminology and the documentation of architecture standards. In this posting we pick up the thread and dive into the embedding of the standards practice in the organization. As mentioned in the introduction, well defined architecture standards do not live in solitude. The relationship between similar concepts in other parts of the organization, such as corporate strategy, policies, tech standards etc. should exist and maintained. The “art” of embedding is an important topic, because the linkages are essential but could easily lead to a rigid and complex system, inhibiting its effectiveness.

Architecture standards: Documentation

This is the third posting in a series on architecture standards. In the previous posting we presented some basic terminology. Most importantly, we distinguished between standard rules, and standard components. In this posting we pick up the thread and zoom in on the documentation of standards. In order to do so, we kick off this post with an analysis of how/ where standards are used, and “derive” a template from that.

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.

Architecture standards: intro and overview

Standards management plays an important role in many aspects of organizations. It is frequently seen as a way to improve costing structures, governance, IT-efficiency et cetera. Setting up a good standards practice is by no means simple and straight forward, though. 

This is the first in a series of postings on Architecture standards. The series consist of seven postings each covering a different aspect of the subject. In this first posting we will explore why an organization would care about architecture standards in the first place, and also what value a good architecture standards practice can bring to the table. For the content of this series we base ourselves partly on theory from architecture frameworks such as TOGAF , documented best practices, and our own practical experience and lessons drawn from several engagements with client organizations in which we helped building an effective architecture standards practice.

Covering the basics: keep track of requirements

This is the last posting in a series on TOGAF’s ADM. In this final post we zoom in on the Requirements Management phase which is central to the ADM. We will start this post with a discussion of the formal objectives, steps, inputs and outputs of this phase. After that we will discuss best practices for effective requirements management in the architecture space. We will end this series by discussion TOGAF and ArchiMate integration.

Dealing with change

This is the eight posting in a series on TOGAF’s ADM which covers phase H – Architecture Change Management. Phase H is not really a phase, but more a continuous activity of monitoring change as well as establishing procedures for managing this change.

Managing implementation oversight of projects

This is the seventh posting in a series on TOGAF’s ADM. In the previous posts we zoomed in on defining a vision, modeling baseline and target architectures, finding delivery vehicles for implementing the target architecture as well as defining a set of projects to implement the delivery vehicles. At this stage, we shift our perspective to implementation governance: overseeing the projects that were defined in the previous phase.

Translating opportunities to a well-defined project plan

This is the sixth posting in a series on TOGAF’s ADM. In the previous post we zoomed in on finding opportunities that help realize a desired vision. In this post we pick up the thread and focus on translating these opportunities and solutions to a well-defined migration plan.

Finding ways to implement the target architecture

This is the fifth posting in a series on TOGAF’s ADM. Following the ADM, we have so far prepared the organization for doing architecture work, defined an architecture vision and modeled baseline- and target architecture. In this post we zoom in on phase E: Opportunities and Solutions in which we find the delivery vehicles for implementing the architecture. As before, we briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Figuring out the baseline architecture and target architecture

This is the fourth post in a series on TOGAF’s ADM. In this posting we zoom in on Phases B, C, and D, covering business architecture, information systems architecture, and technology/infrastructure architecture. We briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Starting an ADM cycle with a vision

This is the third post in a series on TOGAF’s ADM. In this posting we zoom in on Phase A – Architecture vision. We briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Preparing the organization for EA

This is the second post in a series on TOGAF’s ADM. In this posting we zoom in on Phase P – the preliminary phase which prepares the organization for doing architecture with TOGAF. It may very well be that this is the most elusive phase of the ADM. We briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Implementing & Using TOGAF: best practices

Architecture has been around since the mid 1980’s. The most famous standard from that era is probably John Zachman’s framework for enterprise architecture. Many more standards have been proposed since, ranging from the IEEE standard, DYA, DODAF/MODAF, TOGAF, ArchiMate, IAF etc. A good overview (in Dutch) can be found in the book Wegwijzer voor methoden bij enterprise-architectuur.