Information Systems Architecture

Summary

Surveys the architectures that hold modern information systems together: three-tier and n-tier, enterprise architecture frameworks (TOGAF, Zachman), integration patterns, SOA, microservices, and the API economy.

Role in the course: Give students an architectural mental model so that every later technical chapter (data, cloud, security, AI) lands in the right architectural slot.

Concepts Covered

This chapter covers the following 23 concepts from the learning graph:

1. Application Portfolio
2. Three-Tier Architecture
3. N-Tier Architecture
4. Presentation Tier
5. Application Tier
6. Data Tier
7. Enterprise Architecture
8. TOGAF Framework
9. Zachman Framework
10. Reference Architecture
11. Solution Architecture
12. Integration Pattern
13. Enterprise Service Bus
14. API Gateway
15. Service-Oriented Architecture
16. Microservices Architecture
17. Monolithic Architecture
18. Event-Driven Architecture
19. REST API
20. GraphQL API
21. Webhooks
22. OpenAPI Specification
23. API Versioning

Prerequisites

This chapter builds on concepts from:

• Chapter 1: Foundations of Information Systems
• Chapter 2: The Role of IS in Organizations

---

Welcome back

Welcome to Chapter 3. In Chapter 1 we defined what information systems are; in Chapter 2 we figured out who runs them and why anyone pays for them. Now we get to the genuinely fun part: the architecture — the structural blueprints that decide whether an organization's IS portfolio behaves like a well-designed city or a pile of houses with the plumbing on the outside. By the end of this chapter you will be able to look at any enterprise system and locate it on a small set of architectural maps. That skill is what separates "person who uses the systems" from "person who can change them."

Why Architecture Is the Conversation Above the Code

A working organization runs dozens — sometimes hundreds — of applications. The CRM. The ERP. The HRIS. The data warehouse. The marketing automation tool. Three different ticketing systems that nobody can quite remember why they have. The collection of those applications is called the application portfolio, and managing it is one of the central jobs of any modern IS organization.

The application portfolio is not just a list. It is a structured inventory: each application has an owner, a business capability it supports, a lifecycle stage (introduce, grow, sustain, retire), an integration footprint, and a cost. A healthy portfolio gets pruned the way a healthy garden does, on a regular cycle. An unhealthy portfolio just keeps growing — every new initiative buys another tool, nothing ever retires, and within five years the integration map looks like a bowl of spaghetti that has been left out overnight.

Architecture is the discipline that keeps the portfolio coherent. Without architectural thinking, every project optimizes for itself, every team picks its favorite stack, and every shortcut that "just makes this one feature ship faster" turns into a permanent constraint on everyone who comes after. Architecture asks the questions that no individual project will ever ask on its own: How does this fit with what we already have? What standards should we follow? What can be reused? What problem are we genuinely creating for the team three doors down?

This chapter walks down the ladder of architectural abstraction, from the top-of-the-skyscraper view (enterprise architecture frameworks) to the floor plan of a single building (three-tier and n-tier) to the plumbing and wiring (integration patterns and APIs). Each level matters; each level uses different vocabulary; and you will be expected to move between them fluently.

The Three-Tier Architecture: The Floor Plan You Already Know

Almost every business application built since about 1995 has the same fundamental shape, called the three-tier architecture. The shape is so universal that you may have used it without ever giving it a name. It separates an application into three logical layers, each with a clearly bounded responsibility.

The presentation tier is the layer the user actually touches. It is the web page in the browser, the mobile app on the phone, the desktop client on the laptop. Its job is to render information and accept input — and that is all its job. A well-built presentation tier contains as little business logic as possible; it is the storefront window, not the warehouse.

The application tier (sometimes called the business logic tier or the middle tier) is where the actual rules of the business live. Is this loan applicant eligible? Does this discount stack with that promotion? Should this support ticket auto-route to the security team? Every consequential decision the system makes happens here. The application tier orchestrates the workflow, validates the inputs, enforces the policies, and decides which pieces of data to fetch or update.

