Every company runs on a stack of big systems. And every data project eventually collides with one of them. The CRM that owns the customer records. The ERP that owns the numbers. The fifteen-year-old monolith nobody dares to touch.
This category names those systems. It also names the engineering discipline that connects them. Term by term 👇
30-Second Summary
Architecture and systems cover the platforms where business data actually lives: CRM, ERP, content management. Plus the architectural patterns and legacy realities that shape how data moves between them.
What This Category Covers
- The discipline: data engineering
- The patterns: monolithic architecture and legacy systems
- The platforms: CRM, ERP, and ECM
📌 Quick take: Architecture debates feel abstract until you try to move data. Then every pattern choice someone made a decade ago sends you an invoice.
The Terms in This Category, Walked Through
The discipline comes first. data engineering is the craft that builds and runs the infrastructure every other page in this wiki assumes. Pipelines, warehouses, quality systems. Plus the operational habits (idempotency, contracts, observability, cost tracking) that keep data arriving complete and on time.
That page covers a representative day and the modern principles. And it shows how the role divides as teams grow: platform, movement, modeling, and trust.
Then the architectural patterns. Monolithic architecture gets the honest treatment its reputation rarely receives. One deployable unit, one shared database. Simple to operate, consistent by construction, tangled only when discipline lapses.
The page walks the industry’s monolith-to-microservices-and-back arc, plus the modular-monolith position that emerged from it. Then come the data consequences: a single schema that’s easy to find but modeled for the app, not for you. And the decomposition checklist at the end has talked more than one team out of an expensive mistake.
Legacy systems covers the machines that outlived their era but not their importance. Why do they persist? Because they work, and their business logic is documented nowhere else.
You get the four-option modernization menu (maintain, wrap, migrate, replace) with real definitions. Next comes the data-archaeology problem of extracting decades of feral semantics. And you get the risk register that turns ‘we should modernize’ into a ranked portfolio. Its closing section, preventing tomorrow’s legacy today, is the one to read while your systems are still young.
Then the platforms where enterprise data actually lives. ERP runs the operational money: finance, procurement, inventory, orders on one shared database. The page explains why implementations earn their horror stories. It’s operational surgery, not software installation. It also shows why master data is where ERP quality is won, and how analytics extracts finance-grade truth without touching the system that closes the books.
ECM manages everything that isn’t in a database. Contracts, invoices, policies. Capture, classification, retention, and defensible destruction. The metadata economy and the migration playbook form its practical core.
And CRM is the revenue team’s shared memory. The page maps the data model (accounts, contacts, leads, opportunities, activities) and its misuse patterns. It covers the hub position that makes CRM quality everyone’s inheritance, plus the adoption dynamics that decide whether the system lives. There’s also a five-number health scorecard worth running quarterly.
How These Systems Relate
The seams repeat across companies. CRM owns relationships while ERP owns money. So the entity matching between their customer records is a canonical integration project.
Both feed the warehouse through extraction pipelines built by data engineering. Content in ECM increasingly becomes structured data through extraction. And every one of these systems drifts toward legacy status, given enough birthdays and customizations. That’s why the legacy page’s prevention section applies to systems bought last year.
Using This Folder
Building a data practice? Read data engineering first. It’s the lens for everything else. Read the platform pages (ERP, CRM, ECM) when you’re integrating with those systems or extracting from them. Each includes the data-team perspective most vendor documentation omits.
And read the monolith and legacy pages before any architecture debate. Together they inoculate you against the two most expensive reflexes in the field: decomposing what works, and replacing what merely embarrasses.
Questions This Category Answers
“Where does the truth live?” The platform pages draw the map. Money and operations sit in ERP, relationships in CRM, documents in ECM. And the seams between them are where identity questions concentrate.
“Should we break up the monolith?” The monolith page’s checklist forces the honest version of that debate. Name the pressure. Plan the data split first. Price the operations, and keep the first step reversible.
“What do we do about the old system?” The legacy page’s four-option menu and risk register turn dread into portfolio management. And its archaeology section is required reading before any migration touches decades-old data.
“Why can’t we just query the production database?” The data engineering answer: extraction into analytical systems, behind contracts, monitored. Every platform page repeats that pattern. Because every production system deserves it.
“Why is the same customer different in every system?” That’s the folder’s recurring seam. Entity matching between platforms gets mastered deliberately or fragmented by default. The ERP page’s master-data section and the CRM page’s identity disciplines are two views of one fix.
This folder’s through-line is short. Systems age. Patterns cycle. And the data outlives all of it. Architect for the data’s longevity and the platform decisions get easier, and cheaper to revise.
How This Category Connects to the Rest of the Wiki
Every other category eventually knocks on this folder’s door. Because these systems are where the data actually lives. The flow folder‘s pipelines drain them. The quality folder‘s matching and dedupe wrestle with their overlapping customer records. Meanwhile the analytics folder reports on their extracts. And master data management exists precisely to arbitrate between them.
The governance categories carry special weight here. identity management controls who touches these systems, the ERP and CRM being every auditor’s first stops. And privacy obligations land hardest on the platforms holding the most personal data. Which is these.
One closing observation from watching many estates. Companies don’t really choose their architecture. They accumulate it. Purchase by purchase, merger by merger, decade by decade.
The pages in this folder help you manage that accumulation deliberately. Know what each system owns. Extract from it safely, integrate it honestly, and retire it without losing thirty years of truth. That management, more than any diagram, is what ‘good architecture’ means in practice.
Frequently Asked Questions
What is enterprise architecture?
The structure of an organization’s major systems, meaning the platforms that hold its data and the patterns that connect them. In practice it’s less designed than accumulated, which is why managing it deliberately matters so much.
What is the difference between CRM and ERP?
CRM manages customer relationships (contacts, deals, activities). ERP manages the operational money (finance, inventory, orders). Most companies run both, and matching customers between them is a classic integration project.
What makes a system a legacy system?
Age alone doesn’t. A system becomes legacy when it still matters but nobody can safely change it. That usually means undocumented business logic and expertise that retired years ago.
Should every monolith be broken into microservices?
No. A well-modularized monolith is often simpler to operate and consistent by construction. Decompose only when a named pressure justifies the operational cost, and plan the data split first.