Target Architecture
I had the pleasure recently of working with a client that had a very well-defined target architecture. They knew exactly where they wanted to get to and perhaps more importantly they knew why they needed to get there.
They had a defined target with defined business justifications for that target.
From a consultative perspective having this clear understanding of what and why certainly helps me to add value with the technical how.
But what if you don’t have a defined target architecture? What if you don’t know where you need to get to? What do you do then?
So what is a target architecture?
The target architecture is not about technology. The target architecture is about the business mission, vision, strategic plan and the capabilities required to fulfil those that the technology provides. The target architecture is therefore not defined by technological steps or upgrade cycles etc.
The target architecture therefore can be considered the plan for the organisation, based upon the business vision, mission, goals and strategy. It is the plan that governs the relation between the business, data, applications and technology. To provide direction for an organisations IT, it only needs to be defined at a high level.
It is often not possible to achieve the target architecture in a single step. It can only be achieved by breaking it down into manageable deliverable chunks. The sequencing of which is determined based upon organisational requirements.
Why do I need a target architecture?
If you don’t know where you are going, how do you know if you have got there? If you don’t know what direction you a travelling how can you correct your course? How do you know if these shiny things your installing are actually adding any value to the business? How do you know where you should be spending your budget, if you don’t know what the business wants?
How do you develop a target architecture?
The development of the target architecture can only happen with a clear understanding of the business vision, mission and goals. If you understand what an organisation is trying to achieve, then you can define the business, data, application and technology architectures required to support that.
This isn’t to confuse target architecture with enterprise architecture. EA is more than futures. Trying to see holistically, to see the whole, to learn from experience and the experience of others, to preserve knowledge and artefacts, define principals and plan. Target architecture forms part of that planning.
So in order to define a target architecture, you need to be asking broader questions about the organisational vision, mission and goals. You need to understand how the architecture can support those business goals etc.
Feed this understanding into the ADM cycle, kept at a high level, the output will provide something that can be used as a target architecture.
Hopefully, you have an existing understanding of the existing baseline architecture. Comparing the baseline and target allows the identification of gaps and reusable building blocks.
Congratulations, if you now know where you are trying to get to, what building blocks are reusable and those you are missing, then you can start to define the steps you need to take to move from one to the other. You can start to define transitional architectures.
Thanks
Simon