The data tier is where the persistent state lives — the databases, the data warehouses, the document stores, the file systems. Its job is to durably remember things and to answer queries about them. The data tier does not know or care whether the request came from a web browser, a mobile app, or a batch job; it just stores and retrieves data accurately.

Why split an application this way? Because the three layers change at different rates and for different reasons. The presentation tier changes when users want a new screen or a different device. The application tier changes when the business rules change. The data tier changes when the data model evolves — and it changes the slowest, because changing it well is hardest. Splitting these concerns means a UI redesign does not require touching the database, and a rule change does not require redeploying the mobile app.

Before we look at the diagram below, here is the key thing to absorb: the three tiers are logical, not necessarily physical. You can run all three on the same laptop during development and deploy them to three separate clusters in production. The architecture is about separation of responsibilities, not about how many servers you bought.

Diagram: Three-Tier Architecture with Request Flow

Three-Tier Architecture with Request Flow

Type: interactive-infographic sim-id: three-tier-architecture
Library: p5.js
Status: Specified

A vertical three-layer diagram drawn in p5.js, drawn responsively to fill the available iframe width. From top to bottom, the three layers are labeled Presentation Tier, Application Tier, and Data Tier. Each layer is rendered as a rounded rectangle running the full canvas width, with a clear label and a representative icon (browser/phone for presentation, gears for application, cylinder for data).

Color palette (light mode): Presentation = soft sky blue, Application = medium teal, Data = warm gold. Each layer has a 1px darker border and dark text. Layer separators are dashed gray lines.

Interactivity: when the user clicks the Trace a Request button, an animated dot travels from the presentation tier down through the application tier to the data tier (request path), pauses, and then travels back up (response path). At each stop, a small callout shows what that tier does for this request: e.g., presentation = "User clicks 'Apply for Loan'", application = "Validate inputs, run eligibility rules", data = "Fetch credit history, write application record."

A toggle switches between three example requests — view a product page, submit a loan application, generate a monthly report — so the same architecture is shown handling different workloads.

Layout: layers stacked vertically, full width; callout panel appears to the side at desktop widths and below at narrow widths. Canvas resizes on window resize. The setup() function calls updateCanvasSize() as its first step. Canvas parented with canvas.parent(document.querySelector('main'));.

Learning objective (Bloom: Understanding): Students can identify which tier owns a given responsibility (rendering a chart, validating a discount rule, storing a customer record).

Implementation: p5.js, single main.html, accompanying index.md doc, deployed at /sims/three-tier-architecture/.

When Three Tiers Aren't Enough: N-Tier

The three-tier model is a beautiful starting point, but real systems quickly need more layers. The general form is called the n-tier architecture — the same idea, generalized to any number of logical tiers, each with a focused responsibility.

In a typical enterprise application you might find: a presentation tier; a web tier that handles HTTP routing, sessions, and authentication; an application tier for business logic; a services tier that exposes shared capabilities (notification, search, identity); a caching tier (Redis, Memcached) that absorbs read traffic; a data access tier that mediates between the application and the data stores; and finally the data tier itself. That is seven tiers, not three.

The reason organizations add tiers is the same reason cities add zones: specialization scales better than mixing everything together. A dedicated caching tier can be tuned by people who know caching. A dedicated identity tier centralizes a security-critical concern. A dedicated services tier lets the rest of the application share capabilities without each team rebuilding them.

The cost is operational complexity. Every tier is another component to deploy, monitor, secure, and pay for. There is a real tradeoff here — we will return to it shortly when we discuss monoliths versus microservices, because microservices push the n-tier impulse to its logical extreme.

Pause here — this one matters

