Phase A - Vision Phase

Introduction

The TOGAF® vision phase A gives the architect the opportunity to spell out and sell the merits of the current iteration of the ADM. It can be visualised as performing phases B through to F at 20,000 foot. Imagine yourself sat in a plane at 20K ft cruising above a city. What do you see? You can clearly make out the structure of the city, the main arteries, the zones of the cities, the flow of traffic between those zones, an outline view of the utilities (those that are above ground, such as water and electricity and possibly some gas lines). Phase A can be considered similar to a Project Initiation Document (PID) or a BID document (obviously this will vary from organisation to organisation).

Phase A - Vision Phase Mindmap

Collateral

Phase should encompass the analytical activities of phases B through to F as shown in the figure below.

The architect should engage in a process of examining the Business, Information and Technology domains of the enterprise.  These phase can be tackled in parallel or in series.  If done in series, which one you start with depends on whether the driver for architecture work is business led or technology led.  An example of the former being: your company has decided that they wish to expand into a foreign market in which they have no experience.  An example of the latter being: a large technology company whose operating system you heavily dependant on has announced that one of their leading operating systems will no longer be supported in 2015.  In either case an evaluation of both drivers must be done, the former being a top down process and the latter a bottom up one.

The models

The models you produce at this level, should be high level candidate building blocks, solution (SBB) and architecture (ABB).  The thing to note about this phase is that you have to learn to abstract at the right level of detail for your target audience.  This is not easy if you've never modelled using classification techniques.  As to whether you start with SBBs or ABBs is very dependant on how you process information, whether your starting from a clean sheet, or whether or not you have a decent enough baseline view of your world.  Wherever you start, you really are looking to capture your world in terms of ABBs.  Remember ABBs are less volatile than SBBs, as concepts they hold well through time, are not affected by the vendors desire to change the implementations because technology has moved or so as to create a market space of parts replacement.  For example the concept of a car hasn't changed in over 100 years, but the there have been numerous implementations of this concept, each bringing to the market varying qualities with varying strengths to those qualities.

Phase A should encompass a 20K ft view of B, C and D.  It should specify the solutions that currently exist in each domain (if there are already existing solutions) and their logical specifications.  The figure below illustrates how this acheived

Be careful in noting that the target solutions are not selected till phase E as shown here

This apporach lends itself to a gradual evolutionary model.

The examples above clearly show a baseline first and target last approach which generally suits an evolutionary approach to doing architecture.  But what about target first and baseline last?  The danger here is that the proposed solution is so far from what is already in place that you could have a revolution on your hands, in some cases this may be acceptable.  In this situation you would want to develop abstract models (ABBs) of the target state, followed by identifying the possible solutions (SBBs) to those ABBs.  What comes next is dependent upon time and available resources.  You may have to very quickly harvest the current landscape and produce ABBs of the current state., if time allows you may be able to harvest the current landscape and produce SBBs and ABBs of the current landscape.  Be careful that harvesting both ABBs and SBBs of the current landscape doesn't become an exercise in irrelevance especially if the current state is to be completely replaced or something similar (in such a case detailed knowledge of the current state could be satisfied through detailed ABB specifications).

Once you have a decent collction of roadmaps for each of the domains, work can begin on producing consolidated roadmaps using techniques such as tube maps.  This would be done in phase E.

Key TOGAF® Activities

There are a number of key activities you should engage in at this level, some of these should be followed through in phases B, C and D when they are done in more detail (2K ft).  They are shown here not in any particular order... 

1. Clearly specify why you have been engaged, the RAW (Request for Architecture Work - this would normally translate to some standard document within your organisation, like a PID)
2. Risk of engagement and none engagement, and how these risks will be mitigated - extremely important that this is covered as early as possible to ensure there are no hidden gotchas
3. The development of a communications plan, stakeholder management techniques: www.mindtools.com and the stakeholder views ad viewpoints.
4. The identification of building blocks - it's common to have stuff (systems and processes) already in place, these are your current state SBBs, map these out as current state ABBs
5. The development of an engagement programme (TOGAF® makes use of BTEP, but other tools might be available to you)
6. High level migration and implementation plan - you would be expected at this level to draft out a high level migration strategy, no one is going to invest in a piece of work without seeing someting like, with estimated costs, timeframes and resources

Risk

Risks should be identified as early as possible and monitored throughout the whole of the ADM cycle.  You should think clearly about the risk to the organisation of engaging in a program of work that could lead to financial loss and loss of credibility.  The risk could also be the time it would take to complete the work.  If it's a lengthy engagement, are there competitors that could steal the market share before the programme is completed?  Is the technology required to do the task at hand available?  Does the organisation have the competencies to do the work?  There are so many things to consider that risk modelling should be seen as a separate work stream in its own right.