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.

Objectives, steps, inputs and outputs.

Formally the objectives of this phase include a review of the organizational context for enterprise architecture (EA), identifying sponsors and other stakeholders, ensuring that everyone who needs to be on board is actually on board, identify scope and the architecture footprint of the architecture initiative, verify alignment and define alignment with other frameworks and methodologies as well as define principles and select supporting tools. A whole list which, in short, boils down to preparing the organization for doing architecture work by tailoring the TOGAF framework.

The inputs of this phase can be split into non-architectural inputs and architectural inputs. The former are such things as board strategies, frameworks for project management and governance, budgets, IT strategy etcetera. These inputs entail the overall direction of the organization. Since it is rare to start from scratch (green field), architectural inputs include such things as existing organizational models for EA, existing frameworks, principles and repositories.

Given these goals and inputs, the idea is that the architecture capability – with the TOGAF standard in mind – gets to work in defining the scope of the enterprise, and to make sure the architecture capability is firmly embedded in the existing organization. This includes obtaining approvals and support.

There are several outputs of this phase which mainly mirror its goals. The most important output, however, is the request for architecture work which is usually sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. This deliverable is one of the key inputs for the next phase – architecture vision – which is discussed in the next blog posting.

Best practices

In our experience, the preliminary phase is often underestimated in terms of importance and complexity. First of all, it should be noted that in doing architecture work: preparation is everything (note: the author of this post is a firm believer in rule #1 – be prepared!). Preparation means that people in the organization know what you are doing, and support the effort. Getting this right avoids the reputation of being an “ivory tower architect”.

Preparation also means that the right tools and means of support are in place. No carpenter would start on an important job without cleaning / sharpening his tools; nor should an enterprise architect embark on a mission critical to the organization without taking care of his tools including software, templates, methodologies etc.

The second aspect that was mentioned is complexity. We have encountered organizations where this phase was supposed to be completed in less than 2 days; the thought being “it’s all there in the book; all we have to do is delete the stuff we do not need”. In reality, however, there is a lot more to it. For example, at one large client we saw that executing the preliminary phase for the first time took close to three months (and involved a team of approximately a dozen architects), mainly because integration with existing frameworks was a lot more complex than anticipated.

In our experience, executing this phase should be a collaborative effort in which all the key players in the enterprise participate; from business to IT, from sponsor up to professional on the work floor.  Therefore, we usually follow a workshop approach in which we interact a lot with people all over the organization. 
Typical topics for workshops include the selection of inputs and outputs of phases, integrating the ADM with project management methodologies, or working on the content meta-model and standards information base.

Outlook

If you’d like to know more about our workshop cycle or the topics covered in this blog post, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.