The single most useful question to ask about any application is: "Which tier is this code running in, and why?" Code that pretends it does not have a tier — like business logic stuffed into a database trigger, or a database query embedded in the HTML template — is code that will fight every future change. Architecture is fundamentally about putting code where it belongs, so that the next person who needs to change it can find it without weeping.

Enterprise Architecture: The View From Orbit

Three-tier and n-tier describe a single application's structure. Step way back and you face a much bigger question: how should all your organization's applications, data stores, integrations, and technology platforms fit together as one coherent whole? That is the domain of enterprise architecture (EA).

Enterprise architecture is the discipline of describing, governing, and evolving the entire IS landscape of an organization in a way that supports the business strategy. EA produces a set of artifacts — current-state diagrams, target-state diagrams, transition roadmaps, standards, principles — that let leadership make portfolio-level decisions instead of project-level ones. We met the Enterprise Architect role in Chapter 2; EA is the body of knowledge that role draws on.

Enterprise architecture is usually decomposed into four interrelated views:

• Business architecture — capabilities, processes, organizational units, value streams.
• Data architecture — the major data domains, their owners, and how they flow.
• Application architecture — the application portfolio and how systems integrate.
• Technology architecture — the platforms, networks, and infrastructure underneath.

Two frameworks dominate the EA conversation: TOGAF and Zachman. They are not competitors so much as complements — Zachman gives you the vocabulary to describe what exists, while TOGAF gives you the process to evolve it.

The TOGAF Framework: A Process for Architectural Change

The TOGAF Framework (The Open Group Architecture Framework) is the most widely adopted enterprise architecture framework in the world. It is published and maintained by The Open Group and is currently in version 10. The bulk of TOGAF is a step-by-step process called the Architecture Development Method (ADM) — eight phases plus a preliminary phase, arranged as a cycle:

1. Preliminary — establish the architecture capability itself.
2. Architecture Vision — define scope, stakeholders, and high-level goals.
3. Business Architecture — describe the business in capability and process terms.
4. Information Systems Architectures — data and application architecture.
5. Technology Architecture — platforms and infrastructure.
6. Opportunities and Solutions — identify projects and roadmap.
7. Migration Planning — sequence the projects.
8. Implementation Governance — make sure the actual build matches the architecture.
9. Architecture Change Management — handle changes after deployment.

TOGAF is methodical, comprehensive, and — done badly — soul-crushingly heavyweight. The classical TOGAF failure mode is to treat the ADM as a literal waterfall, produce 400 pages of diagrams, and ship nothing. Done well, TOGAF is tailored ruthlessly to the organization's actual decision-making cadence — using only the artifacts that real stakeholders will actually read.

The Zachman Framework: A Schema for Architectural Description

The Zachman Framework, created by John Zachman at IBM in 1987, takes a different angle. Zachman is not a process; it is a taxonomy — a 6-by-6 grid that classifies architectural artifacts by what they describe and whose viewpoint they describe it from.

The columns are six interrogatives: What (data), How (function), Where (network), Who (people), When (time), and Why (motivation). The rows are six perspectives: Executive (scope), Business Management (concept), Architect (logic), Engineer (physics), Technician (component), and Enterprise (operations).

Each cell of the resulting grid represents a specific kind of architectural artifact. The "What/Architect" cell is the logical data model. The "How/Engineer" cell is the application design. The "Where/Technician" cell is the network deployment diagram. Zachman's genius is that the grid forces completeness: if a cell is empty, your architecture has a documented blind spot.

Framework	Type	Strength	When to use it
TOGAF	Process	Step-by-step method to evolve the architecture	When you need a roadmap from current to target
Zachman	Taxonomy	Comprehensive schema to classify what already exists	When you need a complete inventory of artifacts

Working enterprise architects often use both — Zachman to organize what is, TOGAF to plan what comes next.

Reference Architecture vs. Solution Architecture

Enterprise architecture produces two flavors of architectural document, and confusing them is one of the great recurring mix-ups in our field.

