What Is a Systems Analyst? Designing How Systems Talk to Each Other

A systems analyst maps and designs how the parts of a system fit together: the services, the data, the integrations, and the messages that flow between them. It is the whole-system view that the other analyst hats navigate by.

A systems analyst is the person who holds the map of how everything connects. While a business analyst focuses on the business problem and a functional analyst on the behavior of one feature, the systems analyst takes the widest view: how the services fit together, where the data flows, how the integrations behave, and what breaks when the third hop times out. The job is to make sure the pieces work as a whole, not just individually, because a system is not its components; it is what happens to a transaction as it crosses all of them.

I have done systems analysis on payment platforms where a single transaction touches an ingestion service, a validation service, a processor, an interbank network, a settlement system, and a status channel, some hops synchronous and some event-driven. Nobody understands a flow like that by reading one service’s spec. You understand it by mapping the whole path and following a transaction across it, which is the same discipline behind You Don’t Understand the System Until You Test It. The systems analyst is the one who owns that map and keeps it honest.

What does a systems analyst actually do?

A systems analyst defines and maintains the structure of how systems interact, then traces real flows across that structure to confirm it holds.

Day to day that means producing and updating the diagrams that show the system’s shape: the system context diagram at the boundary, the data-flow diagrams inside it, the sequence of messages across services. It means defining integration points: which service calls which, over what protocol, with what message format, and what happens on failure. It means specifying the message formats and APIs that services use to talk. And it means tracing a transaction end to end to find the failure points, the timeouts, the ordering issues, the places where two services disagree about who owns a decision.

In payments, that is mapping how a payment moves from a pain.001 at initiation, through ingestion and validation, into a pacs.008 sent across the interbank network, through settlement, and back as a status report, while keeping track of which hops are synchronous API calls and which are asynchronous events. The systems analyst is the person who can draw that whole picture from memory and tell you exactly where it is fragile. Reading and specifying the APIs and message contracts that connect those services is core to the role, which is why I wrote API Documentation from Scratch.

What is the difference between a systems analyst and a business analyst?

The business analyst owns the business problem. The systems analyst owns the technical structure that solves it. One asks what the business needs; the other asks how the systems must fit together to deliver it.

A business analyst writes “customers in the new region need to receive real-time payments.” A systems analyst takes that and works out which existing services can be reused, which new integration is required, how the new regional scheme’s message format maps to the internal model, where the flow becomes asynchronous, and what the failure and reconciliation paths are. The business requirement is satisfiable many ways; the systems analyst designs the specific structure that makes it real and robust.

This is why the systems analyst hat sits alongside the Business Analyst and Functional Analyst hats in one discipline. The business analyst defines the why, the functional analyst the behavior of each part, and the systems analyst the structure that connects the parts. When the same person can move across all three, intent flows cleanly into a coherent design, which is the strength of the technical business analyst profile. The structural-view skills, from reading architecture to specifying integrations, are part of The Technical Skills Guide for BAs.

What is a system context diagram, and why start there?

A system context diagram shows your system as a single box surrounded by the external actors and systems it talks to, with the data flowing between them. It is the highest-level view, and it is where systems analysis should start, because you cannot design the inside until you have agreed the boundary.

For a payment engine, the context diagram shows the originating channel that submits payments, the payment system itself as one box, the interbank network it sends to, the settlement system, and any sanctions or fraud service it consults, with the data on each arrow: a pain.001 coming in, a pacs.008 going out to the network, a pacs.002 coming back as status. In one picture, anyone can see what the system touches and what crosses each boundary. That clarity prevents the most expensive class of mistake, the integration nobody scoped because it was never drawn.

From the context diagram you zoom in: data-flow diagrams for the internals, then sequence diagrams for specific transactions. Each level adds detail without losing the whole. The discipline of starting at the boundary and zooming in, rather than diving straight into one service, is what keeps a systems analyst from missing the connections that matter. The templates for these diagrams and the rest of a systems analyst’s deliverables are in Real-World BA Deliverables.

How do integration patterns shape a system?

Integration patterns determine how services talk, and that choice shapes latency, failure modes, and the customer experience more than almost any other design decision. A systems analyst has to recognize which pattern is in play and what it implies.

The two big families are synchronous and asynchronous. A synchronous integration is a request and an immediate response: the caller waits. It is simple to reason about, but it couples the two services, so if the callee is slow or down, the caller is stuck. An asynchronous integration, usually over a message queue like Kafka, decouples them: the caller publishes an event and moves on, and the consumer processes it when it can. This gives resilience and near real-time throughput, at the cost of harder problems: ordering, duplicates, retries, and eventual consistency.

In a real payment flow you see both. Ingestion might accept a payment synchronously and return a 202 received, then publish an event that the processor consumes asynchronously. That mix is exactly why a payment can show “received” instantly but take a beat to become “accepted,” and the systems analyst is the one who understands and documents that, including what the customer sees during the gap. Validating those asynchronous event hops directly, rather than assuming they work, is a skill in itself, and I cover it in Automate Kafka Validation with Postman.

What is the difference between batch and event-driven processing?

Batch processing handles transactions together on a schedule; event-driven processing handles each one as it arrives. The choice between them defines a system’s timing and its failure behavior, so a systems analyst must know which applies where.

Batch collects transactions and processes them in bulk at set times, end of day for example. It is simple, efficient for high volume, and easy to reason about, but it introduces delay: a payment submitted at 9am may not move until the evening run. Many legacy banking systems are batch at their core, which is why some payments still feel slow. Event-driven processes each transaction the moment it arrives, typically through a queue, giving near real-time behavior. The trade is complexity: you now have to handle ordering, idempotency for duplicates, retries for failures, and consistency across services that update independently.

Modern payments are a migration story from the first toward the second, and a systems analyst working in banking spends real time at that seam, where a batch-oriented core meets event-driven rails. Mapping how a transaction crosses that boundary, and where it can get stuck, is some of the most valuable systems analysis you can do. The domain knowledge that makes this possible, including the ISO 20022 message flows that run across these patterns, is exactly what Break Into Banking is built to teach.

How technical does a systems analyst need to be?

Technical enough to read the architecture honestly: the API contracts, the message formats, the config, and ideally the code and the running system. Diagrams drawn before the build lie within months, so the systems analyst who can only read diagrams is reading fiction.

The strongest systems analysts verify their map against reality. They read the API spec to confirm an integration’s real contract. They trace a transaction through the logs to see which services it truly touches, sometimes discovering an integration the architecture diagram never mentioned. They subscribe to a topic to confirm an event flow exists. This is where the systems analyst hat overlaps the Developer Analyst and QA Analyst hats: reading code tells you the real structure, and testing a flow confirms it. A systems map grounded in observation is worth ten drawn from assumption.

That is the throughline of the whole Analyst Engineering model: one discipline, five hats, and the systems analyst is the hat that holds the map the others navigate by. You do not have to wear all five at once, but systems analysis gets far stronger when you can read the code like a developer analyst and test the flow like a QA analyst, instead of trusting a diagram that nobody has updated since the design review.

The takeaway

A systems analyst maps and designs how the parts of a system fit together: the services, the data, the integrations, and the messages between them. The role owns the whole-system view, starts at the boundary with a context diagram, understands synchronous versus asynchronous and batch versus event-driven, and keeps the map honest by checking it against the running system.

Get good at this and you become the person who can explain how anything connects, and where it is fragile, which is indispensable on any complex platform. Start with API Documentation from Scratch and Break Into Banking, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Systems Analysis, Architecture, Banking, Payments, Integration