Design how business systems fit together: map the landscape, draw data flows, choose build or buy, specify integrations and data migrations, and deliver with UAT and change management.

Solution Design & Integration

## Why it matters

No new system arrives in an empty room. A new CRM must receive customers from the web shop, send orders to the ERP, and feed the finance reports, while the old systems keep running. Most of the risk in a project sits in those connections. A systems analyst who can draw the whole landscape on one page spots missing interfaces, duplicate data and hidden dependencies before they become late surprises.

## The core idea: systems of record

A typical organisation runs a handful of major systems, each the **system of record** (the authoritative source) for certain data:

| System | What it does | Usually the system of record for |
|---|---|---|
| **ERP** (Enterprise Resource Planning: SAP, Oracle, Microsoft Dynamics 365, NetSuite) | Finance, purchasing, inventory, manufacturing, order fulfilment | Products, prices, stock, invoices, the general ledger |
| **CRM** (Customer Relationship Management: Salesforce, Dynamics 365 Sales, HubSpot) | Sales pipeline, marketing, customer service | Customers, contacts, leads, cases |
| **HRIS** (HR Information System: Workday, BambooHR) | People, payroll, absence | Employees, org structure |
| **E-commerce platform** | Online catalogue, basket, checkout | Web sessions, carts (orders pass to ERP) |
| **Data warehouse / lakehouse** | Reporting and analytics | Nothing; it is a copy for analysis |
| **Identity provider** (Microsoft Entra ID, Okta) | Sign-in and access for staff | User accounts and groups |

The rule that keeps a landscape sane: **each data entity has exactly one system of record.** Other systems may hold copies, but changes flow from the master. When two systems both think they own the customer's address, you get conflicts that no integration can fix.

## Integration styles

How systems exchange data, from oldest to newest:

- **File transfer:** nightly CSV files over SFTP. Simple and still common; data is up to a day old.
- **Shared database:** two apps reading the same tables. Fast to build, painful to change; avoid for new work.
- **Point-to-point APIs:** system A calls system B's API directly. Fine for a few connections, but with many systems the lines multiply into a "spaghetti" diagram.
- **Middleware / iPaaS** (integration platform as a service, such as MuleSoft, Boomi, Azure Logic Apps): a central hub that transforms and routes messages.
- **Event-driven:** systems publish events ("order placed") to a message broker, and any interested system subscribes.

The analyst does not usually pick the technology alone, but should record for every interface: source, target, data, trigger, frequency, direction and owner.

## Worked example: Harbor Outfitters

Harbor Outfitters sells outdoor gear in 12 stores and online. Today it runs:

- An ERP (NetSuite) for stock, purchasing and finance.
- A Shopify web shop.
- A 15-year-old in-house **customer database** (Microsoft Access) used by store staff for loyalty points.
- Point-of-sale (POS) tills in each store.
- Spreadsheets for the marketing email list.

The project: replace the customer database and the spreadsheets with a CRM. The analyst's first landscape map, as an interface list:

```text
ID   Source      Target      Data                   Trigger / frequency
I-01 Web shop    ERP         Orders                 Each order (API)
I-02 POS         ERP         Store sales            Nightly file
I-03 POS         Cust DB     Loyalty points         Each sale (shared DB)
I-04 Web shop    Cust DB     New customers          Manual re-keying, weekly
I-05 Cust DB     Marketing   Email list             Monthly export to spreadsheet
I-06 ERP         Data wh.    Sales, stock           Nightly file
```

Two findings jump out. **I-04 is manual re-keying**: staff type web customers into the old database, so the CRM project must automate it. **I-03 uses a shared database**, which will break when the old database is switched off; the POS vendor must be involved early. The future-state map makes the CRM the system of record for customers and loyalty, with I-03, I-04 and I-05 replaced by APIs.

## Common mistakes

- Mapping only the systems in scope and missing the ones that feed them.
- Ignoring spreadsheets and manual steps; they are interfaces too, and often the riskiest.
- Two systems of record for the same entity.
- Forgetting non-functional details: volumes, timing, error handling and who gets called when an interface fails.

## Quick recap

- Each major system is the system of record for some data; keep exactly one master per entity.
- Interfaces range from nightly files to APIs, middleware and events; record source, target, data, trigger, frequency and owner.
- A landscape map and interface list reveal manual steps and hidden dependencies early.


Map the main systems a business runs, such as ERP and CRM, and the data that flows between them.

Enterprise systems landscape

What is Enterprise Architecture (EA) and why is it important? EA concepts explained in a simple way.

ERP vs CRM: What’s the Difference? (How to Choose)

Pick a process you know well: a library loan, a gym membership sign-up, a school's homework submission, or the Harbor Outfitters web order. Write a one-sentence description of the system boundary.

List every external entity (people, organisations, other systems) that gives data to the system or gets data from it.

Draw the context diagram: one central process, the entities around it, and a labelled arrow for each data flow. Use specific nouns on every arrow.

