I was thinking and working a lot about target architectures. Usually it is expected that you as architect will define a kind of map, which can be interpreted anyone in the company and reach the shiny targets on low cost zero time and no business outages. I would not say that it is not possible, rather if you plan cost, timing and migration phases but it is far to be simple. The real issue is that a target architecture is a collection of demands driving to ideal situation, which is not necessarily the place you would be; and the price tag, the duration and the full freeze of "disturbing" changes to reach the ideal situation makes most of the target architectures unreal. Let's see why!

As it is described in the pre-word the target architecture is a hard thing to do. The first problem is to define what is the scope of the target architecture. The most usual way I saw is that the target is defined for application using a landscape view. Sometimes this landscape is a kind of table where lines are business functions, the columns are representing business lines and the steps are shown in separate landscape tables.

The nicest part of these landscape steps that they will have due dates, cost estimates for all the changes - they are together the architecture roadmap and the list stage is the target architecture. This is way which is simple to communicate and probably this is the reason of this way being so popular. Popular, simple to communicate, what is the problem?

The first issue is, that the steps of this roadmap usually miss the real business needs behind them. The missing business requirements mean a technology only approach which will never be funded by corporate management. OK never is too strong word here since there are some cases when you will get fund but then you will face the second issue.

The delivery organisations are conditioned to deliver under customer pressure. If they are the customer of themselves they usually miss the focus since no one is prepared to be self-motivated to deliver. These are the projects, programs which never be finished by the original target: ideas come to be more perfect; changes to have better maintainability but losing the usability; brand new but still not proven technology to try; and so on. This is the place where never is really the right word to use.

Turn to the next kind of problem. You have to make timing and cost estimates in an environment, which is absolutely out of your control. Usually there is no business roadmap on that scale as technology roadmaps and target architecture plans are made, therefore you cannot calculate the "side-effects" of them. I mean you will face non-expected business requirements what are opposing the target architecture. All time. That means target architecture will be the hotbed of conflict between the well-prepared technology and stupid business people; or between the progressive, flexible business guys and the slow, bit-brained technology elephants - it depends what is your standpoint. Tell me if you never heard this kind of stories.

Last but not least take a look about the need to be understandable. I like to represent the future which we have to prepare the target architecture as a labyrinth. Assuming the representation is fine do you feel that the landscape pictures are covering the roadmap of a labyrinth?

I mean the roadmap of forward-right-left-left-right... all together this solution has more than 100 steps, some of those are certain, others are not. How to communicate this for the "mice" running in the labyrinth to let them feel safe?  Not simple...

What is the outcome finally? Do not prepare target architecture? I would say you have to, but please don't want to be Nostradamus!

The key word is to interpret architecture as a verb, not a noon! You have to define principles, KPIs which helps to auto-solve the labyrinth instead since the it can be changed as the time is going. I suggest you execute architecture management on the "opportunist" way. Having the right auto-solve approach you can identify incoming business needs, which will help you to go towards the expected target, what is defined by the principles and KPIs, but not by a drawing. This approach certainly allows you to be proactive or generative and suggest business demands, which is serving your targets instead of passive waiting.

Back to the labyrinth. The next picture shows some alternative way by blue, which drives you forward. Some of them are shorter, others are longer. At the time you will reach the junctions the actual demands will describe which direction you will go: red or blue.

This picture shows also a bad example with a brown line which leads to a dead-end. This is the classical example of short-term advantages, like implementing a front-end solution consist all necessary business logic, instead of having a common component which will be usable by all the front-end channels together.

You as an architect has the helicopter view to prepare labyrinth solution map, but you will not be authentic if you use a loud-speaker from up there. You must land to the be a "mouse" together with the others. Show them your map and lead them towards the good direction as Lead Architect (Architect roles and responsibilities). As you are there in the team and you see where you are, sometimes the best solution is to start breaking the walls: instead of running long you can have a short-cut.

On the other hand, please listen and be patient if there are no business demands which are leading you on the shorter route. Never forget, that enterprises are built to make profit, which requires revenues. Sometimes the shorter routes are not generating the incomes, therefore you have to run longer to get the money, make more profit and get funded on the next step. We architect are not serving the "architecture beauty" but the business success.

Let's see how this approach fits to the crazy example of change the engine of the airplane while it is flying. The usual try to reach the target is a transformation program, like a one-stop journey: plan for more stops with one of them changing the engine. Then you will change it during the journey but not during the flying!

Last but not least a message: you will get using this way that you are lucky having successful projects and more matured architecture. Yes, you are. Since fortune is when opportunity meats preparedness!

You have your principles, your KPIs, the helicopter view, you are prepared to land to be a "mouse" - you are prepared. There is nothing else to do just wait for the opportunities (or generate them)!