Architecture Recommendation

Given a fictional enterprise scenario, produce and defend a recommendation — upstream, a named enterprise distribution, another traditional NOS, or a mixed model — justified by risk, staffing, support, features, and total operational cost including labor. The deliverable is a written recommendation backed by the Lesson 5.4 scorecard.

Prerequisites: Lessons 5.1–5.6 complete.

Tasks

1. 1

   Read and characterize the scenario

   Example scenario: 'Meridian Freight operates two regional data centers, runs a 6-person network team with no software-build experience, is subject to industry regulation requiring documented security advisories and audit trails, currently runs Dell OS10, and wants to modernize its leaf-spine fabric with EVPN/VXLAN over the next 18 months on a predictable budget.'

   Extract: engineering capacity, risk tolerance, regulatory constraints, scale, existing vendor relationship, and timeline.

   Expected:

   • A short written profile of the organization's capacity, constraints, and priorities.

   What happened internally: The recommendation must follow from the organization's actual capacity — this task forces you to name it before choosing.

2. 2

   Fill the scorecard for each candidate

   Score upstream, at least one enterprise distribution, and 'keep/extend the traditional NOS' against the Lesson 5.4 rows, including operational-staffing and TCO-with-labor.

   Expected:

   • A completed scorecard per candidate with go/no-go rows marked and TCO including labor.

   What happened internally: Forcing the staffing and TCO-with-labor rows is what prevents a naive 'upstream is free' conclusion.

3. 3

   Write the recommendation

   State the chosen model (upstream / named enterprise distribution / traditional NOS / mixed) in one sentence, then justify it from the scorecard.

   Expected:

   • A clear recommendation justified by risk, staffing, support, features, and total operational cost including labor.

   What happened internally: For the example scenario, a small team with no build experience under regulation typically points to an enterprise distribution or staying on the traditional NOS — but the justification, not the label, is what is assessed.

4. 4

   Name the accepted risks and a review trigger

   List the risks the recommendation accepts, their mitigations, and when the decision should be revisited.

   Expected:

   • A short risk-and-mitigation list plus a defined review trigger (e.g. staffing change, scale threshold, vendor release).

   What happened internally: Every model carries residual risk; naming it and setting a review trigger is what makes the recommendation professional rather than dogmatic.