Draw a level-0 DFD with 3 to 6 numbered processes (verb phrases) and the data stores they need (D1, D2...).

Check every flow on the context diagram appears on the DFD (balancing), and every process has at least one input and one output.

Check for illegal flows: entity to entity, store to store, entity straight to store. Fix any you find by adding a process.

Show the diagrams to someone who knows the process and ask them to find one missing or wrong flow. Correct it.

## Why it matters

Stakeholders agree with long text documents and then discover, months later, that they understood them differently. A diagram that fits on one page is much harder to misread. Context diagrams and data-flow diagrams (DFDs) are the analyst's fastest way to agree on scope ("what is inside our system and what is outside") and on what data moves where.

## The core idea

A **context diagram** (also called a level-0 DFD in some textbooks, or a system context diagram) shows:

- **One process**: the system you are building, drawn as a single circle or rounded box.
- **External entities**: people, organisations or other systems that send data to it or receive data from it, drawn as rectangles.
- **Data flows**: labelled arrows showing what data moves, and in which direction.

It deliberately shows nothing inside the system. Its job is scope: anything not on the diagram is not part of the project.

A **data-flow diagram** opens the box. A level-0 (or level-1, depending on the textbook) DFD splits the system into its main processes and adds:

- **Processes**: numbered verbs ("1.0 Register customer"), each transforming input into output.
- **Data stores**: places data rests, such as a table or file, drawn as an open-ended rectangle labelled D1, D2...
- **Data flows**: labelled with nouns ("customer details", "points balance").

DFDs show data, not control. There are no decisions, loops or timing: that is what activity diagrams and BPMN process maps are for.

## Rules that catch mistakes

- Every process must have at least one input and one output. A process with only inputs is a **black hole**; one with only outputs is a **miracle**.
- Data cannot flow directly between two external entities, or between two data stores, or from an external entity straight into a store. A process must sit in between.
- Flows into and out of a lower-level diagram must **balance** with the level above: if the context diagram shows "order" going in, the DFD must too.
- Label every flow with a specific noun. "Data" or "info" means you have not decided what moves.

## Worked example: Harbor Outfitters loyalty

The CRM project's context diagram, written as text:

```text
External entities: Customer, Store staff (POS), Web shop, ERP, Email service

Customer   --sign-up details-->        [CRM loyalty system]
Customer   <--points statement--       [CRM loyalty system]
POS        --sale (customer id, total)--> [CRM]
POS        <--points balance--          [CRM]
Web shop   --new web customer-->        [CRM]
ERP        <--customer account details-- [CRM]
Email svc  <--marketing list, opt-ins--  [CRM]
```

The level-0 DFD opens it into four processes and two stores:

```text
1.0 Register customer    in:  sign-up details, new web customer
                         out: customer record -> D1 Customers
                              customer account details -> ERP
2.0 Award points         in:  sale (from POS), customer record (D1)
                         out: points transaction -> D2 Points ledger
3.0 Report balance       in:  points transactions (D2)
                         out: points balance -> POS, points statement -> Customer
4.0 Build mailing list   in:  customer record with consent (D1)
                         out: marketing list -> Email service
```

Check it against the rules: every process has inputs and outputs; the POS never writes straight into D2 (process 2.0 does); the flows to and from external entities match the context diagram. Drawing process 4.0 also raised a real requirement: consent must be stored on the customer record, or the mailing list breaks privacy law.

## Tools

Paper and a pencil are fine for a first draft. For sharing, use any diagramming tool: diagrams.net (draw.io, free in the browser), Lucidchart, Miro or Visio. Pick one symbol set (Gane-Sarson or Yourdon-DeMarco) and stick to it.

## Common mistakes

- Drawing control flow (if/then, loops) on a DFD.
- Unlabelled or vaguely labelled arrows.
- External entities connected directly to data stores.
- A context diagram cluttered with internal detail, which defeats its purpose.
- Not walking stakeholders through it; a diagram nobody has reviewed has not been agreed.

## Quick recap

- A context diagram shows one system, its external entities and the data flows between them: it defines scope.
- A DFD breaks the system into numbered processes and data stores; it shows data, not control.
- Check for black holes, miracles, illegal direct flows and unbalanced levels.

## Try it

In the Do tab you draw both diagrams for a process you know.


Draw a context diagram and a level-0 data-flow diagram for a business process.

Context and data-flow diagrams

How to Use a System Context Diagram in Business Analysis (with example)

Data Flow Diagrams - What is DFD? Data Flow Diagram Symbols and More

Pick a decision: the Harbor Outfitters CRM, a note-taking app for your team, a learning platform for a club, or a tool at your workplace. Write a one-paragraph problem statement.

Write 2 or 3 must-have gates (yes/no requirements an option must meet).

Choose 4 to 6 weighted criteria and give them weights that add up to 100%. Write one sentence on why the top-weighted criterion matters most.

