|Software delivery shouldn't be a conveyor belt.|
It encourages high WIP, and low collaboration.
2. Working Software
If your company thinks that they can be much more efficient having architects working solely on the "initial design phases" of projects then they're mistaken - they should take a long hard look at how smoothly "implementation phases" typically go, and the quality of life of their Ops and Support folk.
- Identify and build relationships with all the stakeholders for a particular change (Marketing, Ops, Product, Technical Support, Service Desk...) to make sure that as many aspects as possible have been considered, everyone's aligned, and there are no nasty surprises for anyone later on (including you, if an unexpected requirement or constraint pops up at the eleventh hour).
- Brainstorm, refine, and choose a technical approach in collaboration with the team that will actually implement it.
- Get your decisions and design ratified with all the stakeholders. This is the scary bit. As an architect, your work will be scrutinised and critiqued more widely than anyone else's (except perhaps UX and front end designers, poor bastards). If it's not, then I'd say you're not doing your job properly.
4. Responding to Change
- Be simple
- Be modular
(I have a blog post brewing on how we should define and evaluate the effectiveness of people and teams, but here's a spoiler: It shouldn't be how complex and clever we make things).
Blindingly obvious things get overlooked all the time. An architect should be one of the key people making sure that doesn't happen.
5. What not to do
Separate Architecture Team
- They'll be making decisions they don't understand
- The team won't understand or embrace the vision
- The team's unlikely to have any respect for the architect.
Formal architectural governance
But if technical decisions have to go through an Architecture Steering Board, made up of senior techies who, at a distance, make decisions about projects, grant dispensations to "divergence from the original designs", or document "corrective actions" to go on a "programme register" etc. etc., then people simply won't bother. People will work around it.
Accurate Architecture Models
The main value of architecture diagrams is to communicate a concept. These tools, which strive for accuracy, impose limits on the kind of information you can convey, Typically you'll struggle to bring out the important features without showing the unimportant ones too. And with a restricted palette of visual indicators, you won't be able to bring out all the things that matter (high risk areas, data flow versus flow of control, areas that are changing in different phases, variations by environment, areas holding or transporting sensitive data, and so on).
And of course you'll probably diagram the same thing more than once for different stakeholders at different levels of abstraction - and no one likes looking at diagrams which are uniform and soulless. As humans we like things to be visually compelling, and tools like EA really, seriously, aren't.
|Avoid hand offs. Get the people you need |
working together on each small thing, all the
way through. That includes architects!
But that doesn't mean that they shouldn't involve themselves in the detail of the implementation. Architecture should come from the people who know the detail, and be ratified by them (as well as all other stakeholders). It's the architect who makes all this happen - collating, rationalising, and aligning - driving technical decision making. Ensuring that the design is as simple as possible, and as modular as possible.
Finally, the architect should be a member of the implementation team, collaborating on design just in time, rolling their sleeves up when necessary, and paying attention to the build, deployment, and operational support of the stuff they build.