I’m just in the last phase of a project: Handing over my baby eehmm, sorry, I mean project to the maintenance team. Looking back, I find that the project has undergone a number of phases, setting quite different demands on the technical leadership.
After this week I will no longer have any own assignments in the project, I will just be available for questions and helping out when needed. It’s always a bit sad to leave a project, especially this one that was a greenfield project where I have defined the entire architecture and written a lot of the code. Being an architect is equally much a leadership role as it is a technical role. Looking back, I find that there are five different phases that require distinctly different leadership.
We’ve all seen it: An architect explaining something with a sketch containing bubbles and arrows on a whiteboard. Sometimes the architecture is perfectly realized in the project, sometimes not. Looking at the sketches there are few differences. Why are only some possible to realize?
Let’s look at a typical system sketch drawn by an architect. (My skills at drawing in paint are even worse than my whiteboard sketches, but I hope you get the idea) The project using the design by this architect will be a complete failure. All attempts to build a system according to the architecture will fail miserably when the implementations of the components get incredibly expensive, while the result is a performance nightmare impossible to use for real work.
We’ll get back to where it went wrong shortly. But first, let’s look at a sketch that works.
Another architect draws this image. The project delivers high quality software on (or maybe even ahead of) schedule.
You can stop comparing. There is no difference. Actually, it’s the same image displayed twice.
So what’s the difference? The sketches are the same, but the outcome of the projects are completely different.