A reference architecture is a generalized, vendor-neutral, organization-tailored blueprint that describes how a class of system should be built. "Our reference architecture for customer-facing web applications uses an API gateway, stateless application services, a relational database for transactional data, and a separate analytics store." A reference architecture is the recipe — abstract, reusable, and specifically not about any one project.

A solution architecture is the specific design for a specific project. "The new loyalty portal will use the customer-facing reference architecture, with Kong as the API gateway, three Spring Boot services running on EKS, PostgreSQL on RDS, and Snowflake for analytics, integrated with the existing identity provider via OIDC." A solution architecture is what gets built; the reference architecture is what it conforms to.

The two work as a system. Reference architectures provide consistency across the portfolio (every project in this category looks roughly like this). Solution architectures provide adaptation to each project's specific constraints. Skip the reference architecture and every project reinvents the wheel; skip the solution architecture and you cannot actually build anything.

Pro move

When you join a new IS team, ask whether the organization has any published reference architectures for its common application categories. The answer tells you a lot. A team with three good reference architectures is a team that has thought about reuse on purpose. A team with none is a team where every project is a snowflake — and where your first valuable contribution might be quietly drafting one.

Integration Patterns: How Systems Talk to Each Other

So far we have talked about how a single application is structured. The harder question — and the one that consumes most of an enterprise architect's working life — is how multiple applications talk to each other. The CRM has to know what the ERP knows. The data warehouse has to pull from both. The identity provider has to authenticate users for all of them. Integration is the connective tissue that makes the application portfolio behave like a system instead of an archipelago.

