Data-Oriented Architecture: Designing Around the Flow of Data
Most enterprise architecture is organised around execution: which service calls which, in what order, under what contract. Service-Oriented Architecture (SOA) is the mature expression of that idea — a messaging fabric where applications agree on contracts and pass messages along predetermined routes. It works. But it has a blind spot: the service bus doesn't care what's in the message. Meaning lives in the contracts, not the data.
Data-Oriented Architecture (DOA) inverts the priority. It organises the system around the data itself — its design, relationships, access, interpretation, and reuse — and treats execution as something that emerges from the data rather than something the data is poured through. The question stops being "what calls what?" and becomes "what does this data mean, and where can it usefully go next?"
Content re-appropriation
The idea at the centre of DOA is what I think of as content re-appropriation: the ability for data to be reused and repurposed across different contexts without being re-modelled each time. Instead of every consumer getting a bespoke payload shaped by a contract, data is related, classified, and identified through general operations — searching, filtering, grouping, aggregation — and enriched with syntactic or semantic meaning through tagging or interpretation.
The payoff is that a single well-described piece of data becomes useful in contexts its producer never anticipated. Value compounds because the data carries its own meaning instead of borrowing it from a contract.
Execution as a graph, not a pipeline
The deepest difference from SOA is the execution model. A service bus implements routes: a flow of execution based on static, pre-determined rules, indifferent to payload. DOA replaces sequential execution with state transition over a graph of nodes and edges.
Because the system understands the data, traversal and execution can happen in any order. Data can pass between any nodes, and the system can change its operation as it goes — interpreting and modifying data as it moves back and forth between producers and consumers. A data binding technique lets you pass key-value data of any type, scale, or precision to any node. The result is far more adaptable than a fixed route: the same data ecosystem supports many workflows, exposed and securely invoked across any channel.
In that framing, SOA isn't the opposite of DOA — it's a subset of it. Contract-based messaging is one thing you can do once you have a system that understands data; it just isn't the only thing.
What a data-oriented platform provides
A mature DOA platform tends to grow the same set of capabilities, regardless of domain:
- A directory of information assets that supports object-oriented concepts — inheritance, encapsulation, abstraction — plus object parameters, extensibility, and composition/decomposition.
- Data capture, modelling, and tooling for design, relationships, access control, change management, transformation, and processing.
- Multi-channel delivery across web (HTTP/S), messaging (JMS, XMPP, MQTT, STOMP…), and internet protocols (SSH, SMTP/S, FTP/S…).
- Hierarchies, user, and identity support so data is organised meaningfully and access is controlled by role and identity.
- Background services — schedulers, automation, real-time messaging, distributed processing — that automate data-related work.
- Synchronous and asynchronous operation, so the same data flows support real-time and deferred processing.
- Templating, scripting, and command-line support, so models and pipelines can be created and modified programmatically.
- Localisation and multi-lingual support, and modal/contextual interaction (text, voice, gesture) at the application layer.
None of these are exotic in isolation. What makes them data-oriented is that they all operate on a shared, richly-described repository of data rather than on opaque messages in transit.
Where it earns its keep
This isn't the right model for every system — a simple request/response API doesn't need a graph. DOA pays off where data is the product: data mining and knowledge discovery, information integration, machine learning and NLP pipelines, information retrieval, knowledge discovery in social and information networks, and visualization.
It also composes naturally with adjacent technologies. Build a platform on data science, identity, and a distributed trust layer and you get things SOA struggles with: contractless data interchange, multivariate modelling of system interactions, zero-trust transactions, and dynamic user experiences that adapt to the user's changing intent. The use cases that follow — decentralised marketplaces, DeFi, knowledge platforms — are all really the same observation: when the architecture understands the data, the data can go places the original designers never wired up.
The shift in mindset
The practical move is small to describe and large to absorb: stop designing the calls and start designing the data. Model relationships, access, and meaning first; let execution be a traversal of that model rather than a fixed pipeline you maintain by hand. Done well, the system stops being a set of brittle integrations and becomes an ecosystem where data — properly described — is free to be re-appropriated wherever it's useful.
