Knowing that you are staying on task isn’t an easy task 🙂
As we build solutions, it is easy to lose conceptual integrity along the way. There are few things more important to the success of a project than having a development team all on the same page.
Fred Brooks (from Mythical Man-Month) put a high premium on conceptual integrity:
“I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas than to have one that contains many good but independent and uncoordinated ideas.”
An architecture review meeting is really a checkpoint meeting, designed to ensure that the team is all working toward the same goals. Part of that being on the same page is ensuring conceptual integrity. Part of it is just making sure we have communicated the architecture correctly.
Who should attend this review meeting?
- Project Manager
- Project Owner
- Core use cases
- List of activities
- Architecture Design
- Static – Static Tiers
- Dynamic – Call Chains
- Project Plan / Project Design
- Solution Skeleton
Questions to ask (checklist)
- Do the core use cases seem correct?
- Does the architecture fit the core use cases?
- Does the project plan / design seem reasonable?
- Is this achievable?
- Are there any technical risks?
- Do these need to be de-risked?
- Does the solution skeleton match the architecture?
- Are there smoke tests?
- Would anyone change the plan / architecture?
- Is there an outline of a test plan / strategy?
The architecture reviews are quick meetings that get everyone on the same page, effectively making sure we are all building the same software. Rework is a huge source of expense in software projects. Some rework is difficult to prevent, but other rework — such as design rework — is largely preventable. Making sure everyone knows where we are going can greatly reduce the likelihood of rework caused by a design.