Should an Architect Write Code? Yes -- And No

by Michael Rosen, Director, Cutter Consortium Enterprise Architecture Practice

The debate constantly comes up about the role of an architect and whether or not he or she should write code as part of a project team. This can become a somewhat heated discussion with lots of strong opinions, but I think it ultimately comes down to the typical consultant's answer: "It depends." It depends on your environment, what you mean by an "architect," and what you expect the architect to accomplish.

For example, the job of the enterprise architect is to understand things at an enterprise scope, beyond any individual application or line of business. Architects must understand how all similar applications fit together, what must be common across all of the applications to meet enterprise goals (such as single sign-on, common customer profile, standard server platform), and what each application must do to support the overall enterprise. The enterprise architect must also understand the relationship between the different architectural domains (business, information, application, technology, security, and so on) and how to achieve the enterprise goals in terms of the different domain architectures. So the questions I ask are: how does writing code help the enterprise architect achieve this, and just as important, is it the best use of the architect's time?

More relevant to the discussion is the role of the solution architect. The solution architect acts as a bridge between the areas of:

• Enterprise architecture (particularly what the application needs to align with)

• Domain architecture

• Internal architecture of the application

In other words, we do not expect the project team to be knowledgeable and current about EA; that is not their responsibility. The team is responsible for executing a project. Instead, it is the job of the solution architect to understand EA and to convey the important aspects (important with respect to this project) to the project team so that the team is incorporated into the design and implementation of the project.

How does the solution architect bridge these different perspectives to effect an architecturally conforming implementation? The critical part of this is the architect's ability to convey the concepts to the team, get them incorporated into the design, and make sure they make it into the implementation. This will depend on the skill of the architect, the type and size of the organization, and what the architect is expected to accomplish. Here, personal experience is likely to influence your opinion.

There is no doubt that a solution architect must be conversant in both design and implementation skills and be able to talk the talk with the project team. Let me give a few examples from personal experience. At a large insurance company, I helped build a team of 50 application architects, most of whom were developers in the past. This company does about 2,000 projects a year, for which the most important 500 get application architects assigned to them. You do the math: that means 10 projects per year for each architect. Most architects can do two projects concurrently, which gives them 10 weeks (at half effort) for each project. In this time, they are able to work with the application team to create a good, EA-conforming, high-level design. Later on, they participate in design and implementation reviews. The architects simply do not have the time to write code, yet in the four years since we initiated the program, it has proven to be very effective -- so much so that project teams compete to get an architect assigned to their project.

On the other side of the argument, Scott Ambler, a great architect for whom I have the highest regard and respect, believes equally strongly that an architect must write code to be effective. In his environment -- working with smaller, agile teams -- his experience is that the architect has to be able to get his or her hands dirty in the code to be effective.

So it boils down to your environment and your expectations of an architect. No one answer is right for everyone, but that won't stop us from arguing about it.

I welcome your comments on this Advisor and encourage you to send your insights to mrosen@cutter.com.

-- Michael Rosen, Director, Cutter Consortium Enterprise Architecture Practice