System Mapping Template

A system map shows how work moves today. It does not need to be a perfect architecture diagram; it needs to show the systems, handoffs, data flows, and ownership boundaries that shape the project.

This is useful before engineering joins because non-engineering team members often know the real workflow better than the architecture diagram does.

Why It Helps

Engineering uses a system map to spot integration risk, duplicate systems, vendor boundaries, manual workarounds, security concerns, data ownership, and places where the proposed product strategy may be fighting the current environment.

A good map makes the hidden architecture visible enough to ask better questions.

Mermaid Example

flowchart TD
    subgraph Users["People and channels"]
        Resident["Resident submits application"]
        Staff["Caseworker reviews case"]
    end
    subgraph Agency["Agency systems"]
        Intake["Online intake form"]
        CaseSystem["Legacy case system"]
        Reports["Reporting spreadsheet"]
    end
    subgraph Shared["Shared services"]
        SSO["State SSO"]
        Email["Notification service"]
    end
    subgraph Vendor["Vendor boundary"]
        Rules["Eligibility rules engine"]
    end
    Resident --> Intake
    Intake -->|creates case| CaseSystem
    Staff -->|reviews in| CaseSystem
    CaseSystem -->|nightly file| Rules
    Rules -->|status update| CaseSystem
    CaseSystem -->|manual export| Reports
    CaseSystem -->|send notice| Email
    Staff -->|signs in through| SSO
    style CaseSystem fill:#dbeafe,stroke:#2563eb,color:#172554
    style Reports fill:#fef3c7,stroke:#b45309,color:#451a03
    style Rules fill:#fce7f3,stroke:#be185d,color:#500724

What to notice: the map separates agency systems, shared services, and the vendor boundary. That makes ownership and integration risk visible before anyone argues about solutions.

Copy This Template

## Current System Map

| System / tool | What it does | Owner | Users | Data in | Data out | Integration method | Known pain |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Legacy case system | Tracks service requests and case status | Program operations | Caseworkers, supervisors | Intake data, status changes | Reports, notices, vendor file | Manual entry, nightly file | Slow search, duplicate records |
| Online intake form | Collects new requests from residents | Digital services team | Residents, call center | Applicant data, documents | New case packet | Form submission export | No status tracking |
| Eligibility rules engine | Calculates program eligibility | Vendor | Vendor support team | Nightly case file | Eligibility decision file | SFTP batch | Limited transparency |

## Open Questions

| Question | Why it matters | Owner | Due date |
| --- | --- | --- | --- |
| Does the legacy system have an API? | Determines whether integration can be real-time or batch. | Agency CIO delegate | 2026-07-15 |
| Who approves changes to notice templates? | Affects delivery timeline and stakeholder review. | Program communications lead | 2026-07-18 |

Bring This to Engineering

Bring the diagram, the table, and the open questions. Engineering can then focus on validating the riskiest boundaries instead of reconstructing the whole system from scratch.