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.