Architects – do you know if your team members are embracing your work?


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:

Typical Solution Component Collaboration

• A picture showing the architecture dependencies between the major subsystems which teams are usually formed around.

Solution Component Build Dependencies

Solution Component Build Dependencies

• 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

Configuration Management Centric Development Flow

Configuration Management Centric Development Flow

• A high-level diagram that illustrates how all the key processes relate to each other

Enterprise Modeling to Sprint and Release

Enterprise Modeling to Sprint and Release

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
• Dependencies
• 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 🙂

  1. #1 by Adrian on March 25, 2014 - 1:47 pm

    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).

(will not be published)

*