Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Architects Should Code: The Architect's Misconception

Architects Should Code: The Architect's Misconception

Leia em Português


When I interview people for architect positions I usually ask a question like: “Do you think an architect should do any coding?” And I usually get one of two responses:

“No, I look forward to advancing to a position where I no longer work with code.”

“I’d love to continue coding, at least some amount, but I probably won’t have time.”

Similarly, when I ask other architects how much they’ve coded recently, more often than not I hear:

“It’s been a while.”

These responses are always disturbing. Since when did advancing in a technical role come to mean separating from technology and delivery?

How does one expect to navigate the vast landscape of technology options and understand how they play within their enterprise without staying plugged in to the teams that implement those technologies? Or, better yet, implementing them oneself?

How does an architect expect to stay nimble in response to changing project requirements without staying connected to the delivery?

A good architect must work closely with the delivery team. This is imperative to evolving a successful architecture, which leads to a successful delivery.

Collecting feedback and providing leadership are two key benefits of staying engaged with the delivery. 


An engaged architect will be present to witness feedback first-hand and available to work with the team to mitigate any deficiencies. Feedback can come from a number of sources such as changes in enterprise standards, changing or evolving functional/non-functional requirements, and challenges discovered during implementation and testing.

The earlier these deficiencies are identified the faster the architect can evolve the architecture. If the architect is not actively engaged with the delivery team then this feedback could take weeks or months to bubble up, usually very late in the delivery cycle.

Given that the architectural decisions usually encompass those things that are most important or hard to change, this lag in feedback will only compound if significant architectural changes are required.

Discovering architectural deficiencies late in the cycle usually leads to workarounds and technical debt to “just get through this release.” However, the earlier this feedback can be captured and assessed for architectural impact, the more agile the entire project will be, and less risk will be accumulated.


Another primary responsibility of any architect is to provide leadership. Leadership can take many forms, all of which are important to the successful implementation of any effort and its underlying architecture.

Architectural leadership requires the architect to effectively communicate the "big picture" to the team for successful realization. The best way to relay this information is by working closely with the delivery team and having several contextual discussions, not through one document or one meeting or one speech. The architectural direction must be reiterated throughout the effort. It is all too easy to get caught up in the heat of delivery and lose sight of the overall goal. Having an architect that is continuously engaged will help maintain a consistent vision.

Technical leadership stems from the fact that the architect is often highly experienced in development and delivery. A goal of the architect should be to educate and grow the development team. Sometimes there are specific tech leads that play this role, but why horde the experience gained by the architect? Not only does this interaction benefit the team as a whole, it benefits the architect to understand some of the common issues the development team encounters.

Mentoring is a form of non-technical leadership that an architect can impart on a team. Topics like working with non-technical people, embracing Agile principles, defining architecture, and modeling architecture are all important skills for growing developers and future architects. Much of the training and knowledge of an architect's role is gained by way of on-the-job experience as opposed to more formal, classroom-type educational opportunities. An architect should embrace this tendency and make architectural learning active rather than passive.

Tactics for Enhanced Engagement

An engaged architect may not necessarily be picking stories for individual delivery. Actually, depending on several factors like architect-to-developer ratio or number of external project commitments, having the architect solely own and delivery stories may be a less optimal approach. Following are some tactics for aligning the architect with the delivery and improving the interaction between the architect and the team.


Martin Fowler mentioned in a 2015 O’Reilly Software Architecture conference keynote that pairing may be a good option to keep the architect involved. Pairing, or Pair Programming, is an agile software development technique, made popular with the Extreme Programming methodology, in which two team members work together at one workstation to accomplish a common goal. In this scenario, the architect never actually owns a story independently, but pairs with others on the team to perform any required design, development, and/or testing. This approach has the advantage of keeping the architect committed to the delivery and close to any architectural feedback discovered, while shielding the team to resource churn in those instances where the architect must tend to extraneous responsibilities.

Peer Reviews

This approach is similar to Pairing, though with a slower feedback loop. Peer reviewing is when a peer reviews the work of another, usually after most of the work is completed, for quality. Here, the architect works with the developer to peer review the code, either periodically or once toward the end of story completion. Through this approach the architect gains insight into architectural adherence or issues preventing adherence and has the opportunity to provide leadership in the form of development advice.


