Why Do We Need Software Architects?
ByAnother Blast From The Past Article – Originally Published in Sept. 2003
I am a software architect, but I’m not a “Blue Sky” thinker; I’m more of a practical thinker. I asked myself some questions about architects. What is a Software Architect and why do we need them? What do we expect from architects and why not just have a tech lead? Is there real benefit in an architect and are some projects too small for an architect? If so, what qualifies a project as needing an architect?
I believe and practice iterative development techniques and agile methodologies. What I have found, is that even in the agile world, a strong architect can make a project and the lack of architecture (or more properly – architecting) can foil a project’s success. Martin Fowler has written an excellent treatise on Software Architects – Who Needs an Architect? (pdf).
In it, he states:
Architectus Reloadus is the person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity, and perhaps because the architect doesn’t think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be made early on so that everyone else has a plan to follow.
Architectus Oryzus is a different kind of animal (if you can’t guess, try www.nd.edu/~archives/latgramm.htm). This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in nontechnical terms — such as development costs.
Do you remember MSF (Microsoft Solutions Framework)? This is a development methodology that was distributed by Microsoft. The Lifecycle methodology was kind of iterative, but on a release cycle, rather than multiple iterations per release ala RUP. It tended (in my mind) toward product development rather than custom software projects or internal IT projects which are quite different from product projects.
What MSF did have is a very strong Team concept that bears close review today. Now they don’t really mention the concept of an Architect in relation to the development team, but they do put great emphasis on a tech lead (who would be doing what I expect an architect to do). The great principle here is that you need at least 3 leaders on a team:
- The Project Manager (Program Manager in MSF)
- The Tech Lead
- The Product Manager
The tech Lead (Architect) takes on the million technical details of a project and the leads the design and development process. The Product Manager is a business representative whose job it is to coordinate the million business details of a project, gather requirements at the business level form stakeholders, and is the business Point of Contact for the project. The Project Manager is responsible for managing schedule, LOE against budget and is the buffer between the Architect (yes I switched terms in mid-stream, good catch) and the Product Manager.
The bottom line is that a strong team needs a good technical mind and a good business mind and a good manager / organizer mind. When the business folks are pushing for more features, the project manager is asking the architect what the impact is and then relaying that back to the business folks. No surprises, scope creep is managed. If a change is scope is really needed, all go into it with eyes wide open.
So then, why not just a tech lead? Because just as the skills required for project management differ from developer skills, architect skills differ somewhat from tech lead skills. A good tech lead certainly has architectural savvy to at least some extent. An architect though is used to always considering the big picture. He or she can step back – and *stay* back, keeping his mind on the larger view. The architect will let the tech lead and developers do their job without micro-management, and yet they are always there to help and advise if needed.
So do all project need a dedicated architect? Yes and no. Certainly on a smaller project the tech lead can function as the architect, but must keep in mind the big picture, the long-term view. Its easy to be inundated with micro-details and miss the larger issues that have great effect over the long haul. On a mid-size or larger project, having an architect (of the type Mr. Fowler describes) can make the difference between overwhelming success and the other alternative.
Take some time to read the article and ponder it. I think it will be more than worth your time. Get the article here.
Related posts:
