8 reasons not to leave architecture to the end of a project

Sometimes I see architecture left until the end of a project. These 8 reasons are the reasons I normally try to push for it earlier.

There have been times in the past where I have been pulled in at the end of a project and told that the project has implemented a technical solution and there’s a requirement by the customer for it to be documented and when that happens I get a little sad inside. In large projects one person never has all the information. This blog is from personal experience from working at different companies over the last 25+ years.

Its worth mentioning at this point that design doesn’t all have to be done at once in a waterfall fashion it can be agile. I will talk about this in later blogs.

Documenting architecture always has value, but much of the value you would get from an architecture practice has gone if you start doing architecture at the end of a project. The bigger the project the bigger the problem. Lets get started:

1 – It takes more effort doing it at the end.

When you do architecture at the end of the project you have to take time to understand everything that’s happened. This includes understanding how requirements have been realized and what decisions have been made

As you start to understand the scope and concepts behind a solution questions arise. I might go to one person and ask the answer – they typically wont know. or may have part of the story. They lead me to other resources and it could take me hours of time just to find out why a single decision has been made.

If a team had been working together on a single architecture throughout a project you don’t burn that investigative time trying to understand things. It’s not always obvious what necessitated a decision, so its important to track decisions in a single place.

2 – Its expensive

Time is money – exploring the rationale behind decisions and understanding whats happened at the end means having to engage lots of people. If an architect has a meeting with three technical specialists for an hour that’s 4 hours of work time. When they don’t have the answers to hand – they have to write emails, contact other people, and come back to the architect – that’s also burned time. If the decisions had been put into an architecture as they were made, in some projects its possible to save hundreds of hours.

The same idea applies with things like requirements realization. If you haven’t shown exactly how each requirement has been realized in architecture you will have to investigate each one. If you are in a project with a 1000 requirements and spend 15 minutes investigating each requirement then potentially you would have to spend 250 hrs just figuring this out (more, if you consider you need to engage other people).

Map the requirements at the beginning of the project and make sure you create some kind of requirements realization within a project. Keep a log of all the decisions made, together with the activities taken around each requirements together in one place. This extra effort will save time and money as a project moves on and resources come in and out of projects. It will kill the need for new architects (or other people) having to “investigate” to understand status at the end of a project and will reduce the number of meetings you need during the project.

3 – Its hard to build well under time constraints

At the end of a project there are normally time pressures because people want to shut things down.When I am having to investigate the architecture designs and their rationales, I need to take time. If organizing a meeting to understand how we realized one requirement takes an hour, and may not yield the result – other meetings will need to be scheduled in. In a situation when you are given a week to deliver a design near the end of a project – that time disappears very fast if you need to have multiple meetings and rely on peoples availability. This puts deadlines are at risk.

If we are building the architecture throughout a project there is no rush at the end of a project.

4 – Information gets lost

If decisions are made and not recorded in an architecture information very easily gets lost. In large projects many people are involved – sometimes resources get replaced over time and we lose information on why decisions were made. Sometimes that information is recorded but we don’t have access to it. If you have a large project spanning 6 months, that is running a project meeting every morning where they make decisions that’s potentially 120 sets of meeting minutes – assuming those minutes are kept properly and all the information on decisions is available you still need to sift through it. Of course some people make all their decisions in email, sometimes people leave the company, some also forget or don’t write things down.. In these situations you have real problems.

Keeping architecture concerns and decisions documented in a work log as part of your architecture design process throughout the project mitigates this risk. Having that log available on a collaborative platform is essential. if you have to take a conversation in email – paste that to the collaborative log too, so everyone knows everything that happens and there are no hidden caches of knowledge.

5 – You find things that are missed

When you take a structured approach to analyzing requirements and creating a requirements realization view for your solution, things don’t get missed, because an architect is guiding work. This is one reason why we do architecture design in the first place – to make sure a solution is fit for purpose. I’ve often seen functional requirements well considered by a technical team but non functional requirements missed. A technical team tends to focus on things like getting a server up and showing a tangible result.

If you come to the end of a project and suddenly realize the technical solution doesn’t meet your requirements, you are in a bad position. It’s too late to rebuild or change technologies. You may end up having to compromise quality just to get the project ended, or investing a significant amount of time and money re engineering or rebuilding a solution.

The earlier you do a requirements analysis the earlier you find gaps. The hard and sometimes boring requirements analysis part at the beginning of a project is essential. You must make sure that every requirement is realized in a view. At this point you should be also ensuring every requirement has an owner that is managing it. The project managers can then more effectively chase up project status without having to call lots of expensive meetings.

6 – You’ve lost the benefit of concerns management.

