Having worked through a number of large scale IT projects, migrations and transformations, I thought it prudent to share some thoughts around these three, commonly used yet commonly misunderstood, Architectural States: ‘Current’, ‘Transitional’ and ‘Target’.
All architectural strategies must consider at least two of these, the Current and Target states and some, well any which are not pure big bang releases, will include one or more transitional architectures.
What are these states for and what do they mean?
Current Architectural State
This is the current state of the architecture, in a greenfield environment this is essentially a blank sheet, but that is still a valid Architectural State and it’s important to recognise it. The Current architectural state describes the ‘where you are setting off from’ at the time the project or programme is destined to start. If you miss the start date you need to understand that due to the changing nature of the business, the Current Architecture is also likely to change.
The current architecture must include a full understanding of the systems involved along with information such as:
- Which SBB’s (Solution Building Blocks – or ‘bits of software’!) are being replaced or phased out
- Licence renewal dates for SBB’s
- What each piece of SBB is currently being used for
- What each SBB is capable of (e.g. a document management system may also be capable of publishing but that capability is not currently being utilised) – saves buying unnecessary software
Often we see that architects especially at the Enterprise Level ‘do not want to be constrained by existing legacy systems and processes’ and therefore ignore the current architecture. Whilst it is important not to be constrained by current systems and processes it is equally important to understand that at some point you need to move the Enterprise to the new Architecture, from where you are now. That is unless you are just turning off the old enterprise and do not want any legacy information at all (which is unlikely).
Current architectures can be very difficult and time consuming to collate, from my experience any enterprise that has ‘grown organically’, or went through an early idea of ‘Agile means no documentation’ phase will have a number of significant challenges creating this view.
The target Architecture is the ‘end goal’ of the project, it describes a view of the world when the project has completed and all development has been completed. However, it is important to understand that for any project of any decent length, until we have reached the target architecture we will not really know what it looks like.
This uncertainty is simply due to changes that will undoubtedly occur during any project’s lifetime. I am personally always wary of anyone who will not start until the target architecture is fully documented, whilst having this would be comforting, it is likely to be false comfort. Target architectures should define enough to give the project confidence that the architecture can deliver, but not too detailed to make changes difficult to manage. This is true of both traditional style (e.g. waterfall) projects and agile projects. The recognition of this uncertainty is one of the key reasons for the Agile movement gaining so much ground.
I cannot emphasise enough how important it is to see the target architecture as a current understanding rather than something that is set in stone. If you communicate that the target architecture is going to evolve with the business, development and technical designs will be created to be flexible not rigid and small continuous change will be simpler to accept. If you communicate it as fully designed to the n’th degree, you are likely to fall into a trap that many long running waterfall style projects have in the past. By the time you have arrived at your target architecture, both or one of the business or technology have moved on whist your project has not. Of course you can manage this by change requests but it is likely this will be more difficult as technical design and development will probably have been done to meet the target design to the letter. Oddly enough I often see Agile teams developing stories to reach the ‘definition of done’ for that story, leading to systems that are difficult to change, this again can be attributed to not fully understanding that the product of that story may change once it has been completed – it’s Agile after all! (sometimes however it may also be down to having a scrum master breathing down your neck!).
Be careful of having too much belief in the target architecture when outsourcing fixed price contracts, always break them down into chunks that can be delivered in a short time frame. Whilst complex fixed price contracts with a ‘fully defined and point’ can offer some feeling of safety as ‘the risk is on the supplier’, in reality the risk is in how well you can communicate your requirements to that supplier, how you are going to manage changes during that time, if your supplier’s design can cope with that change, how much your supplier will cost those changes for, and how willing you are to not have those ‘should have’ requirements. Not all suppliers take advantage, but I have often seen fixed suppliers rely on changes to make the real money and also use the lack of clarity in specifications to justify delivering code that does not work well.
A target architecture will include not only the vision of the systems, descriptions of how they will interact, and architectural and business principles and goals, enough to ensure that everyone is working towards a similar goal and in a standard and consistent manner, and that we can understand when we have delivered some view of what was originally asked for Business Goals.
These are ‘Mini Target’ architectures that help us get from the current architecture to the target architecture in a series of mini-steps rather than one big bang, and are often shown as ‘architectural plateaus’ (giving the impression they offer a rest bite in the change process).
These transitions could exist for any number of reasons including:
- Just to de-risk the project (transitional not big bang), see the discussion on architecture transitions here.
- To take into account the need for pilot phases
- To take into account other projects in the enterprise changing the landscape whilst we are delivering our project.
- To take into account key business dates
As discussed above, at the outset of a large scale project or program we are not 100% sure of the target architecture, but we should be sure of the current architecture, therefore we should have more confidence in transitional architectures that are nearer the current architecture than those that are closer to the target architecture further off in the distance.
In essence a technology project or program can be seen as a journey from where you are when the project starts (Current Architecture) to where you intend to get to (Target Architecture), and any of the key waypoints that you expect to pass on the way (transitional architectures).
Traditionally project teams have viewed IT projects and programs that get us from defined point A to defined point D possibly going through defined points B and C. Unfortunately, this leads us to design solutions specifically for points B, C and D. However, experience tells us that in any project that is likely to take more than 6 months, point D is likely not to fit the business and technical environment by the time we get there. We are after all, I assume, setting off on a journey that has never been travelled before within a given enterprise where the landscape is ever changing.
It is much better to have a solid understanding of where you are setting off from, and have confidence that the tools that you are using will get you where you want to be. That means you and your development teams have to embrace change as part of a normal project process.
Whilst this could be seen as a glowing recommendation for ‘Agile’ approaches, it possibly is to some degree, but remember that there are many development methodologies and even mini-waterfall will fit with the discussion above and there are many projects where Agile is not necessarily the best solution.