Architects Should Code: The Architect's Misconception
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.
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.
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.
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.
If you are not coding ...
Becoming an architect is not the next step after lead. Your best developers might not have the abilities required for architect.
Almost fully agree
Or, as a wise architect should always answer: "It depends". In a team with veterans, an architect has a lot less trouble, or maybe isn't needed as such. He or she may get the task to explain the work to management or get more involved in the requirements process.
My observation in the industry is that I can tell when non-coding architects have left development. That's where they had stopped learning. They promote concepts from that particular era as if they were convinced that they had learned all which is to learn back then. Big mistake.
once you've put the crown of abstraction and irresponsibleness on its head.
An architect should be passionate about producing UML diagrams
as a writer should be passionate about producing tables of contents.
Every time I spoke with an architect who thinks his job is UML and
technical notes, a "PowerPoint architect", I found him terribly lacking
any required skill (a sense of the many possible trade-offs, an ability
to deal with concurrency, etc.).
I even once witnessed one propose a network API to retrieve current time
in a "high performance computing" application, while calling system time
was perfectly fine (if not already a little slow).
But it's no surprise, since they got promoted to that authority position
by people who don't have a clue what it's all about, and for reasons like
having spent a few years coding a framework (whatever dirty it is), or
knowing a lot about what some old thing do and how it does it, or even just
due to age, look (but where does look not come into play? :), or diploma
(without any experience, just out of school, because the school was
"a top one" - was the case for the network API guy).
The problem with the clueless people (managers) is not so much that they
don't know what it takes to develop software, that they don't seem to know
what it takes to do anything, as if they didn't do anything real in their
lives and had some kind of magical thinking, which seems to be a tendency
in our societies with our serviced lives and the multiplication of
That reminds me of an old peasant woman I knew when I was a child,
she had not much education but made very good pies.
She often told us about urban people, with her accent:
"Les gens de la ville, quand mêêême, ils sont bêêêtes !"
("People of the city, reeeaally, they are stuuupid!").
That said, if the developers are good enough the architect might just
have to throw in some advice here and there.
What is architecture?
The software development community does itself a huge disservice when we try to model development practices off of manufacturing. Too often we look at software architecture like manufacturing architecture and equate blueprints to UML or paper designs. What is completely missed here, is that while blueprints may very well be the design of the building, paper is never the design of the software solution. The code itself is the design, and the code itself defines the architecture of the solution. While manufacturing deals with very predictable materials such as wood and steel, the software process introduces so many variables and complexities that quickly supersede any "PowerPoint design".
Thus, any architects, that aren't involved at the code level, are depriving themselves or real design. This article does an excellent job of describing the void we create when allow, or even encourage, "architects" to stop coding.
Thanks for sharing. I completely agree with the assessment in the article.
Future of the architect
Technology keep changing he keeps learning and waiting for the opportunity to implement those technologies. If developer is struggling to learn and implement code and help them to learn and implement. He may never move up the ladder if he keep continue coding and keep helping. His whole achievement would be his value is recognized by team, many times he keep helping and delivery is keep delivering what is the further roadmap for the architect.
I have met couple of professionals who spend there whole life doing the same activity, they are known to be the god father for the product application at the end but what next...what is the future of an architect.
Nowadays architect should focus on requirements, test/quality, communication (with management and other stakeholders), and the coarse grained architecture - the main components.
Technology is nothing that architects could suggest, that is what they are asking for.
Architects do not "lead", they fulfil only a differen role compared to developers in a team.
Application and Solution Architects Maybe
This is a very narrow view or architecture. Architecture as a discipline is made up of many different families of architects which play very different, but equally important roles. Technology Architects, Platform Architects, Application Architects, Solution Architects, Security Architects, Innovation Architects, UX Architects, Business Architects, Enterprise Architects, Information Architects, etc. Some of these architects have 0 coding experience. Technology and Platform Architects as an example do not start out in development. The last thing I want one of my Enterprise or Business Architects to be doing is coding. I want them focused on business process engineering, capability mappings, and IT strategy.
Who do I want to code from time to time? Application Architects, Innovation Architects (maybe), Solution Architects (rarely). At the end of the day I can hire a lead developer for 30+% less than an architect. Also, in my experience lead developers have a very different mindset and it hinders them when they try and move into architecture roles. Change the title to 'Application Architects Should Code..... Sometimes' and we are square. As it is presented I don't agree.
Architects should know about coding..
Let the hordes of developers hoard that knowledge themselves.
Re: Almost fully agree
Re: Application and Solution Architects Maybe
Re: Almost fully agree
Re: Magical architecture
Re: Application and Solution Architects Maybe
The Instructor MUST have up-to-date programming skill, as he is directing programmers. I think most readers here have this type in mind.
The Consultant can quite happily not program, if his expertise is orthogonal to programming. For instance UI design. However, to avoid ivory tower work, a close collaboration and understanding what programming is about is still necessary.
Both need to understand the constraints of the target environment.
Software Architect’s Deliverables
Re: Almost fully agree
Re: Application and Solution Architects Maybe
We are being told that (re your Article) that Architects should code and I see from your note that you include the Infrastructure. Can you tell me what type of coding you would expect the Infrastrcuture Architect to do?
Thanking you in anticipation
Infrastructure Solution Architect.
Architect Architect shouldn't code
He gave me the job saying "You are right. We have 200+ programmers here making a portion of your salary. If we have programming needs we will go to them. We have 5 of you. Let them talk to you in your language (Charts, diagrams,...). Don't talk to them in their language (Code). Don't write code. Don't read code. Don't do anything with code."
He was right. We made the best software assembly-line I've ever seen (this was my job number 20). We were getting requirements from business. Convert them to architecture designs. passing them to dev team. well oiled machine. Still working perfect.