What is a "Software Architect" and should they write code?

These are questions I’ve struggled with over the years, as I often find myself in the role of a “Software Architect”. What I’ve discovered though, is that companies are rarely able to identify the actual needs of their software teams, and tend to overcompensate by relying on the title of “Software Architect”.

What follows is a grand redesign of the software architecture with little to no impact on product delivery due to misalignment with the needs of their business. After all, the Software Architect is going to do what he or she can do best: build architectures. Massive and beautiful, but they are not held responsible for implementing their grand vision, nor do they want to be involved in writing code.

I remember a past position where I was a developer on a team, implementing a massively complicated architecture. I joined the team mid-way through, so I never had the opportunity to be there from the start. I soon started questioning some of the decisions and designs of this system. One in particular comes to mind:

The architect wanted to use a MySQL database with a complicated caching stack in front of it, coupled with custom libraries and callbacks, to serve as an internationalization and localization system!

The product was a simple application, that required the display of translated strings in a number of target languages. As you could imagine, the Architecture was overkill.

When the team started discussing this, I suggested we use free and lightweight alternatives such as gettext, which is included in almost every system and already has built-in libraries for almost all major programming languages! Unfortunately, my suggestions were shot down as the Architect’s word was sacrosanct. In the end, I realized three things:

1. The Architect has never heard of gettext, nor did he bother reading the documentation when I proposed it.
2. The Architect enjoyed solving problems “his way” and would prefer not to take a different one, even if it were easier. The cost to business, and the efficiency of the product were of no concern to him.
3. If the Architect was forced to code and implement his own architecture, he would have sooner realized how overly complicated it was and the incredible amount of time it would take to develop. Thus he would have to reconsider his approach.

What is the effect of a non-coding architect on a development team, a product, or a business?

Anthony Langsworth wrote an excellent analysis of the question: “Should Software Architects Write Code?” He starts by highlighting some negative stereotypes around the role that have been building over the years:

Non-coding architects, sometimes called “PowerPoint architects”, “astronaut architects” or “ivory tower architects”, may use archibabble and talkitecture to convince non-technical stakeholders of their expertise while delegating the unsolved, real problems to developers, so much so that it has become an organizational pattern (“Architect Also Implements”) and corresponding anti-pattern (“Architects Don’t Code”).

There have been more than a few opinions on the topic, like the discussion that followed Anthony’s post on LinkedIn. Many are interesting, and challenge or confirm the argument. However, one thing keeps escaping all these posts and discussion on this topic:

Particularly, the following questions come to mind:

• What industry does your business belong to? (banking, technology, telecommunication, broadcasting, etc …)
• What is the size of your organization?
• What is the size of your development team?
• What is the expected output of your team? (software products, services, innovation)
• Do you already have a development team or are you building a team?

Industry

But “software” is agnostic to the industry, isn’t it?

Why it matters: Having worked in a number of similar, or closely related, industries (Internet publishing, advertising, and social media) has allowed me to build subject matter experience in the technologies related to these industries, as well as influence change and innovate across industries.

A Software Architect cannot possibly become a subject matter expert without focusing on one or more related industries. I would love one day to switch industries and try out something new, for example join a chemical lab/business. I can only imagine what adventures I could embark on in building software for chemical engineering!

But what will my (now) 10 years experience in building web and mobile technologies bring to the table? How could I be better at determining the architecture of chemical process simulators, than the developer who’s been working on this specific type of software for the past 5 years?

Furthermore, a chemical business would most likely not even have a need for Software Architects, but rather rely on Chemists/Chemical Engineers with Computer Science backgrounds to lead software development that is better suited to their needs.

Likewise the music industry does not need Software Architects. It is led by musicians (with background in Computer Science) and leverages software developers (that may or may not be familiar with music theory) as needed.

Spotify, and iTunes may look like exceptions, but they don’t count as part of the Music Industry. They are technology and entertainment businesses that do little to advance music itself, but rather the delivery of it.

Let’s limit the scope to the Technology industry to make it easy.

Organization Size

Does a team of two need a Software Architect?

Why it matters: When was the last time you’ve heard of a successful small business/startup that had a dedicated Software Architect?

It is not a question of whether the role is needed. A startup cannot afford to have one team member focus on just the architecture. Everybody has to share the task, and wear multiple hats. Even the founders/CEO/CTO all have to be able to jump in and be the janitor.

Okay, so are startups the exception? How big is your organization? Hundreds? Thousands? But are they all in same field? Or even in technology?

Even giants like Google, Apple, and Facebook will have a massive part of their workforce that is not even technical in nature; Let’s focus on the parts of the business that are technical, and for a universal catch-all title, let’s use: The Software Department.

Does the software department have a need for technical people to communicate with other departments or clients, gather requirements, and deliver products or services?

If your answer is yes, to any of the above, and expect a Software Architect role to fill that need, then you have some reading to do

So what role does a Software Architect fill in the Software Department of a big organization? Or better yet: “How does having a dedicated Software Architect role benefit your Department?”

Let’s talk about team size.

Team Size

Does your entire department operate as a single team, or is it split into many different teams that are working on different projects/products?

Why it matters: It has been my experience that a dedicated role in any software team with a defined list of ownership and responsibility stifles collaboration.

I’ve heard the words, “it’s not within my job description” almost as many times I’ve heard, “this is clearly within my job description and I should be the one to decide!” Both are two sides of one anti-collaborative coin.

