You can't address this topic without first defining what software architect is. So here I opt for the rather nebulous "the expensive, hard-to-change decisions about how the software is constructed" definition.
A few years ago, you would have heard hard-core agilista touting the "there are no specialists, everyone is a team member" line. Even then, you could scratch the surface and ask the tricky questions about UX designers, DBAs and other specialist roles. When pushed, you would get concessions that amounted to either short-term embedding in the team (just another team member) or external consulting / standard compliance (just another stakeholder). A few years on, the community has matured (some might say regressed) and amidst the creation of it's own specialists (e.g. DevOps), admit the need for specialised roles.
Within, or around, an agile development team you need someone to be doing the following:
Identifying what the expensive, hard decisions are.
Providing coaching and guidance on technical approaches to problems.
Identifying appropriate standards and enforcing them.
Acting as a developer's conscience, for those times when it would be so easy to take a short cut, but so painful in the future.
Retain and maintain the big-picture vision.
Ensure the ongoing cohesiveness and consistency of the solution.
Advising on preferred solutions.
Making sure the cost of the solution is commensurate with the business benefit derived from it.
Identifying when you can no longer delay and have to make one of those hard to change decisions.
I would be the first to agree that there is no reason why a talented senior developer with appropriate leadership skills could not do any of these - perhaps in concert with others.
I would also agree that an architect embedded within a team could also actively contribute to the team delivering.
But there is also the matter of responsibility, and often, even in agile teams, a responsibility shared is a responsibility forgotten. In a team of explorers, or a team of soldiers, someone holds the map and compass (or the sat-nav). I have worked alongside many talented senior developers, and with the ongoing pressure and responsibility, with a focus on the problem that lies in front of them, it is very difficult for them to not get lost in expediency or elegance, and lose sight of the big picture. This is especially true at the tail end of a project. The result being that the delivered solution, which began with such promise, ends up being (at least) slightly muddy/corrupted/confusing.
There is a (much needed) role for an architect on an agile, it just may not look like some of the roles of old:
They are a coach, not a commander.
They make Just-In-Time decisions, rather than big Up-Front decisions.
They make decisions with incomplete information, rather than researching in depth until they are satisfied they have covered all the bases.
They work with the team.
They deliver working, production-ready code, not just diagrams and documents.
Comments
Post a Comment