This unit is the proposal request (the RFP). The Task at the end is to write the technical response to it. That exercise forces every earlier module to connect: business architecture feeds the requirements, the requirements feed the architecture, the architecture feeds the estimate, and the estimate feeds the commercial case.
What you write is the technical response. A real proposal also carries sales content — case studies, references, commercial terms — which is someone else's job and is not what you are practising here.
Do not reuse Lumen artefacts. Halcyon is a different customer. Reuse the method from Modules 2–9 (how you find drivers, write ASRs, draw views, estimate). Copying Lumen stakeholders, components or numbers into this response is a fail.
The brief — Halcyon Standards Council
Fictional, like the case study. The particulars are invented; the shape is the shape these engagements actually take.
The customer. The Halcyon Standards Council administers a system of product and location identifiers used across supply chains. It serves roughly 180,000 member businesses across 22 industries, and its mission is to make supply chains legible: it sets the identifier standards, licenses identifier prefixes to members, and provides the education and support around them.
The domain. A member is licensed a 6–9 digit prefix. From that prefix the member derives identifiers and attaches descriptive attributes:
| Identifier | Format | Purpose |
|---|---|---|
| Product identifier | 12- or 14-digit | Identifies a product; renderable as a barcode for retail transactions |
| Location identifier | 13-digit | Identifies a physical or legal location; similar format, different attribute set |
Both are composed of prefix + a sequence of unique digits, which has a consequence worth noticing in the data model: a 9-digit prefix yields 100 distinct 12-digit product identifiers by varying the last three digits, and 1,000 distinct 13-digit location identifiers by varying the last four. Capacity is a function of prefix length, and members will ask about it.
Out of scope: member onboarding and prefix licensing. Assume a member already holds a prefix.
What to build — three modules sharing one data and system architecture on one platform:
- Create and manage product identifiers
- Create and manage location identifiers
- Access identifiers and attributes created and shared by other members
Whether these present as one application or a suite of related applications is left to you. That is an architectural decision the brief deliberately does not make, and you are expected to justify whichever you choose.
The three stated goals:
- A web-based solution that extends current functionality and improves the member experience through clearer navigation and work flow
- An architecture that supports the requirements, aligns with the Council's existing enterprise architecture, is maintainable by the Council's own staff, and is scalable and sustainable given projected growth
- Efficiencies and cost reduction for future enhancements, through a standard application framework and a scalable architecture
And a forward-looking clause that is a modifiability requirement wearing a disguise:
Future expansion may include managing and sharing data other than product and location identifiers, and extending sharing permissions down to individual field level. These are out of scope — but the design should accommodate them.
Goal 2 is the one that constrains you most, and candidates routinely miss it: maintainable by the customer's own staff rules out a technology choice the customer cannot hire for, however elegant. Goal 3 plus the expansion clause together say that cost of change, not cost of build, is the evaluation criterion.
Current systems and constraints
The Council already runs:
| System | Role |
|---|---|
| Member portal (legacy) | Username/password, used to request identifiers by filling forms that a back-office team then keys into a central store. Outages of a few hours are tolerated today; they will not be after go-live |
| Prefix registry | Source of truth for which member holds which prefix. Out of scope to replace — the new platform must read it |
| Enterprise directory / SSO | Staff identity. Members are not in this directory today |
| Enterprise architecture standard | Java on the server, relational data for systems of record, a content-delivery network in front of public pages. The Council's operations team can hire for this stack. A clever choice they cannot staff is a failed Goal 2 |
The supplier hosts the first release. From month 18 the Council wants the option to operate the platform with its own staff (still on the same stack), which is a portability constraint dressed as a commercial one.
Functional requirements
Written the way the Council wrote them — loosely. Making them measurable is part of the work, as in Module 3.
| Area | Requirement |
|---|---|
| Product identifiers | Members can create, update, retire and search product identifiers derived from their prefix. Each identifier carries a descriptive attribute set (the Council will supply an initial schema). Identifiers must be renderable as barcodes for retail use |
| Location identifiers | Same lifecycle as product identifiers, different attribute set. A member must not be able to issue a location identifier that collides with a product identifier in any context the Council cares about — "you figure out what that means" |
| Capacity | The platform must show remaining capacity for a prefix (how many identifiers of each length are still free) and refuse an allocation that would exceed it. Members will ask about this in the first week |
| Access and sharing | A member can find and read identifiers and attributes created by other members, subject to sharing rules. Default: attributes are visible to all members. The Council wants to change those rules later without a rebuild |
| Work flow | Create → validate → publish → amend → retire. The Council "may add approval steps later". Notifications by email on publish and retire |
| Search | Members must be able to search across product and location identifiers by identifier, prefix, and selected attributes. "Search should feel instant." Precise criteria to be agreed during design |
| Admin | Council staff can manage schemas, sharing defaults, and take an identifier out of circulation. Audit of who changed what |
| Bulk | Members with large catalogues will upload files. Format "to be discussed". Failures must be reported so the member can retry |
Non-functional requirements, as the customer wrote them
| Category | Requirement |
|---|---|
| Usability | A web-based experience with clearer navigation than the current portal. Works on a range of screen sizes |
| Maintainability | Maintainable by the Council's own staff after handover. Stack aligned with the existing enterprise architecture |
| Modifiability | Future sharing of data other than product and location identifiers, and permissions down to individual field level, are out of scope but the design should accommodate them |
| Performance | Routine screens should feel immediate. Bulk upload of "large" catalogues must complete "in a reasonable time". Precise criteria to be agreed during design |
| Availability | The current portal's occasional hours-long outage is no longer acceptable. A figure will be agreed in discovery |
| Scalability | Member count and identifier volume will grow (see assumptions below). The architecture should not need a rewrite to absorb that |
| Security | Authenticated traffic TLS 1.3 or better. Member data is commercially sensitive even where it is not personal data |
| Deployability | Robust promotion to live. Council staff must be able to operate the promotion path after handover |
| Configurability | Schema and sharing-rule changes without a code release where possible |
Integrations, volumes, growth
| Integration | Notes |
|---|---|
| Prefix registry | Read-only. Prefix length and ownership. If the registry is down, identifier creation must stop; search of already published identifiers should still work |
| Enterprise SSO | Council staff. Members need a separate identity approach — the brief does not specify whether that is federation with the member's IdP or accounts you issue |
| Barcode rendering | Downstream print and POS systems consume an image or a payload. The brief does not pick a symbology |
| Publish and retire notifications |
| Fact | Value |
|---|---|
| Member businesses | ~180,000 across 22 industries |
| Identifiers already issued | ~40 million product, ~8 million location (to be migrated) |
| Create/update rate, peak | ~120,000 identifier writes per hour at seasonal peaks |
| Search | ~15 million queries per day, most from member applications rather than humans |
| Growth | 8% more members per year; identifier volume roughly doubles in four years |
| Regions | Today one jurisdiction. A second region with different data-residency rules is expected within three years |
Out of scope: member onboarding, prefix licensing, replacing the prefix registry, payment, the Council's public education CMS.
Use assumptions wherever the brief is silent. Mark them. Rates for the commercial section are yours to choose; say what you chose.
How a proposal response is structured
The technical solution is a minority of a real response. The rest is what convinces a customer you can actually deliver it:
| Area | Typical sections |
|---|---|
| Executive summary | The whole case in non-technical language, for people who will read nothing else |
| Recommended approach | The solution in outline, before any detail |
| Solution | Architecture; integration approach per interface; data architecture; security architecture; performance and availability |
| Delivery | Roadmap and timeline; phase-by-phase approach — discovery, design, implementation and integration, transition and launch |
| Service capability | Team structure; support process; service levels; how effectiveness is measured; governance and escalation |
| Infrastructure | Hosting; environments — production and non-production; sizing |
| Management | Communication plan; project metrics and reporting |
| Commercial | Estimate, resource plan, cost, assumptions |
Two observations. The delivery phases map exactly onto Module 7, so that exercise output drops straight in. And the service capability section is where proposals are most often won or lost, because it is the part that speaks to the customer's real fear — not "can you design it" but "what happens in month fourteen".
What to reuse from each module
The capstone is deliberately the integration point. Work it in this order on Halcyon, not Lumen. Each step consumes the previous one's output:
Write the executive summary last. It is the section the customer reads first and judges you on, and you cannot write it convincingly until everything behind it exists.
What reviewers actually reject
These are the recurring failures, and none of them are about being wrong on technology.
A weak executive summary. It is the most-read and least-worked section. After reading it the customer should be able to see that you understand their business and its current state, that the proposal covers current and future needs, and that it will land on time and on budget. Write it last, from the finished document.
Diagrams that are boxes of boxes. A high-level diagram with no interaction, no protocol, no direction of dependency communicates nothing beyond "we know the words". If a reader cannot tell who calls whom, how, and what happens when it fails, the diagram is decoration.
Components named but not described. Every architecturally significant component needs its purpose, its stack, its relations and — critically — which requirements it satisfies.
Quality attribute requirements never addressed. The most common serious defect: the ASRs are listed in one chapter and the design in another, with nothing joining them. Every high-priority scenario should be traceable to the tactic and component that delivers it.
No traceability in either direction. You should be able to start from a requirement and find the design that satisfies it, and start from a component and find the requirements that justify it. Anything with no requirement behind it is scope you invented.
An estimate that does not reconcile with the plan. Reviewers check. If development totals 400 days and the resource plan shows 260, the whole commercial case is suspect.
Exercises — Capstone
Task. Write the technical proposal response to the Halcyon RFP above. Output: the sections in "How a proposal response is structured". Do not paste Lumen content. Assumptions are expected; mark them. Use any rates you like; say which.
- Executive summary (write last, one page)
- You understand the business and current state
- The proposal covers current and future needs
- It can land on time and on budget
- Solution approach
- FRs / NFRs you actually designed to
- High-level architecture with interactions (who calls whom, protocol, failure)
- Component descriptions tied to requirements
- Integrations
- Stack and storage justified against "maintainable by Council staff"
- Deployment
- Dependencies, risks, assumptions
- ASR traceability
- Every high-priority scenario maps to a tactic and a component
- Delivery
- Discovery, design, build, transition
- WBS, estimate, resource plan, timeline
- Estimate reconciles with the plan
- Commercial
- Cost
- Assumptions
- What is out of scope