A good day...
Architects can work in the Product Planning team with the Product Owner and help define the architecture to support the User Stories. They can sketch out a skeleton.. an emerging road map that looks enough past the planning horizon to help the Product Owner and the development team envision the target state. And they can work with any developer or engineer (in a paired style) to develop prototypes/spikes.
Not such a good day...
Then you have special technology projects, new technology projects, flooded with new tools that only SMEs or consulting architects know about. Even the Product Owner can often feels so agitatedly dependent on their 'god-like' consulting architect that seem to promise the earth and never deliver anything tangible. And to add to it, they don't like to share enough of their expertise so the development team feels like they can't seem to go anywhere. The architects run away with the spike. No one knows whats happening. They go into a rabbit hole. And all they say at stand-ups is "its still in progress". When they are a part of our team, its difficult for the team.
What does a Scrum Master do to help?
All governance, no delivery
Architecture governance is a good thing. Larger organisations need it, the world needs it. It gives us standards which in turn gives us nice things like the internet, frameworks, etc. The best standards emerge from good development practice (not really the other way around). When governance is a gate for blueprints to be passed into development by first being vetted by people in architecture roles that have not developed for a long time, it just sounds (and turns out) ODD!
Often architects go towards consulting and end up in "reporting up" roles that slow down real development. Emergent "agile" architecture needs, Senior system engineers (aka Architects) to be able to share their expertise to bring on the younger engineers into how they see things work. Part of emergent architecture also need to "include" younger engineers in actively, 'hands-on' learning exercises, coding dojos, etc to share knowledge grow the teams capability rapidly via collaboration rather than some lame, late, incomplete, out-of-date, architecture design document.
Can emergent architecture work with governance ?
Using an emergent architecture approach requires a few key artefacts and one key activity..
- Thing > Domain Model - (we all know this, if not google it) This should preferably not be too emergent.
- Thing > Solution Road Map - this one is diagram with high level connections of how everything comes together, likely with 2-3 transitions states describing how the solution is expected to evolve based how much is know about the solution.
- Thing > Mapping to Enterprise Architecture Capabilities - This is important. As architecture emerges, architects must map their solution components to an organisation domain model to allow future enterprise initiatives to weigh-in already built capabilities. This mapping must be stored in a model repository like Sparx Systems EA, ARIS, RSA or whichever tool is used to store the domain model. Preferably one that support a good "tagsonomy".
- People > Actively pair programming on spikes with developers and engineers - In my opinion, architects must actively participate in paired sessions to learn coding and stay close to engineering while sharing their perspective on the design for the solution as it 'emerges'.
