Do Architects need coding skills?

Do Architects need coding skills?

In the oft cited parallel world of construction and engineering (of buildings), it is true that to be an architect one does not need to necessarily possess brick-laying skills in order to be effective in their role. However, to be an architect one does need to understand the properties of the materials used for construction.

What about software? Most, in fact pretty much all of the (software) architects I know have some background coding experience. The question to be asked is how essential is it to have coding skills? If an architect can get by without having ever laid a brick, is it possible for a software architect to get by without ever written a line of code?

At least at the current state of our discipline, I would say no.

However, a more contentious question maybe – Do Architects need to maintain their coding skills once they’ve achieved the lofty status of architect. Well, I think it depends. Enterprise architects - possibly not (more on that later). However, for application, solution or product architects – I would say yes. There are many reasons why I think this is the case.

Firstly, the job of the architect is to take a definition of what needs to be built and figure out the best way for how to deliver the solution or product given the imposed time and financial constraints (in reality, the architect is also usually involved in figuring out what needs to be built although this should really be the role of the business analyst or product manager). He/she needs to figure out how to break the problem into manageable chunks (high-level design), decide what materials and tools to use (taking into account the current state of the art and the skills of the development organization) and forage for the non-functional requirements or quality attributes. Basically, the objective of the architect is to deliver better faster cheaper. It’s often a difficult job. The architect may also be stretched and be responsible for data design, dynamic modeling and even detailed design activities such as screen design. Essentially, the architect has to provide whatever it takes to ensure the development organization has enough information to be successful in the build out.

The architect may also be pulled into oversight of the development effort. Throwing designs over the wall and turning your back is likely to result in the development organization delivering something different to what is actually required.

Sometimes, models are not enough. They are by their nature abstract which means they are missing details. The details are where the devil lies. The details need to be figured out sooner or later and so the development organization may either choose to figure it out for themselves or involve the architect.

There may be some system requirements that are difficult to articulate in English specifications. Sometimes, code in the form of prototypes provides an ideal communication mechanism to the development team.
The architect is required to look around and observe and evaluate current trends in technology and processes. Maybe, there is some new toolkit or framework that has been developed that promises to help shorten the development cycle or provide some significant value. Of course, the architect has to try out the technology or process outside of the critical path of the project to ensure fit and readiness for the project at hand. Perhaps some prototypes need to be developed. The architect may need to dive in and learn the new technology before making a sound recommendation to embrace or avoid.

The architect shouldn’t be coding on a daily basis. If the architect is spending most of his/her time then I would argue they are not doing architecture. Having said that, coding is a small yet important component of the architect’s repertoire.