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.

Objectives, steps, inputs and outputs.

The official TOGAF 9 specification lists a wide range of objectives for phase A. All of these revolve around two things: developing a shared vision of where we want to go, and obtaining approval to move ahead. These goals reflect the fact that (most) architecture work in the context of the ADM has to do with controlled change in the enterprise.

Formally, this phase starts with the receipt of a request for architecture work from the sponsor in the organization which outlines such things as the strategy of the organization, business goals, high level description of what is to be achieved including time constraints etc. This document is a key source for deciding the scope of what is to be delivered down the road.

A key step in this phase consists of a stakeholder analysis which is essential in making sure that all the bases are covered. Doing this well will avoid a lot of issues down the road, as commitment and buy-in from key stakeholders tends to go a long way.

The definition / documentation of the vision itself may contain a first cut at a birds-eye view of the baseline and target architecture to be achieved by the current ADM cycle. At the very least, one must make sure that each of the domains (business, information systems, technology) are covered in this vision.

The vision is documented in the architecture vision document  (a high-level, aspirational view of the end architecture product) and the statement of architecture work which complements the request for architecture work (the latter formally defines scope of the initiative). Therefore, this phase can be thought of as a “handshake” between the sponsor and the architecture team: a joint venture in making a request and promising to deliver on that request.

Best practices

There are several pitfalls in executing this phase that can easily be avoided. Keeping in mind that this phase is all about a “handshake” will prevent most of them.

First of all, it must be understood that this phase is executed in close co-operating between the sponsor and the architecture team. We have seen only too many situations where this phased was implemented as a “paper monster” in which many versions of request and statement are pushed around. To prevent this we propose to follow a workshop approach and merge the request and statement documents. This will both increase understanding and buy-in of all parties involved.

A second best practice in this phase pertains to documentation. More and more organizations use a formal architecture modeling language such as ArchiMate or a profiled-version of UML. Even though we strongly recommend using a formal modeling approach in conjunction with TOGAF, starting too early with modeling will only hinder the creative process.

The “best” approach depends on preferences within the group.  However, in our experience a 3-step approach works best: (1) the key sponsor (frequently a single individual develops an idea and outlines it in half a page of text; (2) the architecture team facilitates a series of workshops in which the idea is further developed, using various brainstorming techniques and back-of-the-napkin style diagrams; (3) the end result is documented in high level diagrams in the formalized diagramming technique (preferably ArchiMate) adopted by the organization.

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.