Ask 10 developers what a software architect is and you’ll get ten different answers; at least one of them will tell you the title software architect is just a fancy name for some guy in some office somewhere writing specs and forcing you to use a garbage CI/CD platform because this internal wiki page says you have to.
The problem is that software architecture has fuzzy borders, which makes it hard to define. And anyone who’s worked under a terrible architect will take a dim view of the role pretty quickly. Also, the reality is that people like to complain more than they like to praise, so online sources—especially places like Reddit—can be a pretty mixed bag.
So, let’s spend some time talking about what a software architect is and what they do, then dive into defining the traits and habits that differentiate the ones who give the role a bad name from those who make developers’ lives easier.
Full disclosure: I’ve never officially held the title of software architect but I have spent a lot of my career dancing around the role. I’ve had the good fortune to work with some very strong architects early on in my career at Ubisoft and Mozilla, so I’ve experienced firsthand how a good software architect can make a developer’s life easier. Later, in roles at Datadog and Scaleway, I got to focus on understanding and explaining the business case for technical decisions; reversing that to explain the technical case serving those business decisions; and teaching the next generation of developers how to build and maintain large systems.
Those are responsibilities all software architects would be very familiar with! So let’s get a little more into what that looks like day to day.
The software architect is responsible for ensuring a company’s technology supports the long-term continuity and success of the organization. This takes a very specific blend of skills, including technical mastery, business acumen, and leadership.
On a day-to-day basis, a good architect is going to be in constant contact with almost every aspect of the business. That means meeting with executives, lead developers, product people, sales people, logistics, finances, vendors and more. That’s a lot of meetings and a lot of people.
As you might imagine, trying to get all those diverse stakeholders on the same page so the tech team can do their job is difficult to do well under optimal conditions—and, to put it bluntly, conditions are never optimal.
Other than the onslaught of meetings, a typical week might include:
Basically, the software architect has the impossible task of bringing order to the chaos of people, procedure, and policy that make up any large company.
So, how do you excel at such a big job? It takes a lot of experience in a variety of domains, and a genuine interest in business, leadership, and technology. All three are mandatory; missing one or more of these is often the root cause of failure in the role.
So, we’re going to break down essential practices along those lines.
Yes, I know how that sounds, but stick with me here. Coming from a tech background, as most software architects do, one of the hardest practices is putting the needs of the business before technical considerations.
This includes:
When you’ve properly aligned your priorities, you will offer technical solutions that bring the most value to the business. The upside here is that when you can do this well, it makes you extremely valuable too, which is great for your own career advancement.
As a software architect, you’re on the hook for timelines and budgets. If you give in to overpromising or nodding along to impossible requests, you set yourself up for failure no matter how perfectly your design ideals meet business requirements. But when you’ve managed expectations effectively throughout the project, both your executive and development teams will be much happier with the result—and with you!
As both a tech expert and a business expert, you need to understand and weigh the risks on both sides. But not every project that comes across your desk as an architect requires the same level of conceptualization and planning. Some will impact flagship products that drive the business, while others will be much smaller and have a very small impact on ROI. These two different types of projects require different levels of architecting.
While it may be tempting to subject every project to the same level of planning, over-analyzing low-risk projects adds time and overhead to a project that reduces ROI without significantly affecting the final result. However, under-preparing for high-risk projects can lead to disaster. Therefore, knowing which is which—and acting appropriately—is a big part of success or failure at the end of the day.
I mentioned this before, but as a software architect, one of your core responsibilities is meeting with diverse stakeholders. Each of these people will have their own priorities, ideas and fiefdoms they want to protect. You’ll be talking to developers about financial decisions, leadership about technical decisions, and defending every choice to all of them. Ergo, maintaining a working relationship with each of these stakeholders is vital to your success as a software architect. To put it another way, if half of the role is avoiding stepping on people’s toes, the other half is stepping on them strategically.
A lot of being a software architect is being likable enough that people want to listen to what you have to say. Because you’re dealing with so many different parts of the business, you’ll rarely have the direct authority to “make” people do something—but, if they trust you and enjoy working with you, they’ll be much more inclined to go along with what you’re asking of them.
On the other hand, sometimes, you just have to tell a developer, “We’re not doing it that way. We’re doing it this way, and you need to get on board—and this is why.” Being a jerk here doesn’t work. You need to be competent, confident, and above all, trusted.
Building software isn’t like playing chess. You don’t know all the moves, or where all the pieces are. And, even if you did, next year, the chess board is going to change, and suddenly you’re playing checkers or mahjong. You will never know as much as you would like and you don’t always have the luxury of waiting until you have all the answers.
Instead, you have to be OK with making some data-poor decisions, knowing full well that you’re missing something—and everything may need to change tomorrow anyway—just so the project can keep moving forward. Yes, this is wildly uncomfortable, but it’s exactly where having trusted partners in the organization will help.
As a software architect, you’re not generally limited to a single team—in fact, you’re usually a bridge between them.
You need to be able to communicate complex technical issues to business stakeholders so they can make good decisions. You also have to do the reverse, translating business objectives into technical requirements so you can align the technical vision with the business strategy.
When you’re an architect, everyone has an opinion on how you should do your job, but no one sees the problems or goals as well as you do. That means you will get suggestions and requests from a variety of directions, many of which will require a negative response.
Being able to respond to impossible requests with a polite ‘no’ is essential to save your team, your relationships, and your sanity.
Most software architects start as developers, where it’s important to have a deep understanding of a limited number of tools. However, this type of understanding can act as a set of blinkers as an architect, causing you to view every problem through the filter of your expertise.
Obviously, you can’t gain the same depth of understanding for everything, but you don’t need to. By increasing your high-level understanding of all the tools at your disposal, you give yourself the ability to choose the right tool for the right job, instead of restricting your team to work with languages and tools that you understand and feel comfortable in.
As an architect, both the big picture and the intricate details are your domain. To be able to work in both areas, you need to be skilled at zooming out to see how all the parts work together to satisfy business requirements and zooming in to see how each detail fits into the overall design.
Being able to switch between, without losing your focus on what is important in the moment, will help make you a great software architect.
In the beginning of the project, there’s a lot of noise. You have future requirements, past ideas, legacy tech, and everyone’s opinions on what’s important and how you should set about making it all happen. From all this information and static, you need to be able to zoom in to that one piece—that one pixel—and decide here is where we need to start.
I like to think of it like a Fourier Transform. At the start, there’s a cacophony of frequencies. You’re the algorithm that takes the chaos and spits out those discrete pieces of information that give your team a good starting place.
For the most part, we’ve been talking about how to succeed as a software architect from a pretty high level. But if you’re interested in the role, you probably need something a little more concrete. You want to know if all that personal growth above is moving the needle at all.
Everywhere is different, but here’s a list of measurables you can look at to give you concrete feedback on how well you’re doing.
This is one of the most telling indicators of your architectural decisions. You'll want to track not just the frequency of incidents, but their severity and duration as well. A well-architected system should experience fewer critical incidents, and when problems do occur, they should be contained and resolved quickly. If you're seeing an uptick in severe, long-lasting incidents, it's often a sign that architectural decisions need revisiting.
These tell you how well your architectural standards are being followed across the organization. This includes everything from security protocols to coding standards to deployment procedures. Low compliance rates might indicate that your architectural guidelines are either too complex, poorly communicated, or not aligned with the team's actual needs.
This is a blog post on its own, but briefly stated, managing tech debt requires a two-pronged evaluation. First, assess how much tech debt you're actually dealing with—is it growing, shrinking, or staying constant? More importantly, evaluate how that tech debt is impacting the business. Some tech debt is acceptable if it's not slowing down feature delivery or creating operational headaches. The key is understanding when tech debt crosses the line from manageable to business-impacting.
When it comes to metrics, focus on execution against expectations. Are you consistently meeting the timelines you've committed to? More critically, are you delivering solutions that actually meet the business requirements? It's worth noting that being on time but missing the mark on business value is often worse than being slightly late with exactly what the business needs.
Brass tacks: this isn’t easy to measure, but it is important to try. The idea is to measure how well different systems and teams are working together under your architectural vision. Smooth integrations between services, teams, and external vendors indicate that your architectural decisions are facilitating rather than hindering collaboration.
Finally, cost management reflects your ability to balance technical excellence with business realities. This includes not just the obvious costs like infrastructure and tooling, but also the hidden costs of complexity, maintenance overhead, and developer productivity. The best architects find ways to reduce total cost of ownership while improving system capabilities.
If you’re a senior developer, or moved into an architect role from a senior developer position, the list of skills above will probably be all new to you. For some this change is a breath of fresh air, for others a rude awakening.
Stepping away from a purely technically-focused career isn’t for everybody. It’s not a reward. You want to really want to focus on how you can help the company build something at a different level. Correspondingly, I would counsel everyone looking to move into the role that it takes a very particular personality type to excel as an architect, as the Venn diagram of the prototypical architect and the prototypical developer don’t overlap as much as you might think.
That being said, the role can be incredibly rewarding, and the skills and practices we’ve discussed here will help you not only excel in the role, but enjoy it as well.
If you want to dive deeper into implementing and managing authorization, join one of our engineering demos or check out our in-depth documentation.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。