Team Review

Review with the team

Review is important for several reasons:

1. Validate...
   • your design matches the goals, features and restrictions of the project.
2. Prepare...
   • the developers and the business team relying on the system architecture.
3. Gain the confidence...
   • of stakeholders and the team. Show that the architecture is solid.
4. Confirm your part is on track...
   • and the team can move to implementation.

Focus

The process of reviewing your solutions and plans is similar for Business and Tech.

Prefer 2 separate meetings to focus on respective concerns.

Business System Design review:

• Focus more on high level requirements they gave in the 6U and functional requirements.
• Don't get too technical. This will only confuse non-tech people.
  • Good:
    • "Our API handles all user requests. They can create orders and get the order info."
  • Bad:
    • "Our customized resolver in the API Gateway coordinates with a FIFO messaging queue optimized with 3 autoscaled replica nodes. Edge Lambdas handle static asset rewrites."
• Keep it short only to their exact requirements. Talking too much can lead to "overselling" and causing doubts.

Tech System Design review:

• Prior to the meeting,
  • Key players should already be aware of your solution and have given feedback.
    • "The database we are using is DynamoDB, like another similar projects we did, do you see any issue with that in this case?"
    • "Any gotchas about this I should be aware of?"
    • "Do you anticipate this will still be a valid choice 6-12 months from now?"
  • Don't be blindsided by sudden objections to your design, or new info affecting it.
  • If you expect challenges, come prepared with evidence/backing.
  • Get buy-in from specialists and key players related to it.
• Spend extra time soliciting tech feedback on hidden potential tech restrictions
  • upcoming network changes
  • upcoming deployments affecting your design
  • upcoming staffing changes
  • tech organizational or infrastructure requirements or approvals needed.
  • timing along with other projects
  • external dependencies and related timelines, such as reliance on external vendors/timelines.

Tech Review Process

Below is focused on the Tech Review.

For business review it's similar, perhaps a shorter 30m meeting.

Remember, not too much tech detail for the Business review. You do not have to run through all the tech options in too much detail. Just mention other options were considered, perhaps the "headline" and why it does not work.

Success tips

1. Get full buy-in from all key player separately BEFORE the meeting.
2. Know where each key player stands (who may object, why, and have well-prepared response).
3. Have all key choices/points supported up by specialists quotes and external references.
4. Make checklist for meeting of all major items here that have to be completed successfully.
5. Confirm your video presentation such as screen sharing are working prior to meeting.

0. Pre-Presentation checklist

• Schedule the meeting at a time that is convenient for all attendees
• Ensure all key deciders are attending.
• Reschedule if interruptions anticipated, health or others issues affecting ability to present.
• Check that video, microphone, and screensharing are working properly.
• Have a backup plan in case of technical difficulties (and/or another partner who can take over).
• Have necessary slides/screens ready before the meeting.
• Use 2 screens, one for sharing, one personal with notes, checklists and references.
• Bookmark folder with meeting-relevant bookmarks on your browser to quick references.
• Non-shared notes a list of key points you need agreement on. Follow that list!
• If anticipating objections, be prepared in advance with good responses.
• After each main point, confirm meeting attendees understand the point and have no objections.
• By planning ahead, you minimize the risk of the meeting failing due to non-architecture related issues.
• have a plan to follow up with attendees after the meeting.

1. Presentation Demeanor

• Calm, thoughtful, stable, confident.
  • Purpose: get the team unified behind your design.
  • If debates or objections, try to mediate, resolve disputes and followup.
    • Take the approach of the thoughful professor balancing all sides.
  • Worst thing would be to get in a huge argument dividing everybody.
• Presentations style
  • Slides with applicable images, diagrams, tables
  • Not too much text.
  • Not too many slides or too long.
  • Not rushed, cramming in 1 hour of presentation into 20 minutes.
  • Be organized, like an outline, main topics and subtopics.
  • Video chat is preferable so it can be easily saved, shared, slides referenced.
• Circuit breaker: if you are NOT confident in your design (options):
  • do not have this meeting until reasonably confident
  • solicit help from specialists, get their feedback, reference it,
  • support your choices with external references,
  • solicit other architects in your org.,
  • tell leadership of the difficulties,

2. Review of 6Us and Functional Documents (5-10m)

• Review 6U responses in brief.
• Review priorities.
• Review additional UX, diagrams

3. Review potential technical solutions (10-15m)

1. High-level options
   • Solution option 1 - not good due to multiple issues.
   • Solution option 2 - better, but still some issues.
   • Solution option 3 - contender but not perfect.
   • Best Solution option 4 - best option based on priorities, evidence
