In a services firm, the solution architect is the person who turns a client's stated problem into something that can be estimated, staffed and built. When the role works, projects start with a shared understanding of scope. When it does not, sales promises one thing and delivery discovers another.
The most valuable output is not a diagram. It is a written statement of what the system will and will not do, which assumptions it rests on, and what happens if an assumption is wrong. Diagrams communicate structure; the assumptions are what disputes turn on six months later.
The role has to be able to say no during the sales process. An architect who signs off on whatever wins the deal has been converted into a proposal writer, and the cost lands on the delivery team who had no say. That authority needs to be explicit, because the commercial pressure is real and constant.
Equally, the architect must stay involved after signature. Handing over a design and moving to the next opportunity guarantees that the design is reinterpreted, and that nobody can explain why a particular decision was made. A standing commitment through the early sprints is usually enough.
Staffing the role is the practical difficulty. It requires enough engineering depth to be credible with the delivery team and enough commercial sense to be useful in a client conversation, and people with both are scarce. Growing one internally from a strong senior engineer works more often than hiring for the combination.
For a firm of moderate size, this is often a part-time responsibility held by one or two senior people rather than a dedicated title. That is fine. What is not fine is the arrangement where nobody holds it, which is the default and which shows up as a pattern of projects that overrun for reasons discovered in week three.
