Architects can generate volumes of documentation and models, but who reads them? They can even model these things in tools, but does this ensure the architecture is followed?
My experience is in any project – large or small – you can usually tell if the architecture has become a shared vision by looking at the members’ work spaces to see what they have pinned to the walls. Or the one-pagers they bring to meetings. People will post helpful things in their cube:
• A picture of the reference model/conceptual model – a picture of the shared vision
• A picture showing a typical collaboration of the solution components:
• A picture showing the architecture dependencies between the major subsystems which teams are usually formed around.
• A picture (i.e. collaboration diagram) depicting a key design pattern meaningful to their work
• A checklist of items to consider before submitting code for the nightly build or sprint
• A high-level diagram that illustrates the flow of artifacts to coordinate a sprint/increment
• A high-level diagram that illustrates how all the key processes relate to each other
If isn’t pinned to their cube it is handy and people will bring them to meetings.
Solution implementation is a fluid thing and these diagrams must evolve. This is performed by a regular architecture/team lead “stand up” meeting. Not stand-up because people have to stand up, but because people are there to discuss items that matter. They are busy and focused on being productive. All subsystem/stream leads are focused on sharing critical items and gaining consensus that will move their team forward.
The facilitator is the lead architect – not because they know more, but because they are a good facilitator and believes a better architecture is made from ensuring the best ideas are leveraged no matter the source. The lead architect (or technical manager or scrum master) does have to have a breadth of knowledge to be able to understand all the topics discussed and ask questions to help the team come to a decision.
The meeting doesn’t talk about status, schedule, or resources. It focuses on the product and topics like:
• Points of integration
• Alternatives and recommendations to leverage the experience of others
• Shared services
• Recommended patterns, practices, and standards
• Technical issues to be researched and reported on at the next meeting
The meeting can be managed by using many different techniques:
1. When items come up that involve a subset of people, quickly identify the stakeholders and assign a working group to bring a recommendation back
2. If not enough information is available, assign someone to research the additional information
3. If a knowledge gap is apparent, the action item may be for the lead architect to schedule training
4. If the problem appears to be a vendor product issue, the technical person responsible for that vendor relationship takes the action item
Whether you call the facilitator the lead architect, technical manager, scrum master, or servant leader, they are the “glue” of the product and process for the design and build teams.
At the end of the productive meeting, the lead will update:
• The Action Item Log
• The Decision Log
• The Risk Log
Also the lead architect will reflect on additional action items that may be helpful to the team:
• One-on-one discussions to further refine the problem or educate members
• Additional formal training
• Engaging management with the vendor to gain better response time
• Additional tools (e.g. automation scripts) to help the team
• New or revised patterns
• Demos from a team that will help solidify the vision and encourage the team
• Informal sessions from a team member that performs really well on a technique that other people are struggling with
This person, the “glue” is many times invisible and behind the scenes helping the team leads/scrum masters of a team to be successful. They work with management behind the scenes to buffer the team from “necessary but evil” overhead. They encourage team leads when they are frustrated because they have been in that situation before and can empathize. The invisible super glue 🙂
As a Solutions Architect I could not agree more with your article but the sad reality is that most IT projects still do not see the value of such a role. They think that if you throw a bunch of BAs at a bunch of Software Developers then you will generate a working system. I think I understand now why over 70% of IT projects fail and that number is getting WORSE not better).