2. Table
   • Options in a column, each problem in the row, best solutions.
   • Highlight the best choice, which should be obvious by the table.
   • Best choice should be in the 1,2,3 column never the end of the table comparisons.
3. Discuss how this fits into the UCROPS architectural workflow
   • Why this option is best for addressing need and priorities of
     • Usability (external and internal)
     • Cost
     • Reliability
     • Operations
     • Performance
     • Security
4. Add any other resources, evidence supporting your assertions.
   • Do you anticipate any of your assertions to be challenged/controversial?
   • Anything new presented that nobody else was aware of?
     • If so, bring evidence/resources to the meeting.
   • If there are external recommendations or reference architectures, then have those handy.
5. How your plan fits in the goals/priorities of stakeholders, tech team, company.
   • Fits in with other requirements at the org. and department level
6. Reference buy-in with other leads, SMEs
   • Make sure to mention you have agreement from other specialists

4. Soliciting feedback (10-15m)

1. Its good to get buy-in for each element in advance.
2. You should be aware of concerns already and have addressed them before this review meeting
3. Reason for asking is if there are last-minute concerns/issues, new dependencies to consider etc.
4. Objections - if objections
   • Keep things polite and calm, don't take objections personally.
   • Politely say "Those are good/interesting points. Those can be considered, I will follow-up".
     • Make sure to followup.
     • Don't go immediately go behind their back to overrule them or ignore their concerns.
   • Follow up with research either confirming or denying the objection.
   • Get buy-in from the person who made the objection.
   • Tactfuly, share the buy-in with the rest of the team (objection resolved)

5. Wrapping it Up (5m)

• Summarize what you did in the meeting.
• Confirm that your systems design addresses the functional requirements.
• "Assume the sale" if no major objections:
  • "I'm glad we're all in agreement and can move forward with next steps",
• Confirm the team's process and what next steps are needed.
• Confirm the project manager has or is scheduling the implementation.

Avoiding Problems: Why the Systems Review Fails

1. The architect missed key details or features. Looks uninformed.
   • Reasons:
     • Not enough info, bad info, or unsure of how to put it together
     • Poorly planned objectives, no functional document
     • miscommunications, missed key details
   • Remedies:
     • Get all details in writing/video and REVIEW CAREFULLY multiple times looking for gaps.
     • Send an email to stakeholders, confirming your understanding of the key details.
     • Compare to checklists on this site, make sure you are aren't majorly contradicting standards.
     • Use tech team checklists/best practices, (ie. Security requirements is a common one)
     • Seek out specialists for info and validation-- network with and reference other smart people.
     • Validate from other tech members, senior devs and leads and solution architects.
2. The architect made incorrect assumptions about services recommended,
   • Reasons:
     • Did not ask the right questions, or get details
     • Did not consider all options
     • Did not have the knowledge necessary
   • Remedies:
     • Confirm all details with the 6Us and Functional Document.
       • Are there "orphan" ideas, user roles or screens?
       • Did people attend the review who have roles not represented?
     • Confirm all key assumptions (document approval).
     • Are you missing key assumptions?
       • Walk through the assumptions, results and benefits methodically and logically.
     • Use Reference Architectures and Best Practice patterns (ie. AWS, Azure, GCP).
     • Use UCROPS architect workflow on each technical service and overall, to compare services.
     • Google some key assumptions you are making.
     • CYA, and validate when requests are made "These are all the key details I took down-- is there anything else missing here that would prevent us from launching?"
3. New requests require design changes.
   • Use key checkpoints to confirm no new feature requests.
   • Write an internal contract, that the plan is final.
   • Make clear to leadership and stakeholder and document that changes will result in extra time required.
4. Disputes from less relevant participants.
   • Too many participants invited.
   • Avoid too many decision-makers, it can derail and cause delays to have many people trying to make changes or put their stamp on ideas/designs.
   • Invite key players and make sure you have their buy-in.
   • Confirm with project manager who the "deciders" are in advance.
5. Presentation is disorganized makes architect look like a scatterbrain
   • Confirm your video, microphone, and screensharing are working.
   • Confirm you invited all key deciders and they are attending.
   • Confirm all major slides/screens are queued up before the meeting.
   • Have 2 screens, one you are sharing and one with your notes, checklists and references.
   • Have a Bookmark folder with meeting-relevant bookmarks on your browser to share quick references.
   • Have in your notes a list of key points you need agreement on. Follow that list in the presentation
   • If anticipating objections, be prepared in advance with good responses.
   • After each main point, confirm meeting attendees understand the point and there is no objection.
   • If you planned all above, this will minimize risk to the meeting being disorganized.