There are two ways you can approach things. You can put out a fire in a burning house, or you can stop the fire from happening in the first place, by taking away the matches from the idiot that likes to start fires.

When you are doing architecture properly you are identifying and managing risks before they happen by applying thought and designing things to stop issues from arising. A design uses the shared experience of all those involved to avoid problems rather than the experience of individual resources. Of course you can also reuse designs, but that’s another story.

On the flip side, you can leave implementation of projects to technical resources. and manage concerns as they happen. When this happens you have an escalation culture. You normally end up with managers and a lot of emergency meetings to handle problems, often after the project is implemented, leaving a sour taste in the mouth of both operations and the customer. This is very expensive because its a lot of burned meeting time because you are handling the after effects of a fire happening; which also includes a level of damage control. If a house has caught fire several times during a project the damage has already been done. I’ve seen before entire platforms have to be rebuilt because technical teams have rushed to implement a solution without realizing the requirements or dependencies of other systems around them. I have also seen the same problems reoccur.

Concerns cannot be managed at the end of a project because you cannot go back in time to fix them. The only thing you can do that’s cost effective is manage them as they happen or suffer the cost of potentially needing to redo things.

7 – It ends up frustrating people

When you have the end of a project in sight you want to cross the finish line, the project don’t want to have to deal with an architect coming in at the last minute and finding holes in their work. It frustrates everyone, architect included. If you have left architecture to the end the chances are the budgets are depleted and people are exhausted through overwork because the plan that was executed wasn’t designed and work wasn’t properly estimated. The last thing anyone wants at that point is to realize a technical implementation is not fit for purpose when they cant do anything about it – thats demoralizing.

8 – It results in lower quality

When you consider everything above you will realize at the end of a project to get architecture documentation out, you are going to have to compromise. This for me personally is very hard, because I always want to deliver the best. It may be that the documentation will end up at a high level, or it may be that some concerns will just have to be accepted rather than mitigated. It might be that we need to make assumptions about why things were done, or that we don’t get to model our solution because there just wasn’t enough time. The team may have made costly mistakes during the project. At this point you have ran out of time to address all the concerns.

Its very likely that the quality of architecture will be lower if you used the time at the end of a project just to document architecture, rather than following an architecture practice during a project. Its also likely that because of this approach there will be issues arising once a project goes into service.

If you have viewed architecture as a documentation exercise at the end of a project the chances are that what is implemented doesn’t address all of your own internal non functional requirements, the customers requirements, or other stakeholder needs – because the time at the end of the project was focused on describing what has been put in place rather than what really needs to be put in place.

Architecture and security non functional requirements normally exist to ensure we meet the standards our companies promise, they are designed to protect the company, to mitigate risks risks. They also may address the needs of internal stakeholders and may have been put in place to ensure we learn from the mistakes that our predecessors have made. . If we haven’t designed a solution to meet the needs of all of our stakeholders, then we may well see the same issues reoccurring time and time again.

There’s no worse feeling in the world than having to present forward an architecture that you cant justify or isn’t as good as you would like it to be, because of things that were outside of your control. In such cases I think its always important to be honest, to present the architecture, and also the concerns that you have on it at the end of a project so they can be addressed by other architects or your quality team.

To raise quality we also need to raise awareness. architecture may be difficult and laborious at times, but as I have mentioned in this blog, people need to know the benefits of not leaving it to the end.

Improving ArchiMate Model Quality

I get models and diagrams presented to me in many different forms and levels of quality. In this blog I want to look at talk at improving ArchiMate Model Quality by telling a story with your Archimate views, and covering some other basics.

Telling A Story

When I produce a new diagram I will tell a story with it – I will walk through the diagram and try to put it in a number of sentences, and I will think about the value that the view is trying to express to its stakeholders. I will show a fictional example of a motivational view that looks similar to what a junior architect may produce:

Figure 1. A diagram produced in a training

What it effectively says:

“We have a requirement for data protection, identity management, and ease of access. We are driven by a need for security services for Microsoft cloud. This has a positive effect on our goal to have end user identity and access.”

It doesn’t really tell me much – I had to look at the documentation for the elements hoping in particular to find if the requirements had rationales, and impacts defined. I was a little lost to what the author had to say.  I normally start by looking at the drivers. Security service for Microsoft cloud didn’t make sense, as it is not a reason to do something. In strict terms I would question the value of this view. If I didn’t actually know a little of the subject matter may be really confused. 

Finding Some Value In Confusing ArchiMate Views

