I don’t know about you, but I’ve heard the term “target architecture” bandied about many times over the years. Given my role, I’ve always felt that I should have a perfect understanding of such a thing, but I’m glad no one had ever really pressed me on what it is, as I feared my answer would be a little vague. However, last year, someone did ask me and I needed to deliver.
A good starting place is what you might call the “classic CIO view”: there is a picture on a page, with many colourful boxes (and possibly some lines), and probably some of the boxes crossed out, when nirvana is reached, and all the complexity is eradicated by the next major transformation programme. Like most of my peers, I have used such things many times, and they do have value – but also limitations. The value I see as follows:
- You can show the major application systems that are expected to remain at some future point
- You can illustrate the major supporting platforms that are regarded as strategic
- You can give very simple illustrations of the types of architecture patterns you prefer (for example, SOA-style, cloud federation, and so forth)
This is useful, but hardly comprehensive so cannot stand alone.
The next lens, which I would consider a “classic” piece of enterprise architecture: an Application Portfolio Management view, where each major application is annotated with Invest, Retain, or Retire – or if you go with Gartner, then form a 2×2 quadrant map with TIME: Tolerate – Invest – Migrate – Eliminate. In this case, the Retire category is split into two, those where you need to retain the business function/data, and those you can just switch it off. The value of this lens is as follows:
- You can use this as the basis of a plan for what to do with each application
- You can challenge the scope of solution definitions to focus more on investing in the right places, and use this as the basis of a success measure
Again, useful, but what you can’t do with this view is give any real guidance to a delivery function of the standards, patterns and topologies in the target, and provide any information of how you’ll get there – so to represent a rounded target, this needs to be supplemented with a series of architectural deep-dives which will usually be focused around a small set of related applications and/or platforms. This third lens will typically be a lot more detailed and include the following:
- Detail on the current state: technologies, topologies, functions, data stores; and also pain points that need to be addressed
- Detail on the target state: technologies, topologies, functions, data stores; and also the benefits that will be realised by the change.
- A high level roadmap of the key steps in the journey from current to target
Most enterprises are too large to attempt this type of analysis across the whole estate – this approach allows us to use the Just enough, Just in time approach as we see the interest and need to approach a specific area. The resulting roadmap can then be used in one of two ways: To guide emerging project solutions, or to make a standalone case for investment in a strategic IT-led project.
For completeness, there will be more assets you could consider part of the target – in particular patterns and standards which identify preferred platforms and technologies, and other ways of working.
So, if you get asked what a target architecture is – these “big three” may help:
- A big picture view on a page PLUS
- A high level application portfolio view PLUS
- A series of deep-dives leading to associated roadmaps