An integration pattern is a reusable, named solution to a recurring integration problem. The catalog of integration patterns is large (Gregor Hohpe and Bobby Woolf's classic book identifies 65 of them), but the ones you will meet most often fall into a small handful of categories:

• File transfer — application A drops a file in a known location, application B picks it up. Old, simple, still very common in finance and healthcare.
• Shared database — two applications read and write the same database. Tempting, brittle, almost always a mistake at scale.
• Remote procedure call (RPC) — application A calls a function exposed by application B over the network, including REST and GraphQL APIs we will meet shortly.
• Messaging — application A puts a message on a queue or topic, application B consumes it asynchronously. Decouples sender from receiver in time.
• Event streaming — applications publish a continuous stream of events that any number of consumers can process independently. The modern darling, often built on Kafka.
• Webhooks — application A pushes an HTTP request to a URL that application B has registered. The web's lightweight version of "call me when something happens."

Each pattern makes different tradeoffs on coupling, latency, reliability, and complexity. There is no universally best pattern; there is only the right pattern for the specific integration problem you have.

Pattern	Coupling style	Typical latency	Strengths	Typical pitfalls
File transfer	Loose, batch	Hours	Simple, debuggable	Stale data, brittle file formats
Shared database	Very tight	Real-time	Fast, no integration code	Both apps locked to one schema
RPC (REST/GraphQL)	Tight, synchronous	Milliseconds	Easy to reason about, request-response	Calling app blocked when callee is down
Messaging	Loose, asynchronous	Sub-second	Decoupling, durability, retry	Operational complexity, message ordering
Event streaming	Very loose	Sub-second	Fan-out, replay, scale	Schema evolution, consumer-side complexity
Webhooks	Loose, push	Sub-second	Simple to set up, no polling needed	Delivery guarantees, endpoint security

The architecture choice that ties many of these patterns together — and that gave the 2000s their characteristic flavor of integration — is the Enterprise Service Bus.

The Enterprise Service Bus

In the early-to-mid 2000s, organizations needed a way to wire dozens of legacy applications together without writing a custom integration between every possible pair. (With n applications, that is n(n-1)/2 point-to-point integrations — for fifteen apps, 105 connections — and it does not end well.) The dominant answer was the enterprise service bus (ESB) — a central piece of middleware that all applications connect to, which routes, transforms, and orchestrates messages among them.

An ESB typically offered: protocol bridging (SOAP to JMS to FTP), message transformation (XML to flat file to JSON), content-based routing, orchestration of multi-step flows, and centralized monitoring. Vendors like IBM, Oracle, TIBCO, MuleSoft, and webMethods built large businesses on ESB products.

The ESB era taught the industry several durable lessons. First, centralizing integration in one piece of middleware trades many small problems for one large one — the ESB itself becomes a critical bottleneck and a knowledge silo. Second, putting business logic into the ESB (a common temptation) creates a parallel universe of code that nobody outside the integration team can find or change. Third, vendor lock-in around an ESB is unusually painful to escape.

Modern enterprise integration tends to favor lighter-weight, more decentralized patterns — API gateways at the edge, event streaming in the middle, point-to-point APIs for service-to-service calls — but ESBs remain widely deployed in established organizations, and you will absolutely see them in the wild.

Heads up

The ESB era hides a classic footgun: it is silently easy for the integration team to absorb business logic that does not belong to it. A finance team requests "just a small data transformation" inside the ESB; six years later the rules for revenue recognition partially live there, nobody outside the integration group remembers, and replacing the ESB becomes a years-long project. The structural fix is a hard rule: the ESB transforms and routes; the ESB does not decide. Decisions live in business systems, where their owners can find them.

The API Gateway: The Front Door to Your Services

If the ESB is the great hub of the 2000s, the API gateway is its more focused successor. An API gateway is a piece of infrastructure that sits between external clients and an organization's backend services, enforcing a consistent set of cross-cutting concerns: authentication, rate limiting, request routing, response caching, logging, and protocol translation.

Where the ESB tried to do everything for everyone, the API gateway does a small set of things very well, and pushes business logic firmly back into the services it fronts. A typical request flows like this: client sends an HTTP request to api.example.com/orders/42; the gateway authenticates the caller, checks the rate limit, decides which internal service handles /orders, forwards the request, applies any response transformations, and returns the result. Every backend service does not have to reimplement authentication or rate limiting; the gateway handles it once.

API gateways are the standard pattern for any organization that exposes APIs to mobile apps, partner systems, or third-party developers. They are also a key enabler of microservices — without something like a gateway, every microservice would have to handle cross-cutting concerns on its own, and that way lies madness.

Diagram: API Gateway Request Flow

API Gateway Request Flow

Type: interactive-infographic sim-id: api-gateway-flow
Library: vis-network
Status: Specified

A vis-network diagram showing a left-to-right flow: a Client node (mobile phone or browser icon) on the left, an API Gateway node in the middle, and three backend service nodes on the right (Orders Service, Inventory Service, Customer Service). Each backend service has its own database node attached below it. Edges connect client to gateway and gateway to each backend. All edges use a slight y-offset (e.g., 480 → 490) to avoid the vis-network horizontal-edge label rendering bug.

Color palette: Client = sky blue, API Gateway = teal, Orders = lime green, Inventory = gold, Customer = warm coral. Databases are slate gray cylinders.

Interactivity: clicking the Send Request button animates a request token from the client to the gateway, where a side panel highlights the cross-cutting concerns the gateway applies in sequence (authenticate → rate limit → route → log). The token then continues to the appropriate backend service (chosen via a dropdown — orders, inventory, or customer). The response animates back along the same path, and the panel updates to show response-side concerns (caching, transformation, logging).

A toggle reveals what the diagram looks like without a gateway — every backend service exposed directly, each one having to reimplement authentication, rate limiting, and logging. The clutter is the point.

Layout: horizontal flow, full canvas width, height ~480px. Canvas resizes on window resize.

Learning objective (Bloom: Analyzing): Students can articulate which cross-cutting concerns belong in the gateway and which belong in the backend service.

Implementation: vis-network, deployed at /sims/api-gateway-flow/.

Service-Oriented Architecture (SOA)

The architectural style that the ESB and API gateway grew up serving is called service-oriented architecture (SOA) — an approach to building enterprise systems in which business capabilities are exposed as reusable, network-accessible services, each with a published contract, that can be composed into larger applications.

The core SOA principles, distilled to a postcard: services are autonomous, share contracts not implementations, can be discovered, and are reused across multiple consumers. A "Customer Service" exposed by SOA is not a screen in one application; it is a contract that any application — order entry, billing, marketing, analytics — can call to read or update customer information. Build the service once; reuse it ten times.

Classical SOA, peaking around 2005-2010, was usually implemented with SOAP web services, WS-* security and transaction standards, an enterprise service bus, and a centralized service registry. The approach delivered real value when done well, and produced spectacular failures when the governance overhead exceeded the reuse benefit. Many organizations still operate large SOA estates today.

The contemporary descendant of SOA — leaner, more decentralized, more aligned with cloud-native deployment — is microservices.

Monolithic vs. Microservices Architecture

The biggest architectural debate of the past fifteen years is between monolithic architecture and microservices architecture. Both styles can produce excellent systems; both can produce disasters. The question is which tradeoffs fit your team and your problem.

A monolithic architecture packages an application as a single deployable unit. One codebase, one build, one deployment, one process (or one cluster of identical processes). The classic Rails or Django or Spring application is a monolith. So is the original Stack Overflow. So is, mostly, the system at your local credit union.

A microservices architecture decomposes the same application into a collection of small, independently deployable services that communicate over the network — typically via APIs or messaging. Each service owns its own data store, has its own deployment pipeline, and can be developed by a small team that ships independently of the others.

The case for microservices is real: independent deployment lets large organizations parallelize work; small services are easier to understand in isolation; technology choices can vary by service; failures can be contained to one service rather than crashing the whole application.

The case against microservices is also real, and is the one most students do not hear early enough: every microservice is another deployment to operate, monitor, secure, and pay for. Network calls fail in ways in-process method calls do not. Distributed transactions are genuinely hard. Data consistency across services requires designs that monoliths get for free. Microservices trade build complexity for operational complexity, and operational complexity scales with the number of services in a way that surprises people.

Dimension	Monolithic Architecture	Microservices Architecture
Deployment unit	One application, one deploy	Many small services, deployed independently
Codebase	Single repository (typically)	Many repositories, often per-service
Data model	One shared database	One database per service (in the strict version)
Communication	In-process method calls	Network calls (REST, gRPC, messaging)
Team structure	Cross-functional, often one team	One team per service (Conway's Law in action)
Deployment risk	Whole-app blast radius	Per-service blast radius
Operational footprint	One process to monitor	Many processes to monitor, trace, and secure
Best fit	Small-to-medium apps, small teams	Large orgs, many independent teams, mature ops

The unintended consequence to watch for is premature microservices: a small team adopts microservices because the conference talks said to, and immediately spends 70% of its energy on infrastructure (service discovery, distributed tracing, network reliability, schema management) that produces no business value. The pragmatic rule of thumb is "start with a well-modularized monolith and extract services only when you can name the specific pain a split would solve." The monolith is not a phase to be ashamed of; it is often the right answer.

You're doing fine

The monolith-versus-microservices debate looks scary on first contact because both sides have very loud advocates. The good news is the underlying decision is just engineering. Ask three questions: How big is the team? How frequently do parts of the system need to change independently? How much operational maturity do we already have? Big team plus high change-rate independence plus mature ops points toward microservices. Anything less, and a clean monolith will outperform a mediocre microservices estate every time. You already have the framework.

Event-Driven Architecture

Running parallel to the monolith-versus-microservices debate is an orthogonal style called event-driven architecture (EDA). In an event-driven system, components communicate by publishing events — immutable records that something happened — and subscribing to events they care about. Order placed. Payment received. Shipment dispatched. Customer email changed. Each event is a fact, broadcast to whoever wants to know, with no assumption about who that audience will eventually be.

EDA's distinctive property is temporal decoupling: the publisher does not wait for the subscriber, and does not even know who the subscribers are. New consumers can be added later — an analytics pipeline, a notification service, a fraud detector — without changing the publisher. This is enormously valuable when the system needs to grow over time without coordinated releases.

The downsides are also distinctive. Reasoning about a system whose flow of control is "every action emits events that other actions react to" is harder than reasoning about a sequential request-response flow. Debugging a problem requires reconstructing the chain of events that produced it. Schema evolution — what happens when the shape of an event changes — needs careful versioning. EDA rewards mature engineering teams and punishes teams who adopt it before they are ready.

Event-driven architecture and microservices are often deployed together, because microservices need a lightweight, asynchronous way to communicate without re-creating the tight coupling of synchronous calls. The combination is powerful and operationally demanding.

The API Economy: Five Concepts You Need to Know

Most modern integration happens through APIs (Application Programming Interfaces) — published contracts that let one piece of software call another. Whether your team is building monoliths or microservices, customer-facing apps or internal services, the language of APIs is now load-bearing. Five concepts you must be able to discuss confidently are REST, GraphQL, webhooks, the OpenAPI Specification, and API versioning.

REST APIs

A REST API (Representational State Transfer) is a style of HTTP API in which resources (customer, order, invoice) have URLs, and standard HTTP verbs (GET, POST, PUT, PATCH, DELETE) operate on them. GET /customers/42 retrieves customer 42; POST /customers creates a new one; PUT /customers/42 replaces it. REST is the default style of API for most web and mobile applications today; it is simple, cacheable, and works well with the existing web infrastructure.

The genius of REST is also its limitation: every endpoint returns a fixed shape. If a mobile screen needs only the customer's name and email but the /customers/42 endpoint returns thirty fields, the mobile app downloads (and the server serializes) twenty-eight fields nobody wanted. If the same screen needs customer plus their last three orders, the mobile app makes two round trips. These problems are mild for most APIs and fatal for some.

GraphQL APIs

A GraphQL API addresses both problems by letting the client describe exactly which fields and relationships it wants, in a single request. Instead of GET /customers/42, the client sends a query that says "give me customer 42's name, email, and last three orders' totals" — and the server returns exactly those fields, in one response. GraphQL was created at Facebook in 2012 and is now widely used, especially for client-heavy applications where round trips and over-fetching are real costs.

GraphQL's tradeoffs are real too. The query language is more powerful than REST and therefore harder to cache and easier to misuse (a malicious or careless client can request a query that takes the server twenty seconds to satisfy). GraphQL servers need careful query-cost analysis and depth limits. The simplicity REST gets for free, GraphQL has to engineer.

Aspect	REST	GraphQL
Shape of response	Fixed by the server	Chosen by the client
Round trips	Often multiple per screen	Often one per screen
Caching	Easy (HTTP-level)	Harder (responses vary by query)
Tooling maturity	Vast and mature	Strong and growing
Best fit	Public APIs, simple CRUD, microservice-to-microservice	Client-heavy apps, mobile, varied UIs
Risk	Over-fetching, under-fetching	Expensive queries, harder rate limiting

Webhooks

While REST and GraphQL are pull APIs (the client asks the server for data), webhooks are push. A webhook is a URL that one system registers with another, saying, in effect, "when this event happens, please make an HTTP POST to this URL with the event payload." Stripe uses webhooks to notify your application when a payment succeeds. GitHub uses webhooks to notify your CI system when a pull request is opened. Webhooks are the lightweight, real-time backbone of much modern SaaS integration.

Webhooks come with their own set of concerns: the receiver has to be publicly reachable, has to verify that the request really came from the sender (typically via a shared secret signature), has to handle retries (because the network sometimes drops the request), and has to be idempotent (because the sender may deliver the same event twice). Webhook security and idempotency are unglamorous, easy to get wrong, and consequential when they break.

OpenAPI Specification

The OpenAPI Specification (OAS), formerly known as Swagger, is the de facto standard for describing REST APIs in machine-readable form. An OpenAPI document — written in YAML or JSON — declares every endpoint, every input parameter, every response shape, every authentication scheme, and every error code an API supports.

Why does this matter? Because once an API has an OpenAPI document, an enormous toolchain unlocks for free: client libraries can be auto-generated in a dozen languages; interactive documentation renders automatically; mock servers spin up from the spec; contract tests catch breaking changes before deployment. OpenAPI is one of the highest-leverage standards in our field — small effort to write, large benefits to operate. Mature API teams write the spec first and the implementation second; the spec becomes the contract that everything else conforms to.

API Versioning

The last concept is the one that quietly causes the most production incidents: API versioning. APIs evolve. Fields get added, renamed, deprecated, removed. Behavior changes. If consumers of an API depend on its current shape and the API silently changes underneath them, things break — sometimes loudly, often silently and with delayed damage. API versioning is the discipline of evolving an API in a way that does not break existing consumers without warning.

Three common strategies are used in practice:

• URL versioning — put the version in the path: /v1/customers/42, /v2/customers/42. Simple, visible, easy to route. The most common style.
• Header versioning — clients send a header (like Accept-Version: 2) to choose. Cleaner URLs, harder to discover.
• Query parameter versioning — /customers/42?api-version=2. Easy but gets tangled with other query parameters.

Whichever scheme you pick, the deeper rule is: breaking changes require a new version; non-breaking additions can stay in the existing version. Adding an optional field is not breaking. Removing a required field is. Changing the type of a field is. Renaming an endpoint is. Mature API teams publish a deprecation policy (e.g., "v1 is supported for 24 months after v2 ships") and stick to it.

The unintended-consequence pattern to know: silent breaking changes. A team "fixes a bug" in an API response by changing a field's format from string to number, ships the change without bumping the version, and three downstream systems start producing wrong data — but only on Tuesdays, when the affected code path runs. The structural fix is contract testing in CI: every breaking change to the API surface fails the build before it ships.

Putting It All Together

Architecture connects strategy to code. Here is the one-paragraph synthesis of the twenty-three concepts in this chapter:

An organization's application portfolio is structured by an enterprise architecture — described using frameworks like TOGAF and Zachman, captured in reference architectures that constrain individual solution architectures. Within each application, the classic three-tier architecture (presentation tier, application tier, data tier) generalizes to n-tier as systems grow. Across applications, integration patterns like file transfer, RPC, messaging, and event streaming connect the portfolio — historically through an enterprise service bus, increasingly through API gateways. Architectural styles range from monolithic architecture through service-oriented architecture and microservices architecture to event-driven architecture, each with explicit tradeoffs in coupling, deployment, and operational complexity. Modern integration speaks five API dialects you must know fluently: REST, GraphQL, webhooks, the OpenAPI Specification that describes them, and API versioning that lets them evolve without breaking the systems that depend on them.

If that paragraph reads like a map of the field, that is because it is one. Every later technical chapter — data, networks, cloud, security, AI — slots into this architectural geography. You now have somewhere to put what comes next.

Nicely done

You just absorbed the architectural vocabulary that most working IS pros pick up across their first decade. From here on, when somebody says "let's just put it in the ESB" you will hear we are about to leak business logic into integration middleware; when somebody says "we should microservices-ify this" you will hear operational complexity tax incoming, can we name the pain we are paying it for?; and when somebody hands you an API without an OpenAPI spec you will hear we are about to spend the rest of the quarter writing client code by hand. Onward to Chapter 4, where we put this architectural map to work as we look at how applications get built on top of it.

References

See Annotated References