Systems Analyst
A systems analyst sees how the pieces connect, mapping end-to-end flows and documenting the integrations between services. This pillar covers that work in practice: drawing system context and sequence diagrams, choosing between synchronous and asynchronous integration, designing reconciliation between systems, and understanding ISO 20022 architecture and payment message flows end to end. Written for analysts who own the big picture, with patterns from real integration delivery.
What non-functional requirements are, the categories that matter, and how to write NFRs that are testable: measurable targets instead of adjectives. With examples.
What slowly changing dimensions are, how SCD Type 1 and Type 2 differ, how a Type 2 table works with valid_from and valid_to, and how to query it correctly.
The ISO 20022 payment transaction statuses explained: RCVD, ACTC, ACCP, ACSP, ACSC, PDNG, RJCT, and more, with the lifecycle order and what each guarantees.
CBPR+ ends fully unstructured addresses in November 2026. What structured and hybrid addresses are, the elements that matter, and how to migrate without rejections.
Which ISO 20022 message replaces each SWIFT MT: MT103 to pacs.008, MT202 to pacs.009, MT940 to camt.053, and the traps in the mapping. A reference table.
When money must come back, ISO 20022 gives three distinct mechanisms: returns, reversals, and recalls. Who initiates each, which message carries it, and how to model them.
Airflow schedules tasks; Dagster declares the data assets those tasks produce. What the task vs asset split means for lineage, testing, and debugging pipelines.
Data engineers build the pipelines and platforms that move data; analytics engineers model it in the warehouse so it means something. The split, explained.
Data lineage maps how each field flows from source through transformations to the report that shows it, enabling impact analysis, trust, and audit. With a diagram.
A data mesh decentralizes data: domains own and publish their data as products, on a self-serve platform, under federated governance. Explained with a diagram.
A dbt DAG is the dependency graph of your transformations, built from ref() calls. How to read one, the staging to marts convention, and why tests live on nodes.
dbt and SQLMesh both turn SQL into tested, versioned transformation pipelines. Where they differ: SQL parsing, environments, incremental state, and lineage.
Both write code against the same systems. The backend developer owns the production system; the developer analyst uses code to verify and automate analysis.
Fivetran and Airbyte both move source data into your warehouse. They differ on openness, hosting, pricing, and who fixes the connector when the API changes.
Kimball builds dimensional marts first and integrates through conformed dimensions; Inmon builds a normalized enterprise warehouse first. The classic debate, mapped.
A warehouse is a managed analytical database; a lakehouse adds warehouse guarantees to open files on object storage. The real differences, with a diagram.
Looker is a code-defined semantic layer that governs metrics; Tableau is the strongest visual exploration tool. What each optimizes for and when each fits.
The medallion architecture organizes a lakehouse into bronze (raw), silver (cleaned), and gold (business-ready) layers. What each layer owns, with a diagram.
Medallion and Data Vault answer different questions: medallion says how many quality layers, Data Vault says how to model history inside them. With diagrams.
Snowflake and BigQuery are both elastic cloud warehouses. They differ on compute models, pricing units, cloud lock-in, and the knobs your team must operate.
Star and snowflake schemas differ in one thing: whether dimensions are denormalized. What each looks like, when each fits, and how to read one. With diagrams.
A systems analyst maps how systems connect and behave; a solutions architect decides how they should, and answers for it. The line, the overlap, and the jump.
A self-assessment matrix of 25 skills across the five technical analyst hats, with three levels per skill and where to build each one. Original to this site.
Both are technical; the deliverables differ. A technical BA ships verified understanding and specs; an engineer ships production code. Which seat fits you.
Batch and event-driven processing differ in timing, and that difference shapes latency, failure modes, and customer experience. When to use each, with banking examples.
What contract testing is, how it differs from integration testing, and how consumer-driven contracts catch breaking API and event changes before they reach production.
What a dead-letter queue is, why event-driven systems need one, and how an analyst specifies DLQ behavior: retries, routing, monitoring, and recovery. With examples.
How to write requirements for event-driven systems: event schemas, ordering, idempotency, retries, and consistency. A practitioner guide with a Kafka example.
How to run a fit-gap analysis: compare requirements against system capability, classify each as fit, gap, or partial, and turn gaps into decisions. With a payments example.
A walkthrough of how a technical business analyst actually investigates a failed payment: the questions, the tools, and following one transaction from the complaint to the cause.
How to test idempotency in APIs and event consumers: idempotency keys, duplicate requests, redelivered events, and the race conditions that cause double processing.
The integration patterns that wire systems together: request-response, messaging, publish-subscribe, request-reply, batch file transfer, and webhooks. With payments examples.
What ISO 20022 actually is as an architecture: the business model, message definitions, structured data, and usage guidelines that shape modern payment systems.
A practitioner guide to testing Kafka: consuming events in a test, asserting schema and key, verifying ordering, duplicates, and the consumer side effects that matter.
A field-by-field guide to writing pacs.008 test cases: mandatory fields, structured data, validation, reason codes, and the pacs.002 responses that prove each case.
How payment messages flow end to end in ISO 20022: pain.001 initiation, pacs.008 interbank, pacs.002 and pain.002 status, and camt reporting. A systems analyst map.
A practitioner guide to payment testing: following one transaction through ingestion, events, settlement, and status, plus the rejection and stuck-payment cases that matter.
The production support skills that make a technical analyst invaluable: triage, tracing transactions, reading logs, calm under pressure, and turning incidents into requirements.
Field notes from a major payments incident: how reading logs under pressure works, what the trail revealed, and the lessons about observability that became requirements.
How an analyst reads production logs to understand and debug a system: correlation ids, log levels, searching by transaction, and following one request across services.
How to design reconciliation between systems: matching keys, break detection, tolerance, timing, and exception handling. The control that proves the money is right.
How to do regression testing in payment systems: what to retest, building a regression suite, risk-based selection, and automating the checks that protect live behavior.
How an analyst uses Python to automate repetitive checks: calling APIs, comparing files, querying data, and chaining requests. Small scripts, large leverage.
How business analysts use sequence diagrams to map a flow across services, expose integration gaps, and write better requirements. With a payments example.
How to model a payment as a state machine: define the states, the allowed transitions, the triggers, and the illegal moves. The tool that makes status behavior precise.
Synchronous and asynchronous communication differ in whether the caller waits, and that choice shapes coupling, latency, resilience, and the customer experience.
What a system context diagram is, how to draw one, and why starting at the boundary stops you scoping the wrong thing. With a payments example and the C4 model.
A developer analyst reads and writes enough code to verify, automate, and prototype, without becoming a full-time engineer. Here is what the role does in payments.
A systems analyst maps how services, messages, and data flow across a system so the pieces work as a whole. Here is what the role does in banking and payments.
A technical business analyst analyzes, codes, tests, and supports. Here is what the role actually does day to day in banking and payments, and how to become one.
PAIN vs pacs explained: why pain.001 is not pacs.008, how pain.002 and pacs.002 mirror it, where camt fits, and how ISO 20022 splits customer and bank.
Why testing a payment flow end to end teaches you the system and the UX better than any diagram: microservices, Kafka, the database, logs, and pain.002.
Newsletter
Practical, no-fluff playbooks for technical analysts who analyze, code, test, and support. New articles straight to your inbox.
No spam. Unsubscribe anytime.