Scott W. Ambler warns of this and of the dangers of ivory tower architectures:

An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s). The mighty architectural guru(s) go off and develop one or more models describing the architecture that the minions on your team are to build to, for the architect(s) know best.

A big software department with small agile teams (say of fifteen people or less) is no different than a small business/startup. Each team is faced with challenges, deadlines and pressure to deliver.

So who is responsible for architecture in a small team?

Ambler writes:

The easy answer, one that works well for small agile teams (which is the vast majority), is that everyone on the team is responsible for architecture. The practice Model With Others tells you that you really don’t want to be working alone, and frankly architecture is far too important to leave in the hands of a single person no matter how bright they are, therefore architecture should be a team effort.

This increases everyone’s understanding and acceptance of the architecture because they worked on it together as a team. It also increases the chance that developers are willing to change aspects of the architecture when the architecture proves insufficient.

When something is developed by a single person it becomes “their baby” and nobody likes to hear that their baby is ugly. When you find a problem with their architecture they are likely to resist any criticisms of it. When an architecture is developed by the entire team then people are often far more willing to rethink their approach because it’s a team issue and not a personal issue.

In a big software department operating as single big unit/team, the “everyone owns the architecture” strategy doesn’t scale.

When your team is large or geographically distributed, two of the eight scaling factors called out in the Agile Scaling Model (ASM), you will organize your team into a team of sub teams. Architecture at scale requires a coordinating body in such situations.

There needs to be some sort of overall vision/guidance to ensure the direction the technology is taking is the most sensible one, and to coordinate with other big teams/departments.

This is probably one of the few places where (in my opinion) having a dedicated Software Architect is useful. However, what interactions does the Software Architect have with the rest of this large team? Is this another silo role?

Not at all. It shouldn’t differ than the previous model. The role of the Software Architect is to be part of the team with the additional responsibility of communicating & documenting the team’s decisions and channeling direction from the Architecture Owner Team.

So far, we’ve identified one place where we need a dedicated Software Architect!.

Expected Team Outcome

Are you building software products, or updating web pages?

Why it matters: We’ve talked about Industry, Organization and Team Size, but all of the subject matter experience, team structure and process overhead better be productive in our team’s output.

If you have a small or large team, whose sole output is creating/maintaining a simple website, where the highest skill needed on the team is a bit of HTML/CSS, and you’re talking of Software Architecture … then you have bigger problems!

Building a Team vs. Using an Existing Team

Are you struggling with your existing team’s structure? Or planning on hiring Software Architects to solve your problems?

Why it matters: If the goal is to expand your team, then most likely you already have the right candidate within the team; He or she would be the subject matter expert, and the rest of the team needs to step up and collaboratively own the architecture.

Titles don’t matter. An individual asking for specific title is usually a red flag for me, especially for somebody who only wants to be a Software Architect.

There’s a well known saying: “Those Who Can’t Do, Teach.” I strongly disagree with that, but I will leave it to Taylor Mali & Zen Pencils.

Joe Winchester has adapted it to “Those Who Can, Code; Those Who Can’t, Architect”, and while it’s a bit of a strong single-sided opinion, it does raise a good example of where the role of a Software Architect goes downhill:

As soon as a project gets into trouble, they can launch these facts at programmers and proclaim, “Aha, it’s because you’re not using BOJOX and NADA 2.0 combined with YML that you have a bug” in front of the nervous manager who wants nothing more than to buy more time by telling his reporting chain that he needs a year to do a total rewrite. During this time, because nothing ships, nothing can go wrong and, hopefully, the stock price will have grown to the point the manager can cash in his options in time to go be a coward somewhere else.

Joel Spolsky writes of his frustration as well:

Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.

If you’re starting off fresh, and building a team from the ground up, then do just that.

Build your team from the “ground up”! Start with smart, hardworking developers who are eager to learn and grow. Give everybody equal ownership of the software architecture and never stop innovating. Titles will not matter, and your team will be happy and productive.

tl;dr

Not all industries/businesses need Software Architecture

Most technological problems are already solved, what most businesses need are implementers; Full stack software developers who can execute on business needs and ensure product quality and customer satisfaction.

Architecture is far too important to leave in the hands of a single person no matter how bright they are.

When an architecture is owned and developed by the entire team, people are often far more collaborative in sharing both the ownership and the responsibility.

Focus on the end goal: If your team’s expected output is to innovate in software, then Software Architecture is high in your priority list and you need the right people leading the charge.

If your business is selling shoes, then stop wasting your time on the Software Architecture of your e-commerce platform, and focus on selling shoes!

By this point, I hope I’ve brought some clarity to the role of a Software Architect and the value they can bring to the right team, and where it can all go horribly wrong. As for the original question: “Should Software Architects Write Code?” I leave you with a quote from: The book: “The Most Beautiful House in the World” by the Canadian (building) architect Witold Rybczynski:

For centuries, the difference between master masons, journeymen builders, joiners, dilettantes, gifted amateurs, and architects has been ill defined. The great Renaissance buildings, for example, were designed by a variety of non-architects. Brunelleschi was trained as a goldsmith; Michelangelo as a sculptor, Leonardo da Vinci as a painter, and Alberti as a lawyer; only Bramante, who was also a painter, had formally studied building. These men are termed architects because, among other things, they created architecture — a tautology that explains nothing.”