PayCore: Architecture Communication for Auditors and High Turnover
PayCore processes 4 million card payments per day across five European countries and must satisfy PCI DSS and a national regulator. Nine teams, spread across three time zones, contribute to the platform; contractor turnover is 60% per year. The architecture knowledge base is 400 Confluence pages, many outdated, plus Visio diagrams stored on a shared drive. There are three different data-flow diagrams for the same card-authorization path, and no record of why the platform uses synchronous calls to the fraud service. New engineers take about two hours of senior time per day for their first month to learn the system. Auditors ask for evidence that the architecture meets separation-of-duties and encryption requirements. A newly appointed architect proposes replacing everything with one 250-page PDF, reviewed once a year. The CTO asks whether that will improve communication and audit readiness.
1. Design the architecture description set for PayCore using ISO/IEC/IEEE 42010 concepts. Identify stakeholders, concerns, viewpoints, model kinds, and how decisions and rationale are captured.
Read the worked answer
Start with stakeholders and concerns
Stakeholders include payment operations, security, internal audit, regulators, the nine development teams, the CTO, and card schemes. Their concerns include PCI scope, separation of duties, encryption and key management, availability, change impact, audit evidence, and onboarding speed. The description exists to answer those concerns, not to document every class.
Viewpoints and model kinds
- Context viewpoint: system boundary, card networks, acquirers, regulators.
- Functional viewpoint: payment authorization, capture, refund, and settlement flows.
- Information viewpoint: payment, cardholder, and audit entities with retention and tokenization rules.
- Security and data-flow viewpoint: trust boundaries, encryption points, key management, PCI scope.
- Deployment viewpoint: environments, zones, network controls, and separation between duties.
- Operational viewpoint: monitoring, incident response, and reconciliation.
- Development viewpoint: team ownership, repositories, interfaces, and dependency rules.
Use C4 context and container views for communication, data-flow diagrams for security, sequence models for authorization and fraud calls, and a state machine for payment lifecycle.
Capture rationale
Use architecture decision records for choices such as the synchronous fraud call. Each record states context, decision, alternatives, consequences, owner, and review date. Link decisions to views and to the requirements or controls they satisfy. Record correspondence rules so readers know how views relate.
Keep it usable
Provide one entry point and retire duplicate diagrams. The description should be current, navigable, and tied to evidence, not a static encyclopedia.
2. Evaluate the single 250-page PDF proposal. What does it solve, what does it fail to solve, and what communication mechanisms would you put in its place?
Read the worked answer
What it solves
A PDF can serve as an executive snapshot and as an immutable audit submission for a point in time. It is easy to distribute and hard for casual readers to alter. Those are limited benefits.
What it fails to solve
It does not solve freshness: a yearly review cannot keep pace with nine teams and 60% contractor turnover. It does not solve traceability: a reader cannot follow a decision to a view or a control. It does not solve onboarding: a new engineer needs a guided path, not 250 pages. It does not solve communication across time zones. It also hides disagreement by presenting a single narrative.
Replace it with a communication system
- A living architecture repository with one entry point, current views, and a decision log.
- Generated diagrams where possible, so deployment and dependency views reflect reality.
- Architecture decision records linked to views and controls.
- A short onboarding guide with a reading path and a system walkthrough.
- Stakeholder-specific briefings: security gets data flows, auditors get a control matrix, developers get interfaces and ownership.
- A review cadence tied to change, plus an annual architecture health review.
- A generated audit evidence pack; the PDF becomes an export, not the source of truth.
Verdict
Approve the PDF only as a derived artifact. Reject it as the architecture knowledge base.
3. Auditors need evidence of separation of duties and encryption. How would you make the documentation verifiable rather than merely descriptive?
Read the worked answer
Move from claims to evidence
A diagram that says "encrypted" is a claim. Verifiable documentation links each control to an architecture element, an owner, and evidence that can be inspected. Build a control matrix with columns for requirement, architecture element, control description, evidence source, last verified date, and owner.
Separation of duties
Use the deployment and development views to show environments, roles, and approval paths. Evidence includes identity and access management role definitions, deployment pipeline approvals, change tickets, and production access logs. Show that the team that writes code cannot approve its own production release without an independent control.
Encryption
Use the data-flow view to show where cardholder data crosses trust boundaries, where encryption is applied, and how keys are managed. Evidence includes configuration extracts, key-management policies, certificate inventories, and test results. Generate evidence from configuration where possible so it cannot drift from the diagram.
Make it auditable
Link each claim to an artifact and a date. Use architecture decision records for exceptions and compensating controls. During an audit, walk from the control matrix to the view to the evidence. If evidence is missing, mark the gap rather than filling it with prose.
Outcome
The documentation becomes a navigation aid to evidence, not a reassuring narrative. Auditors can sample controls and verify them, and teams can see what must change when a control fails.