If you ask five people what a software architect does, you’ll probably get five different answers, and most will be off in amusing ways. Some think architects just draw boxes all day. Others imagine them swooping in during a 2am outage to save the day. Gregor Hohpe, in The Software Architect Elevator, jokes about these big expectations: the architect who fixes performance issues in the morning and changes the company culture by the afternoon.
No one actually does all of that. The fastest way to understand what a software architect really does is to first figure out what the job isn’t.
The four roles architects keep getting mistaken for
- Senior developer. Developers often think becoming an architect is just the next step up, better title, better pay, same path. But Hohpe says superstar engineers and architects follow different tracks, and neither is above the other. Engineers focus on building and delivering software. Architects take a broader view, dealing with organizational and strategic issues. Companies that get this offer both tracks and let you pick. So moving from developer to architect isn’t a reward for writing great code, it’s a shift into a different kind of job.
- Firefighter. Since architects know how everything connects, they’re often called during a crisis. Production problems do matter to them because they show where the design needs work. But if someone is always rushing from one emergency to another, there’s no time for real planning. Architecture is not the same as operations.
- Project manager. Decisions architects make affect schedules, staffing, and hiring needs. So managers often send project questions to the architect, especially if the project manager is busy with paperwork. This work is helpful, but it can slowly pull you away from what you were actually hired to do.
- Scientist. Architects do need to think in models and systems. But their decisions affect real projects and budgets, which is different from research. Hohpe prefers the title chief engineer to show that architects do more than just write documents. While academics might get published for making things sound complex, architects do the opposite: they make complicated things easier to understand.
The elevator, and why it has to go both ways
That title means something. Imagine the company as a building. In the engine room, developers and operations teams keep things running. In the penthouse, executives set the strategy and decide on budgets. In between are all the layers of management your company has added over time.
Executives shape strategy at the top, often without a clear sense of technical details. Meanwhile, technical decisions are made at the bottom, with little knowledge of the overall strategy. Someone needs to move between both groups, sharing accurate information both ways.
That’s the architect’s job. They not only stay on the top floor but also enjoy going back down again and again. Hohpe warns about architects who only go up and never return, and he has a term for the opposite problem: lift boys, who go down but never actually talk to technical people. They just gather buzzwords and repeat them to executives.
Is it worth making these trips between groups? Hohpe says a CEO can learn more in twenty minutes with architects than in ten hours of committee meetings. He tells executives who think IT issues aren’t their concern: your IT team makes decisions every day that will affect what your business can or can’t do in the near future. You should be aware of that.
The requirements nobody wrote down
There’s a simple way to divide things: developers handle functional requirements, and architects handle nonfunctional ones, the ilities like scalability, maintainability, availability, and interoperability. It sounds neat and is easy to remember, but it’s only partly true.
Hohpe says architects mostly deal with nonrequirements. These aren’t things that aren’t needed; they’re things no one ever mentions. It’s about context, shared assumptions that go unspoken, and hidden dependencies that only show up right before launch. Bringing these issues into the open and making them clear is, in his view, one of the most valuable things an architect does.
When this work goes well, it’s invisible, which is a big reason why the architect’s role is so hard to explain to outsiders.
There’s no such thing as the software architect
If you look at software architect job listings, you’ll see the title almost never stands alone. There are solution architects, enterprise architects, security architects, and also network, cloud, and data architects. It’s similar to the real world, where city planners, building architects, landscape architects, and interior designers all work together without anyone ranking them.
Hohpe uses this comparison directly. A beautiful house in a poorly planned city, with traffic jams and no public services, is just as hard to live in as a badly built house in a well-organized city. Software works the same way. A well-designed application isn’t very useful if it solves the wrong problem, repeats something the company already has, or can’t connect to the corporate network.
So the real question isn’t which architect is more important. It’s whether they’re actually communicating with each other.
How you’d know if yours is any good
Hohpe gives a long-term answer: if a system can handle lots of changes even years later, someone skilled was probably involved early on. That’s true, but not very helpful if you need to judge someone’s work right now.
The shorter-term signals are easier to spot:
- They connect the dots. Each system might be well built and well managed, but together they still might not meet business needs. Architects focus on what happens between systems, looking at the connections no one else manages.
- They see trade-offs. Most important decisions have downsides. Good architects point these out and weigh them against what the company wants to achieve; that’s their job.
- They look past products. Too often, technical choices are made based on the vendor with the flashiest presentation. A good architect ignores the branding and shows you the real options.
- They tie strategy to technology. Architects take business needs and turn them into technical solutions. IT is there to support the strategy, and someone has to make that connection clear.
- They fight complexity. Architects deal with governance, review boards, and bringing together systems that have drifted apart. They also handle the often-ignored task of retiring old systems instead of letting outdated ones pile up.
- They deliver. Real feedback from actual projects keeps everything honest. Without this, any sense of control is just an illusion.
Get back in the engine room
One last point about the elevator, since it answers a common debate among developers: should architects still write code? Hohpe suggests something different; they should debug. Debugging doesn’t require much extra setup, and it doesn’t make anyone feel like their codebase is being taken over. Even better, debugging puts you right in the middle of how components interact, which is what architecture is all about. As Hohpe puts it, architects should visit the engine room, not to write code, but to come back with new insights.
That’s almost the whole job in one sentence: someone who goes down to see what’s really happening, comes back up, and explains it clearly to the people in charge.
So, it turns out the job is a lot more than just drawing nice architecture diagrams.
