Should application architects write code?

Question

This is an often-asked question that has views on both side. Those in favour will argue:

• To design a system for coders you must understand how to code (and be coding)
• You can't design a system without being aware of what is happening at ground level
• Architecture is not just about broad stroke design but about adapting to changing needs at the code level

on the other hand,

• Architecture is a high-level role and should be not be concerned about implementation details
• Coding is a detailed oriented, heads-down funtion which is at odds with the risk management, broad view nature of architecture
• Architecture is about technical risk management and not implementation
• Architecture is about leadership. It's difficult to lead from behind

In my experience architects should not be spending a lot of time coding but must keep in touch with the code base primarily through lead developer communication, review and stand ups. If you spend a lot of time coding you lose sight of the high level issues and become ineffective at managing technical risk.

Answer 1

I (think I) am an architect, coding is what makes this job fun.

Then you see your ideas are coming to life, you can see your design working, and you can see the errors in the design (too late anyway, but next time...)

Answer 2

Yes, to keep their coding experience.

Answer 3

There are architects and there are IT strategists. If you are leading an integration project involving 500 people across multiple departments then no, it's going to get in the way. If you are leading the design and implementation of up to a few 10s of people on a development project, then yes. Otherwise you will be far less likely to have the appropriate insight into the day to day reality of working with your architecture.

Answer 4

Would just writing the interfaces count as code? If so, then this is the minimum I'd expect from an architect, while in other cases it may be much more code from them such as classes with stubs for methods.

Answer 5

Just to give my two cents (and my vision of "architects")

I believe there are several types of architect, each in their own domain:

• business and functional architects: they are concern with business operations and functions workflow, and they actually should not ever code, because they have to be able to abstract themselves from any kind of implementation, and they must produce functional specifications which leave the technical solution open.

• applicative architects: they divide a functional domain (like "profit and losses analysis") into applications (like "portfolio processor", "launcher", "dispatcher", "gui"). They do not need to code, but they should be former coder in order to have a clear idea of technical challenges that their architectures must address. Their primary skill is not coding though, but listening to technical colleagues in order to choose the right solution. They will then produce technical implementation which must be implemented (coded).

• technical architects: they are in charge of choosing and/or implementing technical frameworks (those which are generic for any functional project, like KPI, logging, exception management), and they should absolutely code (and code well), since their components will be used by all the other functional teams.

• development architects (hey, that's me ;) ): in charge of development tools and processes, and technological surveys, they should code and love coding as well.

So I believe there is not just one answer: it depends on your architectural field and expertise: when it comes to 'application architects', I believe the three latter categories can have different coding experience...

Answer 6

I think the role of architecture is changing. I see less and less ivory tower architects that design a whole system for the lowly programmers to implement in a waterfall process.

When doing iterative projects communication between architects and programmers gets more important. The architect is part of a team and should be able to handle changing requirements and new ideas together with the programmers. In situations like this the job of an architect and a programmer are more closely related. I've seen teams where the dev-leads took on the role of architects deliver well thought out architectures for really complicated solutions.

edit In reply to comment
I think in the distinction between application, solution and enterprise architect is a bit artificial and doesn't really fit in many cases. Roles like security architect, data architect etc. give a far clearer disinction between responsibilities. You can look here for more details http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm

By the way, from reading your question again I noticed that many of the arguments against coding architects seem to indicate a strong management/leadership role for the architect. I think it's a good idea to separate the management and architecture roles. It's better to have your technical people divide their time between coding and architecture than between management and architecture.