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.
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.
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."