Many modernization programs begin with a structural question: where should we split the monolith? Teams draw service boundaries, select a messaging platform, and plan a sequence of deployments. Then the work reaches the database and slows down. Several proposed services still need to update the same tables. A change to one business rule affects three schemas. Nobody can say which system is authoritative when two records disagree.

This is not primarily a service-boundary problem. It is a data-ownership problem. If ownership remains ambiguous, distributing the application creates more places for that ambiguity to surface. The organization gains network calls, asynchronous failure modes, and operational overhead without gaining meaningful autonomy.

My point of view is straightforward: define data ownership before committing to physical service separation. A modular monolith with clear authority over data is often a stronger modernization step than a collection of services that share write access to the same database.

A shared database is not the first problem

Shared infrastructure can be a reasonable transitional choice. The real danger is shared authority. When multiple modules can modify the same business data directly, every one of them becomes part of the data model's hidden public interface. A column rename becomes a coordinated release. A validation rule can be bypassed. A production incident becomes harder to diagnose because the last writer may not be the logical owner.

A technical schema alone does not resolve this. Database ownership must follow business accountability. The component that owns an order is responsible for the rules that make an order valid, its lifecycle, and the meaning of its state. Other components may need the information, but needing data is not the same as owning it.

This distinction matters to executives as much as engineers. Unclear ownership increases the cost of change and makes delivery dates less dependable. Clear ownership creates an accountable path for decisions: one team can change a capability while preserving explicit contracts with the rest of the system.

Define ownership in operational terms

"Team A owns the customer table" is too weak. Ownership should describe authority and obligations, not just a storage location. For each important business dataset, answer these questions:

• Who is allowed to create, change, and retire the data?
• Which business invariants must the owner enforce on every write?
• Which system is authoritative when copies or downstream views disagree?
• How will consumers receive the data: synchronous query, event, replicated view, or batch export?
• What freshness, availability, privacy, retention, and audit obligations apply?
• Who decides when the data contract must change?

The answers form a practical ownership contract. They expose issues that a component diagram will not. For example, a team may appear to own inventory, while an ordering module can still decrement stock directly. That is not ownership; it is shared write authority hidden behind a familiar schema.

Map business decisions before drawing services

A useful decomposition exercise starts with decisions rather than nouns. Ask which capability decides whether an order can be accepted, which capability allocates inventory, and which capability determines that an invoice is payable. The owner of a decision usually needs authority over the data required to enforce it.

This does not mean every noun becomes a service. Customer, product, and order are broad concepts that often span several contexts. The same customer identifier may appear in sales, support, and billing, but each context may own different facts. Sales can own prospect qualification, support can own case history, and billing can own payment terms. Trying to force all of those meanings into one universal model creates coupling disguised as consistency.

Prefer a small number of explicit sources of truth over one enterprise-wide model that every team can modify. Consistency should be deliberate: strong where a business invariant requires it, and asynchronous where a controlled delay is acceptable.

A safer sequence for decomposition

1. Establish logical ownership

Assign one module or bounded context as the only writer for a dataset. Document its invariants and consumers. This can happen inside the existing monolith, with no network boundary and no immediate database migration.

2. Route writes through the owner

Replace direct table updates from other modules with calls to an application interface owned by the responsible capability. Enforce the boundary with code structure, permissions where practical, and automated architecture tests. The objective is not ceremony; it is to make unauthorized writes difficult and visible.

3. Separate read convenience from write authority

Consumers often share a database because joins are convenient. Preserve that convenience intentionally through read models, views, APIs, or replicated data. A reporting workload may need a denormalized copy of order and billing facts, but it should not become another writer. Copies are manageable when their authority and freshness are explicit.

4. Prove the contract under real change

Before extraction, deliver several changes through the new boundary. Observe whether the interface captures the business behavior, whether consumers need excessive round trips, and whether events contain enough context. A boundary that survives real delivery work is more credible than one validated only on a whiteboard.

5. Move the runtime and storage only when justified

Once ownership and contracts are stable, decide whether independent deployment, scaling, resilience, security isolation, or team autonomy justifies a separate service. Physical separation then becomes an implementation choice built on an existing boundary, not an experiment that must discover the boundary in production.

Accept the tradeoffs explicitly

Clear data ownership does not remove complexity; it places complexity where it can be managed. Synchronous access may add latency and couple availability. Events improve temporal decoupling but introduce eventual consistency, replay, and ordering concerns. Replicated read models improve autonomy but require reconciliation and observable freshness. Separate databases strengthen isolation but make cross-domain reporting harder.

There is also an organizational cost. The owning team must operate a dependable contract and respond to consumer needs without surrendering authority. Consumers must stop treating database access as a shortcut. Leadership has to support that discipline when a direct update looks faster for one urgent release.

The right choice depends on the business consequence of delay or inconsistency. Payment authorization may require a tighter interaction than updating an analytics dashboard. Architecture should reflect those consequences rather than applying one integration pattern everywhere.

Use better modernization checkpoints

Do not measure progress by the number of services created. Measure whether authority is becoming clearer and change is becoming safer. Useful checkpoints include:

1. Every critical dataset has one named logical owner.
2. Unauthorized write paths are known and declining.
3. Consumer contracts state freshness and failure expectations.
4. Copies and read models have reconciliation and observability mechanisms.
5. A capability can change its internal model without coordinating every consumer.

These signals are valuable whether the final architecture is a modular monolith, a small set of services, or a broader distributed platform. They focus the program on autonomy and accountability rather than topology.

Conclusion

Splitting a monolith before defining data ownership tends to distribute uncertainty. Define who can decide, who can write, which source is authoritative, and what consumers may expect. Enforce those rules inside the current system, test them through real delivery, and extract services only where the operational benefits justify the cost.

The most durable service boundary is usually visible in the data long before it appears in the deployment diagram. If your modernization roadmap is stalled at a shared database, that is the place to clarify authority—not a reason to add more infrastructure.