IMHO, there's no such thing as a Software Architect. Take this for what you will, but people that label themselves as being architects are an instant red flag, as that's usually corporate slang for I'm incompetent, but I can draw diagrams and have meetings.

The industry is simply separated in developers that suck (because they lack either the experience or the ability) and those that don't and that are thus capable of making good decisions.

As to how to get there, there's no simple recipe, but in general you simply have to (1) read a lot, like books, papers, other people's source code and (2) you have to get burned by a lot of bad choices you've made and learn something from those mistakes. Both have something to do with getting out of your comfort zone.

I have to disagree: There certainly are people who can keep (very) large systems in their minds and refine and extend them, but they are very rare and most of the people who might call themselves "Software Architects" are not.

It might be said that the definition of "size" for a computer system is exactly the degree to which it requires "architecture" to make it.

Under that interpretation one way to try to become a "Software Architect" is to study large systems and how they succeed or fail at their intended purposes.

Well, I can tell you easily how a large system (to the degree that it requires a architect to understand) get successful: They don't.

Successful systems may get large, and as a general rule, large systems do not get successful. Once in a while a large system is so well written that it fits inside the head of anybody, and it has a chance of success. You can never get one of those later if there's interference of people that do not code directly.

In my opinion, what works in the small also works in the large and even though there may be caveats with this rule (e.g. synchronous communications vs asynchronous ones that may introduce non-determinism), if you stick to the rule of building simple components that do one thing and do it well and them combine them to build bigger components that are still simple (in the non-entangled sense), then you'll definitely do a good job. But that's easier said than done because ...

There are two types of problems here:

1. doing design mistakes because you make a decision that you never took before and then you get burned by it - as an example you might introduce unwanted cyclic dependencies between your components and if you're talking about different address spaces, then things can get really problematic, or you might introduce concurrency concerns (like in the communications between components) that could be avoided - problems that you won't avoid until you get burned by them.

