You started out using TOGAF. The Preliminary Phase proved very useful in helping to set up the enterprise architecture team, put in place all of the necessary governance and tooling, and tailoring the ADM to your needs.
But now you are in full flow. You’ve completed an iteration of the ADM for your first EA project and things went well. So well that the EA team is now in demand, and there are several stakeholders with important concerns that they want you to address. They are very keen for you to get started; as usual, they expect results yesterday, if not before!
Do you Really Need to Revisit the Preliminary Phase Again?
Or can you save time by getting on straightaway with Phases A to H?
These are questions I hear frequently. And certainly in many organizations EA projects seem to appear as if from nowhere, and there doesn’t seem to be any time to reflect on the nature of the project or make sure that everything is in place before the project starts.
Even if there is time to look at the new business directives, there isn’t time to take a serious look, again, at defining the organization-specific architecture framework, selecting reference materials, or improving tooling.
So I wanted to emphasize some of the really good reasons for spending time on the Preliminary Phase, before rushing off on another lap of the ADM cycle.
It is the Preliminary Phase that initiates an iteration of the ADM, and as such it is where you really get to understand the stakeholder concerns, objectives, and aspirations.
If you don’t get a good, clear statement of what is needed, then you are never going to have a successful iteration of the ADM. For example, if you underestimate the degree of change that is needed or fail to recognize the resources, funding or support that are needed during the Preliminary Phase, then it will be very difficult to get additional resources or time during later Phases.
Interestingly, TOGAF list the Request for Architecture Work as an optional output from this Phase; personally I would say that having a written Request at this stage is vital.
Major Change is a Responsibility That Extends way Beyond the EA Team
Every change initiative requires a different set of people. The Preliminary Phase is where you need to identify all of the other management, business or IT frameworks that need to coordinate with TOGAF.
Again, this is something that really does need to be done at the outset – it is so important to establish the proper responsibilities from the start.
The things we’ve discussed so far are covered by the first three steps in this Phase – Scope the Enterprise Organizations Impacted, Confirm Governance and Support Frameworks, and Define and Establish Enterprise Architecture Team and Organization.
The last three steps in the Preliminary Phase are the ones that are most often overlooked:
- Identify and Establish Architecture Principles is important because having these in place can save a lot of debate and decision-making time later. For example, an enterprise initiated a project to rationalize its customer-facing channels. The EA team defined a principle – “Common Processes Across All Channels” – which was later used in evaluation of architecture and solution building blocks, making it easy to reject any options that didn’t allow common processing.
- Tailor TOGAF and, if any, Other Selected Architecture Frameworks is important because there simply is no one-size-fits-all framework! The easy option is simply to pick a framework and keep using it over and over, but this is like picking a screwdriver and using it for every DIY task. The principle here is “A Stitch In Time” – it is better to get the right framework for the work you are about to do; it makes your work easier, saves time, and is more likely to deliver successful outcomes.
- Implement Architecture Tools follows on from tailoring the framework. Most EA teams muddle through with the tools that they already have in place, instead of thinking about putting in place something that might really help them. For example, an EA team started a project to rationalize the Application Portfolio; it was only much later in the project, after many frustrating attempts to collect information about legacy applications, that they thought of using a Wiki to allow subject matter experts to donate their knowledge. This would have been a huge benefit if it had been in place from the Preliminary Phase.
Yes, you really do need to revisit the Preliminary Phase! It is where you get first knowledge of the concerns you are going to address, and make sure that you have everything you need to be able to address them.
Those are two very good reasons for repeating this Phase. Underlying these tasks is the fundamental principle – being prepared, and having the necessary capability and tools for the job at hand.