Pick at least three options, including one build or do-nothing option. For each, find evidence from official product pages, free trials or documentation (not reviews alone).

Score each option 1 to 5 per criterion and write the evidence for each score in a notes column. Apply the must-have gates first.

Calculate the weighted totals with a formula (for example `=SUMPRODUCT(weights, scores)`).

Sensitivity test: move 5 to 10 points of weight between your top two criteria. Does the winner change? Write down what that tells you.

Write a three-sentence recommendation with one key risk and how you would reduce it.

## Why it matters

"Should we build it ourselves or buy a product?" is one of the most expensive decisions a project makes, and it is often made on gut feeling or on the best sales demo. Analysts bring structure: clear requirements, a fair comparison and a recorded rationale that someone can revisit in two years when the decision is questioned.

## The options are wider than two

- **Buy (SaaS or packaged software):** use the product largely as it comes. Fast to start, the vendor handles upgrades, but you adapt your process to the product.
- **Configure:** buy a platform and set it up with settings, workflows and fields (most CRM and ERP projects).
- **Customise / extend:** add code on top of a product. Powerful, but every customisation can break at upgrade time.
- **Build:** write your own. Full control and fit, but you own every bug, upgrade and security patch forever.
- **Hybrid:** buy the commodity parts and build the parts that differentiate you.

A useful rule of thumb: **buy what is commodity, build what is differentiating.** Payroll, email and accounting work the same way for nearly everyone; buy them. A unique pricing engine that wins you customers may be worth building.

## Total cost of ownership

Compare costs over several years, not just the first invoice:

```text
Buy:    licences/subscriptions x users x years
        + implementation partner + data migration + integrations
        + training + internal admin time
Build:  development team x duration
        + hosting + security and compliance work
        + ongoing maintenance (often 15-25% of build cost per year)
        + the opportunity cost of what that team is not building
```

## The weighted scoring matrix

1. **Agree the criteria before you see demos**, from the requirements: functional fit, integration (APIs available), security and compliance, total cost, vendor viability, usability, time to deliver.
2. **Weight them** so they sum to 100%. Stakeholders agree the weights; this is where priorities become explicit.
3. **Score each option** 1 to 5 against each criterion, using evidence: scripted demos (give vendors your scenarios), reference calls, a trial or proof of concept.
4. **Multiply and sum.** The highest total is the recommendation, unless an option fails a **must-have** gate, which disqualifies it whatever its score.

## Worked example: Harbor Outfitters CRM

Must-have gates: stores customer consent; has a documented REST API; can import 180,000 legacy customers.

| Criterion | Weight | Vendor A (SaaS CRM) | Vendor B (CRM suite) | Build in-house |
|---|---|---|---|---|
| Functional fit (loyalty, segments) | 30% | 4 | 5 | 5 |
| Integration with NetSuite and Shopify | 20% | 5 | 3 | 3 |
| 5-year total cost | 20% | 4 | 2 | 2 |
| Time to go live | 15% | 4 | 3 | 1 |
| Usability for store staff | 15% | 4 | 3 | 4 |

Weighted totals (score x weight, summed):

```text
Vendor A: 4(.30)+5(.20)+4(.20)+4(.15)+4(.15) = 1.2+1.0+0.8+0.6+0.6 = 4.20
Vendor B: 5(.30)+3(.20)+2(.20)+3(.15)+3(.15) = 1.5+0.6+0.4+0.45+0.45 = 3.40
Build:    5(.30)+3(.20)+2(.20)+1(.15)+4(.15) = 1.5+0.6+0.4+0.15+0.6 = 3.25
```

Vendor A wins clearly, even though Vendor B has the best features. The recommendation document records the scores, the evidence behind each, the risks (Vendor A's loyalty module is newer) and the mitigations (a 30-day proof of concept on loyalty before signing).

## Beyond the score

Also check: data ownership and export (can you leave with your data?), where data is hosted, the vendor's security certifications (such as SOC 2 or ISO 27001), contract length and exit terms, and the product roadmap. Sensitivity test the result: if changing one weight by 5 points flips the winner, the decision is close and needs more evidence.

## Common mistakes

- Choosing criteria after the demos, which bends them toward the favourite.
- Letting vendors run their own demo script instead of your scenarios.
- Comparing year-one licence price against a build estimate without maintenance.
- Heavy customisation of a bought product, which gives you the costs of both options.
- No recorded rationale.

## Quick recap

- Options range from buy to configure, customise, build and hybrid; buy commodity, build differentiators.
- Compare total cost of ownership over several years.
- Use must-have gates plus a weighted matrix agreed before demos, scored with evidence.

## Try it

The Do tab asks you to build a weighted matrix for a real decision.


Compare building, buying and configuring a product, and score vendor options with a weighted matrix.

Build vs buy

Buy Software or Build It? The 4-Step Framework That Prevents Costly Mistakes

Map the systems a business runs, draw how data flows between them and decide whether to build or buy.