The diagram above was easy to put into story because of its layout – it was easy to follow the flow of the thinking because the arrows went in a single direction from point to point, even though the actual story was a little confusing from an strict ArchiMate perspective. In some cases where relationships flow in many directions its hard to tell the story. As a disciplined architect its easy to get a little confused when you get a diagram of the quality i have shown – because its arguable that those requirements should be goals, etc…  The usage of the elements is wrong. To get clarity we need to forget the strict definition of the elements a little. If you look at it below, a non-architect may actually find this easier to understand.

Figure 2

I could have taken the influencing relationships off the diagram; and start to think about reworking it. Sometimes when I get models from less experienced architects in my head I am doing exactly as above – trying to understand the thought behind the structure – it normally helps me get some kind of value. I of course do the same thing with the relationships as with the blocks. I am abstracting away from the modelling language So the diagrams above provide some value but not much – if we had strictly understood the usage of each element type and each relationship the diagram would look significantly different – and would fit into a larger architecture in a way that makes sense.

It wouldn’t make sense to reuse the elements in this because they are ambiguous and incorrectly typed – so the value to the overall architecture is greatly diminished – although we cannot make things better unless we have a starting point – and I would be positive towards the architect because this is a starting point for improvement and we can now start a discussion around the things that either the architect or the stakeholders find important.

Looking at a better view

With motivational layer diagrams I normally start by looking for the drivers – the reason why, add a few assessments – and work from there.

Lets look at another view:

Figure 3

CWAD Is Consumer Workspace Architecture Domain – a team I used to run. The story this tells:

A CWAD architect, domain lead, product manager  and service delivery manager are assigned to do CWAD road mapping. this project will deliver a product level road map, concern and motivation views, and work package implementation and migration views. This project needs to ensure that each service work package is mapped onto a product level road map, is properly scoped, and that rational and related concerns are clearly identified;this will all give us improved trace-ability into CWAD workloads.

The story was easy to tell for a few reasons.

  • the arrows clearly go down the page and flow the same way
  • The different layers (business, implementation and motivation) are clearly grouped together
  • The elements are well named and typed.
  • The author is clearly telling a story in the views design – including everything that the reader needs to understand the scope of a project.

When I am trying to read a view in general I start with the business layer, or strategy layer and then work down following the arrows.  Within each of the layers I look for the external elements and work inwards – so I will look for external behavior elements (services) and other external active structures (such as interfaces) – and will work from there. A good diagram will highlight those elements.  In the diagram above its easy to see because the business layer active elements are at top – and flow downwards towards the other elements.

Ordering Elements

When creating diagrams I try to follow the order of things in the ArchiMate core model – if i have strategy elements they are on top – the Business, Application, Technology, Physical, Implementation & migration, going down the page with motivation elements on the right hand side because it connects to all layers. Sometimes it doesn’t make sense to do it that way, but as a rule of thumb, you end up with nice consistent models. Having relationships crossing over each other will sometimes push me to changing the order of things; ultimately we try to tell a nice clean story that makes sense. You have probably seen the Archimate Full Framework which has a nice diagram of the layers – I don’t publish it here because that image is under copyright.

It can be tricky to do take that approach on occasions, and you can be forced to do things very differently – This particularly happens to me whenever I do things with implementation and migration because you can be realizing elements in multiple layers, or with requirements realization views that have motivation elements everywhere. I still try to group layers together but its equally important to stop a spaghetti view with relationships crossing everywhere. Another reason that following the flow of layers in the full framework is a good idea is because of the way some of the standard viewpoints fit together – for example Service realization goes from Business to Application – Technology usage sits beneath it connecting application to technology. 

People in the western world find it much easier following diagrams that go from top to bottom – or left to right.  There are of course times that you cannot avoid to have arrows in different directions. Sometimes diagrams have to be complex. As a rule of thumb if a view has more than 30 elements i think about breaking it out into a separate view.

Some other miscellany

Some general things I do to keep things tidy and consistent: 

  • Avoid relationships crossing each other on the canvas – sometimes this will end up as a jigsaw puzzle and its not always possible. But mostly it is.
  • Don’t use diagonals – I use right angled connections.
  • Resize boxes to highlight importance – on a service realization view – I will make the service big. 
  • Resize boxes to make the line connections simpler. See figure 3 – i made the work package larger in order to avoid having to bend my lines.  the association relationships now go straight down. 

Summing it up…

These are more guidelines than rules. There are times where its not practical to follow all of the formatting suggestions i have put forward today, and that’s OK. The most important thing to remember here is that every view you are creating is telling a stakeholder a story. We need to do that in a way that makes sense, so we have a little creative licence. 

Don’t be shy about getting your views peer reviewed by friends – or asking them to tell your story – it will help you improve your game. Ant view is better than no view.

The more we model and review – the better we get – there’s no one way to do things – but practice will improve your game.