I've spoken to, interviewed and screened a lot of CVs/resumes from senior developers and architects recently and there are a lot of baton hand-offs going on. One of the great things about small or agile teams is that the same people capturing the requirements are more likely to design, build and test the implementation of those requirements. With larger teams, this might not be the case, particularly if the teams are aligned with a specific discipline (e.g. requirements capture, analysis, design, etc).
Anyway, I want to focus on the architecture side of things. I've noticed that there are a lot of people calling themselves "solution architects" or "technical architects" who define an architecture and then throw their solutions over the wall to a separate design and development team. What's worse is that often nobody takes ownership of the architecture, and the original architect takes only a cursory glimpse at the progress from time to time.
Of course, everything we've said about the role of an architect in the past still applies. Given that the role of the architect includes taking responsibility for satisfying the non-functional requirements and for quality assurance, I now have a much better understanding of why so many software projects fail. Some architects just aren’t involved enough to make them a success. Software development isn't a relay sport; it's something that you need to look after.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.