Start / 01
Write the problem before naming roles
Print this page or copy its fields into your working document. Use short, direct answers. Add only the roles needed for the stated work.
- Business outcome: ______________________________________________
- Current problem: _________________________________________________
- Scope that is excluded: __________________________________________
- Adobe Commerce estate: edition, version, deployment, storefront, markets, hosting, and code owner.
- Buyer decision owner: ____________________________________________
- Target decision date: _____________________________________________
This map does not say that a project needs eleven separate people. One named person may cover more than one role when the proposal shows enough time, clear ownership, and safe handoffs.
Workstreams / 02
Map each piece of work to an accountable role
Use the suggested role only as a starting point. The proposal must name who owns the decision, the output, and the handoff.
| Workstream | Plain-English question | Likely accountable role | Required output | Buyer owner |
|---|---|---|---|---|
| Business workflow | Which user, rule, approval, or order path must change? | Business analyst | Agreed workflow, rules, scope, and acceptance detail | ____________ |
| Architecture and platform | Which systems own each decision and record? | Solution architect | System boundary, decisions, constraints, and tradeoffs | ____________ |
| Commerce backend | Which catalog, account, price, checkout, order, or admin behavior changes? | Adobe Commerce backend engineer | Assigned backend design, code, API, and defect ownership | ____________ |
| Storefront and performance | What must a customer see, do, and experience? | Storefront engineer | Assigned storefront behavior, accessibility, and performance evidence | ____________ |
| Integration | What crosses the Adobe Commerce boundary, when, and in which direction? | Integration engineer | Interface contract, mapping, retry, monitoring, and failure path | ____________ |
| Data migration | Which records move, how are they cleaned, and how is completeness checked? | Data migration lead | Data scope, map, rehearsal, reconciliation, and cutover record | ____________ |
| Quality and release | What proves the change is ready and safe to release? | QA engineer; DevOps and release engineer | Test evidence, release record, rollback path, and authority | ____________ |
| Security and privacy | Which data, access, review, or exception needs an owner? | Security and privacy owner | Requirements, findings, decisions, exceptions, and handoff | ____________ |
| Delivery and continuity | Who joins the work, tracks decisions, handles incidents, and receives the service? | Delivery lead; operations and support owner | Plan, risk record, escalation, runbooks, support, and exit pack | ____________ |
Role set / 03
Eleven role labels for a named-team proposal
A label is useful only when it carries an assigned decision and output.
Business analyst
Owns workflow discovery, business rules, requirements, and acceptance detail.
Solution architect
Owns system boundaries, architecture decisions, constraints, and technical tradeoffs.
Adobe Commerce backend engineer
Owns assigned server-side commerce behavior, custom modules, APIs, and backend defects.
Storefront engineer
Owns assigned customer-facing storefront behavior, accessibility, and frontend performance.
Integration engineer
Owns contracts, mappings, retries, monitoring, and failure handling between systems.
Data migration lead
Owns data scope, mapping, cleansing, rehearsal, reconciliation, and cutover checks.
QA engineer
Owns the test plan, traceability, regression evidence, defect rules, and release test record.
DevOps and release engineer
Owns environments, deployment automation, release evidence, rollback, and access controls.
Security and privacy owner
Owns security and privacy requirements, reviews, findings, exceptions, and evidence handoff.
Delivery lead
Owns the plan, dependencies, decisions, risks, change control, escalation, and reporting.
Operations and support owner
Owns monitoring, incidents, runbooks, service handoff, continuity, and exit readiness.
Assignment / 04
Ask for names, time, authority, and backup
Complete one row for every required role. “Team available” is not enough detail for this sheet.
| Role | Proposed person | Decision or output owned | Allocation and overlap | Backup and handoff |
|---|---|---|---|---|
| Business analyst | ____________ | ____________ | ____________ | ____________ |
| Solution architect | ____________ | ____________ | ____________ | ____________ |
| Backend engineer | ____________ | ____________ | ____________ | ____________ |
| Storefront engineer | ____________ | ____________ | ____________ | ____________ |
| Integration engineer | ____________ | ____________ | ____________ | ____________ |
| Data migration lead | ____________ | ____________ | ____________ | ____________ |
| QA engineer | ____________ | ____________ | ____________ | ____________ |
| DevOps and release engineer | ____________ | ____________ | ____________ | ____________ |
| Security and privacy owner | ____________ | ____________ | ____________ | ____________ |
| Delivery lead | ____________ | ____________ | ____________ | ____________ |
| Operations and support owner | ____________ | ____________ | ____________ | ____________ |
Handoffs / 05
Map the joins where work can fail
Record each important handoff in plain language. Add more rows in your working copy.
| From | To | What crosses the handoff? | Proof of completion | Failure owner |
|---|---|---|---|---|
| Business analyst | Solution architect | Workflow, rules, scope, constraints | Approved requirements and open decisions | ____________ |
| Solution architect | Engineering roles | Boundaries, interfaces, technical decisions | Decision record and assigned build scope | ____________ |
| Integration engineer | Backend and data roles | Contracts, fields, timing, errors | Mapped interface and tested failure path | ____________ |
| Engineering roles | QA engineer | Build, test notes, known limits | Traceable test result and defect record | ____________ |
| QA engineer | Release engineer | Release candidate and evidence | Go or no-go record with rollback conditions | ____________ |
| Delivery team | Operations owner | Monitoring, runbooks, access, known risks | Accepted handover and escalation path | ____________ |
Finish / 06
Check the map before comparing a case
- □ Every required workstream has one accountable role.
- □ Every role owns a clear decision, output, or control.
- □ Shared roles show enough allocation for all assigned work.
- □ Buyer and provider responsibilities are separate.
- □ System boundaries and important handoffs have owners.
- □ Gaps are marked “proposal evidence required,” not guessed from public claims.
Next, use the case-to-workstream evidence checklist to test whether a public case matches these workstreams. Carry the confirmed roles and unresolved checks into the expert-team SOW worksheet.
Method reference: LATTICE-11 Expert Team Fit Method. Last updated .