Architects are supposed to sit higher, seeing both more systems (where developers focus on theirs) and seeing further in time (where developers are focused on their next release or two). I see the job of an architect to work on how things work together and make sure nobody "paints themselves into a corner".

How well that works in practice is another matter of course. Architects have longer reach than developers, both in space and time, so the have larger blast radius. One bad architect can screw vastly more things than a bad developer.

I've just seen a project desperately needing one. I'll have to be a bit vague in the description here.

The project is migrating a lot of small interconnected pieces of software, each managed by its own team. None of the teams has any idea what the others are doing. There are smart people in the project, but each is on his own island.

It turns out one of the pieces of software has been installed twice in 2 different locations, for decent reasons. Nobody noticed, so while migrating they were mixed up and replaced with 1 instead of 2 new versions. The resulting mess of wrong interconnections is very hard to untangle and causes all kinds of weirdness.

Apart from that, no one really understands what has been delivered and what not, as nobody knows which chains of pieces are already complete. Different teams use different names for the same thing or even the same name for different things, so people don't even understand they are working on different aspects of the same thing. Recently somehow we managed for person A to configure a thing, while person B migrated it to a new server, loosing person A's changes.

A solution architect should have some overview of what all the pieces are, what should be connected to what, and how the whole thing should behave.

To me it sounds like the devs in these disparate teams need to talk more and work closer together, rather than having a person whose job is to increase the distance between them.

While this is technically correct, the problem is one of scale and organisation.

There are hundreds of people like this in the org, each responsible for one tiny brick. These people are included in dozens of projects and have a small task for each of these projects for a few weeks, then go to the next project. It is unreasonable to demand knowledge for all projects, the org is simply too big.

Personally, I'd say they need a more focused organisation: Everybody on 1 project at a time, and an enterprise architecture that does not sprawl one business task over all these tiny items so meaningful work can be done in 1 team. But this would require the top to loosen control a bit and trust people under them more. To be honest, it would also require all the people at the bottom to be more trustworthy and think about more than their own tiny world.

Trust relations in both directions are basically broken, the top tries to control their people like puppets, and the bottom reacts by protecting their own world against not always well though out orders from the top, no matter the impact on other people's work. Now you're talking about re-tuning the culture of a big corporation, which is very hard.

I've been one for the last seven years, and recently quit because I felt unable to make positive contributions to the success of the organisation due to the way the role had developed.

In an ideal world, solution architects are really your most senior design engineers, have long-term plans for how the sum total of your businesses IT systems fit together, and steer development, acquisition, and upgrades across all aspects (clients, network, back-end, in-house code, cloud etc) to turn those long term plans into reality.

Without that view, a businesses IT landscape will lack cohesion resulting in higher cost, complexity, and risk. Done well, architecture can keep all those things at better levels as well as serving as a bridge between the technical world and management that often doesn't have the domain knowledge to understand the implications of the choices they make. Likewise engineering (whether software, infra, or network) likely don't have an agreed view of all the stuff outside of the tech itself and architecture is a place for that to be considered. Stuff like what support processes and staffing needs to look like and how it will be funded, or ensuring that some compliance gotcha coming down the pipe in five years time won't conflict with some technical minutiae being planned for right now and likely to still be there, or utterly essential, when that five years comes to pass.

Now, that said that's just my personal interpretation and the role is interpreted quite differently from org to org. I probably won't re-enter the field because I have a dim view of architects that sit exclusively in the abstract conceptual realm all day long and don't/can't roll their sleeves up to design and deploy tangible systems and services any longer. The longer anyone spends in that abstract space, imo the more useless, self-serving, and eventually actively harmful their output becomes. Solution design and infrastructure deployment (storage, networking, client, systems management layer stuff) is more my speed but that realm is being eaten up by cloud in the SME space where individual contributions actually matter.

Architects that sit constantly in that abstract realm are useless (and they are not architects in my view). But there are architects that do exactly what you describe in your ideal world.

And that's why I had to go. What started out as the latter was drifting towards the former. In part due to the onwards march of IT services to cloud providers, but also attempts by the organisation to 'mature' their IT landscape, with the view that architects should certainly not be doing any actual engineering.

(imo) Solution Architects are popular in big enterprise environments exactly because the organisation as a whole doesn't use/isn't familiar with agile or the like. They have to figure out what solution the org is looking for, how to best integrate it with what they already have, and how to do it with the least impact on employees. If the org has poor information management, getting requirements is already a mess, and the SA is already screwed.

From what I've seen (with contracted SAs), SAs are just inventorying and working around the half-finished implementations the previous SAs left behind, ad infinitum.

>>>If the org has poor information management, getting requirements is already a mess, and the SA is already screwed. From what I've seen (with contracted SAs), SAs are just inventorying and working around the half-finished implementations the previous SAs left behind, ad infinitum.

^This has been my life for the past 5 years. I was the Information Management Officer for a military org with ~25,000 personnel, and our org suffered ~50% turnover in senior leadership EVERY SUMMER. It's been like groundhog day, every day. Operations personnel don't have the domain knowledge of the IT systems and Communications folks don't have the domain knowledge of the Operations, so neither side can put together a coherent, efficient architecture alone. The IMO is supposed to bridge that gap, focusing on documenting the business processes and helping to turn those into requirements, and possessing just enough IT systems knowledge to sanity-check the solutions proposed by the Communications staff. It's even harder to document the business processes when they are a) evolving b) rarely adhered to c) massive in breadth/scope. Sometimes the job entails telling Senior VP/ C-level staff that their proposed solution is dumb and completely unworkable.

Now I'm a contractor "Operations Research & Information Management Analyst" which basically means the same organization is paying me for my domain knowledge and continuity of experience in trying to get some good ideas from the past 18 months actually into production.

Previously I had looked into what might help me bill myself as a Solutions Architect while job-hunting and 90% of the resources I found were just "how to sell people on AWS." -_-

A lot of the time, their job is to say "no", and shut down some over-engineered solutions brought fourth by dev teams

This is my job now as of 2 months ago. Best I can figure, the value we add is talking to the customer and translating their requirements into a build diagram for devops team that fits into the constraints of the enterprise restrictions.

Hashing out ports for NACLs, nudging them to use AKS instead of Beanstalk, deciding whether they need connectivity to corporate network, validating whether they go into a high/medium/low risk account, etc.

Just as the process of building a bridge has a lead engineer, supported by likely many different different types of subordinate engineers, large IT projects succeed more with a similar structure and process.

If you're building a bridge over a small pond, iteration based on feedback from users will likely work well.

Software development is not like building a bridge, it's more like building a road blindfolded and without planning, and without knowing if the road is for pedestrians, trains, or boats... So you build a dirt road aka MVP, but if you are not lucky it might involve tunnelling and also a few bridges. The key is to first "walk" the path, rather then laying pavement from day one.

And then it turns out the client actually wanted a car, not a road.

Architecture is simple: it is that in your landscape that is hard to change. Making design decisions that are wise is the task of an 'architect', which is just another word for 'designer' (though it has been sold as something else). How you organise architecture processes depends on how you organise development, but the subject is the same. For instance, too much yagni is awful: everybody ends up waiting when something is needed that was not clear before. Finding those elements that improve your future speed is part of a good architecture process. Secondly, users are very focused on features and defects, but architecture is potential features and defects, and users are not a good source for those.