Phase 2 — data and system assessment

What you will learn Four things to confirm before starting, and where you stall if you skip this phase.

If databases themselves are unfamiliar, start with What a database is.

The purpose of this phase

Analyse the existing data and systems and plan the integration.

In one sentence: confirm you can build it before you build it.

The most wasteful failure is this:

Finding out while building means you already spent three weeks. Phase 2 turns those three weeks into three days.

Four activities

1. Map the data sources (API / DB / documents)

Write down where the data you need lives and in what form.

Note the third row. Rules that live "in someone's head" are extremely common, and documenting them is itself an output of this phase.

2. Assess system integration options

Confirm how you can connect to each system.

If it is the last row, reconsider. You can build it, but you cannot maintain it.

3. Evaluate data quality

Being able to access it does not mean you can use it.

There are projects where "one day behind" is fatal. If data for real-time support is a day old, that project does not stand up. This is what you must find now.

4. Document governance and security requirements

Always ask how long approval takes. "About two weeks" and "it goes to the quarterly review board" produce completely different plans.

Output

System architecture & data flow diagram

One picture is enough. Something like this:

graph TD
  A["Accounting mailbox<br/>PDF attachments"] --> B["Read the document"]
  C["ERP supplier master<br/>read-only account"] --> B
  D["Account code rules<br/>documented"] --> B
  B --> E["Produce a draft entry"]
  E --> F{"Over the approval threshold?"}
  F -->|"yes"| G["Human approval"]
  F -->|"no"| H["Auto-enter into ERP"]
  G --> H

The picture must show where human approval sits. That is the start of guardrail design.

Gate — to move on

Have you confirmed you can actually access the data you need?

The standard for "confirmed" is you actually pulled it once. Not "it looks possible."

Common mistakes in this phase

Judging from documentation alone

"It's in the API docs, so it'll work" → in reality the endpoint is disabled, the permissions differ, or the response does not match the docs. Actually calling it once takes 30 minutes.

Deferring security approval

The most common cause of schedule slip. Technical review takes days; approval takes weeks. File the approval request on the day Phase 2 starts. It runs in parallel while you do the other checks.

Eyeballing data quality

Looking at ten records and saying "seems fine" is not enough. Count missing rate, format variants, and duplicates across the whole set. A few lines of query.

Check yourself

1. What is the standard for "confirmed we can access the data"?

2. Why does "overnight batch, one day behind" matter?

3. Why file the security approval on day one of Phase 2?

Before building, check the legal requirements once → Regulation and compliance