EA Voices

One of my interests is coaching, I’m a real believer in the positive effect good coaching can have on work performance, morale, clarity and general well-being. I also believe the techniques used in coaching is an essential part of the toolkit of an enterprise architect.

A few weeks ago I was talking to a colleague who happens to be an experienced coach who is also starting to explore enterprise architecture and specifically TOGAF. I’ve got a love/hate relationship with TOGAF, but it was really interesting to hear how my colleague, coming from a coaching perspective had approached TOGAF. He is now using the TOGAF ADM as what i’d term, a ‘coaching compass’. The idea of bringing up structure/method/map to coaching isn’t a new concept, but it hadn’t hit me how well the togaf adm (or at least the structure it implies) lends itself to being used to orientate a coaching scenario.

I thought this was an interesting way of viewing the ADM and coachign, so thought i’d jot down some of my thoughts off the back of this conversation.

Lets take a look at the ADM (and I warn TOGAF purists i’m going to take some poetic licence with the ADM) from a coaching perspective.

A coach could use the ADM from two different perspectives, either as a compass to guide an ongoing engagement (of one or more coaching sessions) or as a compass for a specific session

Here are some thoughts as to how each phase might translate into a coaching context

Prelim

Creation of coaching ‘contract’ between coach and coachee

A. Architecture Vision

Explore the goals of the session/engagement

B. Business Architecture

Explore possible target state of the people/process aspects of the goal(s)

C. Information Systems Architecture (apps and data)

Explore the tools (in the widest sense of the word) that might enable achievement of the goal(s)

Explore the information that might be required to achieve the goal(s)

D. Technology Architecture

Explore the fundamental structures that might need to be put in place to achieve the goal(s)

E. Opportunities and Solutions

Having taken phases a-d into account, explore the opportunities presented by what has been uncovered and the possible solutions that may help achieve the goals identified in phase A

F. Migration Planning

Having decided on a solution, explore the approach to implementing to achieve the goal(s) and the steps (transition architectures :)) to implement.

G. Implementation Governance

Ensure the planned migration and the chosen solution remains on track, this phase could take the form of simply returning to the migration plan at each successive coaching session

H. Architecture Change Management

The landscape and context for the coachee will change over time and between sessions. This is the opportunity to assess changes to the context that may affect the ways in which the coachee’s goals are to be achieved, or even the nature of the goals themselves.

Requirements

Instead of requirements, think of every phase feeding into testing/validating/changing the goals defined within phase A.

This is just a sketch of how the ADM might be interpreted in a coaching context, i’m not saying this is perfect, maybe its not even useful. but I think its an interesting approach that i’ll explore more during my coaching practice.

Many of you may be familiar with the problem. Especially if you use database applications in your everyday jobs. Sometimes the system stores things that are not entirely correct, or even blatantly untrue. Data pollution; that is what we call it. Somet…