2. some projects have an incredibly complex business logic - I'm working on such a project right now and the business logic is like a freaking fractal. Being so complex and the architecture being based on micro-services, the downside is that people are only willing to understand only as much as they need to for the components they are responsible for. On one hand that's good because that's how you parallelize the development effort. But then the people can't view the big picture anymore and this is usually a failure of business analysis, because truth be told most systems are built with a primary purpose (for example the primary purpose of an email platform is to send emails in bulk) and then the "stakeholders" lose sight of that and come up with often useless and often conflicting features that detract the developers from focusing on the primary purpose (e.g. what use has an email platform that's shitty at sending emails). The end result in our team is that a single man knows all the business logic details and dealing with that takes so much of his time that he does not have time for software development at all.

I do not agree with you on studying large systems. Large systems that have to be studied because they are large are in my opinion a failure of design that shouldn't be copied. IMHO, much better is to develop a nose for simplicity and always strive to build simple things, while also pushing back on the amount of work needed by simplifying the business logic.

While I agree with you that the people that can deal with the above are incredibly rare, I'll stick to my initial claim ... people good at it are software developers that (1) are always studying new ways of thinking and learning from others and (2) that try to do things and get burned a lot.

And nr. 2, the experience you've got, is incredibly important. There's no amount of studying that you can do for successfully recognizing and fixing or avoiding concurrency problems (and btw, I'm not talking about multi-threading here, but about the general issue of concurrency that can happen in all sorts of communications). There's no amount of studying you can do that can help you recognize entanglement that shouldn't exist in the architecture. Sure, books help, but books don't fix the superficial attitude that rookies have towards such problems. In order for one to learn, one has to build stuff and suffer from such issues and then improve.

Good news is that if one follows the above advice and gets out of his conform zone, then one can short-circuit the learning process to about 5 years instead of the usual 10.

So what would be the non-"red-flag" way?

I mean things like: "Problems X, Y, and Z are actually all caused by the other teams trying to work around the bad build-system. We should fix that first."

Pitch yourself based on what you've done, not who you are. Saying "I'm a software architect" is a red flag for "I'm incompetent and can't actually write code", saying "I built this software system (which you can see at this URL) from the ground up" or "I led a team to build this software system, and here's why it's hard" communicates exactly what you can do.

You build things the public is ever allowed to see? Lucky. :(

IMHO, the exposed problem is exactly what's wrong in many development teams. What should happen is this:

1. somebody is feeling too much pain because of the shitty build system, therefore ...

2. that somebody simply setups an alternative and then shows everybody else how great it is compared to the current build system

If this doesn't happen, then the team is fundamentally broken, either because the team has only rookies in it (and rookies tend to be masochists that can take pain) or because the developers simply stopped carrying about the project, for some reason or another (which might be legitimate) and just do the minimal amount of work to cash in their paycheck. If this happens and the build system doesn't get fixed by somebody, then the main problem is not a shitty build system, but a broken team.

The good news is that you don't need an architect label to fix a broken build system, or certifications or other such bullshit. You just have to care enough and invest some effort in fixing it, with the realization that nobody is going to do that for you. Incidentally that's how you get better - sure you might make mistakes along the way, but people that change things are the people that get really good at it.

That isn't actually a position. If you have good devs, the other teams will have communicated that up; if you have good managers, they'll in turn give the teams the freedom to fix the build system (or to work with the devops team to fix it, if there is one).

I think there is such a position. If there are multiple teams, then it's important for someone (a good programmer, but whether they're called "manager" or "lead" or "architect" isn't the point) to have a good understanding of what's going on in all of the teams simultaneously. That person can notice problems that the programmers down in the weeds (even if they're called "senior developer" or "lead") might not be able to see, or might not even think of as being a solvable problem.

Doing this properly for 3-8 teams might well leave that person with little time to contribute meaningfully to any given project, but the bird's-eye view can be very much worth it.

So what you're describing is a 'senior developer' or 'lead developer', who is noticing that the build system is an issue, and reporting it up and suggesting issues.

Whereas I said "If you have good devs, the other teams will have communicated that up".

The only difference I'm seeing is you're positing someone who is aware of developer issues, and 'with little time to contribute meaningfully'. How, if the person isn't developing, is he/she going to be able to tell what the development issues are? He/she can't just ask the developers; if they're aware of it they're not 'down in the weeds', and just communicating it upwards is enough.

I'm pretty sure this issue is best served with a retrospective.

At the OOPLSA 1998 conference, I attended the inaugural meeting of the Intergalactic Society of Software Architectural Awesomeness Rex [1].

Also there was Grady Booch, holding the floor. I was a bit star struck.

When I finally spoke up, I asked "What's software architecture?"

Booch pondered for a moment and then said "Software architecture is what software architects create."

Pop. No longer star struck.

I did eventually find a definition for software architecture in the book "Design Rules: The Power of Modularity". Their definition is (from memory) architecture is the set of visible design decisions for a product.

TL;DR: Don't sweat it. Just write software.

[1] I may have misremembered the name of the organization.

IMHO, and this is really just my personal opinion, the only way to learn how to build a big system is to build one and learn the extent of your ignorance by failing at it the first few times out.

I started a decade ago on my first job on a 20.000 line web app developed with two other guys. Over time that became a 700.000 line system developed by several dozens of people and on track to be a million lines in two years. Between then and now I've learned that I'm very ignorant. I still feel like I'm trying to figure this stuff out and not quite succeeding. :)

As a good second-best choice, try contributing to a large open source project. No books will teach you this stuff, you have to do it to learn it.

If you can work on a green-field project, you'll get a LOT more experience implementing new things that exercise your architect muscles, and you'll be around architects that you can ask why they are making decisions they are. Versus working on an existing project, where you tend to just fix bugs or figure out how to hack in a new feature without breaking what's there. (I don't know which of these camps you're already in, but in general I think it makes a big difference.) (Disclaimer: I am a jr dev, but see a world of difference between what I get to learn and others at my level because of my project.)

One would hope your company would be making these investments in you.

As a developer at [Large well-known software company], after my first year I started being given leadership roles in minor stories, then major stories, then epics that breakdown into major stories.

If the company you work for is not giving you growth opportunities, one might begin to wonder how they picture your future.

Side note: "Software Architect" as a role sounds way too Waterfall to me. People should have varying skills at design, and work together to build the best thing they can. Not have an Architect who claims omniscience and designs the whole project up from.

build your own thing, that's the best way IMO.