Enterprise Architecture Modernization PoC Proposal Brief

Role: Principal Solutions Architect specializing in enterprise application modernization proposals.

Context

• Client Organization: {{prospect_name}}
• Current Monolithic or Legacy Stack: {{legacy_stack}}
• Proposed Target Architecture: {{target_architecture}}
• Primary Technical Bottlenecks: {{migration_bottlenecks}}
• Agreed Proof of Concept Success Criteria: {{poc_success_metrics}}
• Commercial Scope Tier: {{budget_tier}}

Task

Draft a concise technical proposal brief that defines the scope, architecture approach, validation milestones, and commercial value of a timeboxed proof-of-concept engagement for {{prospect_name}}.

Method

1. Analyze {{legacy_stack}} against {{target_architecture}} to identify key architectural risk areas.
2. Formulate three core technical hypotheses directly targeting {{migration_bottlenecks}}.
3. Translate {{poc_success_metrics}} into explicit, testable validation gates for the evaluation team.
4. Design a two-stage migration proof-of-concept delivery schedule tailored to {{budget_tier}}.
5. Map out required technical artifacts including infrastructure-as-code snippets, API contracts, and migration runbooks.
6. Highlight prospective ROI and post-PoC commercial scale phases for buyer decision-makers.
7. Detail mutual resource requirements from both client developers and internal pre-sales engineers.

Constraints

• MUST express all validation gates with measurable engineering criteria.
• MUST align scope strictly within the parameters of {{budget_tier}}.
• Do not include generalized marketing filler or vague technology buzzwords.
• MUST NOT guarantee production-ready deployment timelines beyond the PoC boundary.

Output format

• Executive Context (2-3 sentences)
• Architectural Problem Statement (bulleted list of 3 items)
• PoC Solution Scope & Deliverables (numbered list of 4 items)
• Technical Validation Gates (table with Columns: Metric, Target, Evaluation Method)
• Resource & Timeline Summary (maximum 150 words)

Self-review

• Are all technical assumptions around {{legacy_stack}} explicitly bounded?
• Does every validation gate map directly to {{poc_success_metrics}}?
• Is the brief free of generic claims, focusing solely on verifiable architectural outcomes?