The architect could lead a development spike focused on architectural discovery or delivery. A spike is a functional, proof of concept implementation for some aspect of the architecture used to identify or mitigate risk by exploring a new technology. Spikes provide an excellent opportunity to see the architectural decisions realized, contribute directly to the delivery goal, and promote more immediate visibility into deficiencies or limitations of the architecture. They also encourage that the architect be directly involved with implementation, collaborate with the team, share the architectural vision, and immediately benefit from any lessons learned.

Story Development

The architect could be a team member and perform actual story delivery. This is probably the tightest feedback loop possible. The disadvantage to this approach is the risk of the architect becoming too narrowly focused on individual stories (missing the forest for the trees). Maintaining the architectural vision and forethought must be balanced with detailed design and hands-on implementation. As an additional caution, this approach could play havoc with tracking a consistent team velocity. For example, if the architect is working stories for three weeks then pulls out for two weeks to perform some high level tasks (i.e. road mapping), this could create some churn in the team’s overall velocity. First, though I agree that short term velocity may be impacted; long term velocity should be impacted significantly less as the law of averages takes over. Second, if the architect is working on high level, project-related work, then those tasks should be stories alongside the delivery stories, reducing the amount of “shift” that an architect must manage bouncing between high and low level tasks.


In this tactic, the role of the architect is transitioned amongst team members for some set duration. During each person’s time as the architect, they carry the responsibilities of making architectural decisions, maintaining architectural cohesiveness, and providing overall architectural guidance. Rotating the architect role among different team members carries the benefit of increasing the overall team’s working architectural knowledge. Team members gain a better understanding of all the roles involved in delivery, leading to empathy between team roles, improved intra-team interaction, and a better overall product by diversifying the viewpoints applied to each role. I'd recommend rotating sparingly as the inconsistency could actually cause more disturbance than benefit. Somewhere along the lines of major releases (3-6 months) may be appropriate, depending on your team make up and release cycle duration.

Engagement Approaches to Avoid

While there are several tactics to improve an architect’s engagement with the delivery, there are also approaches that an architect could take to be involved but may be overall detrimental to the health of the team and the effort and should be avoided.

Only the Difficult Stuff

One tendency might be for the architect to take on all the difficult work, whether that work is captured in stories or otherwise. This could seem intuitive given the usual seniority and experience of the architect; however, in the long term this is detrimental to the team. First, by not being involved the team might not fully understand, nor be able to support, these complex nuances of the system. Second, software developers enjoy challenging work. By working all the difficult problems, the architect deprives others of digging in and learning something new.

Take Over

Another discouraged approach would be to just take over the delivery, command-and-control style. Given the time and effort the architect has spent on defining the architecture, there is significant incentive for a successful delivery, especially if the architect will be part of the delivery team. The architect may have the tendency to overly control all aspects of the delivery, rather than help guide the delivery toward the architectural goal. This approach could have the following detrimental effects:

  • Create a team that resents the controlling architect rather than one that is self-organized, highly functional and collaborative.
  • Limit the ownership and growth opportunities among team members.
  • Fail to scale to larger deliveries.

Driving the Details, Not the Essence

When pairing or performing code reviews the architect should be driving the essence of the need, not the details. There are many ways to code even the simplest logic, and many of them are perfectly functional, even though they may not mirror how the architect might do it. The architect must guide toward the architectural direction and enforce local coding standards, but also allow for some poetic license.


To realize a successful architecture the architect must stay engaged with the delivery team throughout the lifecycle. Staying engaged promotes a quick feedback loop into the architecture. It also provides more opportunities for the architect to communicate the architectural vision and provide technical leadership to the team. Although the architect could code, as the title suggests, there are other ways for the architect to stay engaged with the delivery, such as pairing and peer reviews. Conversely, there are ways to stay engaged that could be detrimental to the team, such as taking over the delivery and now allowing the team to self-organize or otherwise take collective ownership. A key goal is to avoid the "ivory tower" architect persona that decrees the architecture up front then is never seen or heard from again. Strive for a collaborative relationship with the delivery team, working together to identify and remedy architectural deficiencies as early as possible to deliver a success architecture and final product.

About the Author

Brandon Bryson is a Senior Consultant at MasterCard, a technology company and payments industry leader, focusing on application architecture, development, and agile delivery.  He is a 15 year veteran of the software industry with a passion for technical leadership, architecture and design, agile principles and the confluence of the three.  He has worked at Fortune 500 and start-up companies across a number of sectors including defense, travel, supply chain, and financial and has a degree in Computer Science from Mizzou.

Rate this Article