Hands On Architecture

I read an essay by John Davies entitled “Architects must be hands on”. It made a lot of sense. John says that a software architect needs to be able to lead by example. The architect should be able to do any of the duties on the team. For example, the architect should be able to configure the build or write unit tests.

The architect needs to be more than a project manager. The architect needs to understand both the technology and the business. The project manager, on the other hand, must take care of the day to day mundane tasks of running the project.

An architect has to be able to demonstrate clearly in order to be effective. Architects should be brought onto a project early. When faced with an important decision, architects should confer with their architect peers. The architect should also have expertise in at least one tool, preferably the Integrated Development Environment (IDE).

A lot of programmers and developers strive to be an architect. Architects sit at the top of the totem pole. It is a good title to have on your business card and resume. Theoretically the architect is making more money than the rank and file person on the project. The problem is that not everybody can be the architect. That being said, it would behoove an architect to follow the advice shared by John.

I think about my own career path. Having worked on the same project for many years, I have become an expert in the business of our client. This gives me an extreme advantage over other developers. Most of the time, the hard part of our job is figuring out what the client wants. It is rare that the difficult part is the technology side of the house. In fact, given our specific client and project, you have to know a lot of legacy technologies to be good at development.

Two strong developers in the past have been promoted to the software architect position before. Now this was mainly a way to not increase their pay, but persuade them to stay on the project. Don’t get me wrong. These were sharp guys. They were strong in technology. And they were top developers. Come to think about it, they were well respected by their peers. Perhaps I should follow on in their footsteps. One went on to be a technical director. The other reverted back to a simple software development role.