So – what is a target architecture anyway?

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



Pragmatic architecture: just enough, just in time

Most people who have been part of an Enterprise Architecture initiative will at some time have suffered from the scenario of significant investment with no apparent return, where a team will decamp to document rich architectural assets that no-one outside the team finds out about or uses. This reinforces the perspective outlined by the old joke: “what’s the difference between the architect calling in sick and the cleaner calling in sick?” …. the answer, of course, is that someone eventually notices the cleaner is missing.

Unfortunately, this is often closer to reality than many in our profession would care to call.

My pragmatic antidote to this is to produce “just enough” architecture “just in time” – in other words, build out the estate of enterprise architecture assets in line with, but just ahead of, emerging project needs. A simple principle to articulate, but needs a level of groundwork to put into practice. Even in the best of worlds, it feels a little like the train chase scene in Ardmann’s The Wrong Trousers, where our hero is desperately trying to lay track in front of the model train he is riding, which is why it is key to have the right pre-requisites in place:

  • An agreed framework to document the assets. The meta-model, or architecture-for-the-architecture and the tooling used needs to be agreed up-front by the team, or the wheels will rapidly come off the bus; a sprawl of ad-hoc assets might just as well be produced by disparate project teams themselves
  • An agreed framework to govern the assets and the projects which will consume them. Without at least the basics of this in place, no progress at all will be made. The process of engaging with projects is the hinge on which a successful architecture turns. Key to this is early awareness of business demand; the exact process, or the level of architecture authority is secondary to being able to engage at the project inception point.
  • An approach to prioritising the assets needed. There is rarely time to produce the breadth or depth of the assets you would like, so what does “just enough” look like? An approach I’ve used effectively is to create a use-case model for architecture, in other words, treat your Enterprise Architecture as any other systems, and take the time to understand the users’ requirements. Who are the actors that will interface with the architecture? What questions will they want answers to?

Each of these require further exploration in their own right, and of course assume the existence of an architecture team.