The Journey

ZibiWorks is a continuing architecture story. Each installment introduces a new business or technical pressure, explores the tradeoffs, and makes the next decision visible.

This page is the roadmap for that story. It shows where the series is going before you start the numbered installments, so you can see the shape of the whole thing and find your place in it.

The questions are planned. The architecture is not.

Planned

The questions ZibiWorks works through, and the order they tend to arrive in. We know the pressures the company will face.

Open

The answers. Microservices, events, CQRS, SaaS, and the rest are possible outcomes, not decisions already made. Each is earned by a specific pressure, or not at all.

This is a series roadmap, not an architecture roadmap. It describes the questions and the pressures. The installments work out the answers.

The path

Six parts, read in order. Each builds on the ones before it.

📍 Start Here→I Understand the Problem→II Find Better Boundaries→III Pull Apart Safely→IV Change Collaboration→V Operate the Platform→VI Next Growth Phase

○ planned● current✓ published

The installments

Part IUnderstanding the ProblemUnderstand what actually deserves to change before choosing architecture.

• ✓What's Driving Change?What problem is ZibiWorks actually trying to solve?
• ✓Move It or Fix It First?Should ZibiWorks modernize before moving infrastructure?
• ○Rewrite vs. EvolveShould ZibiWorks replace the monolith or change it incrementally?

Part IIFinding Better BoundariesUnderstand the business and code boundaries before decomposing anything.

• ○The First SeamWhere can we safely make the first cut?
• ○Boundaries and MeaningHow the same business language can mean different things across domains.
• ○Domain or Utility?What should be shared across domains, and when does shared code recreate coupling?

Part IIIPulling the System Apart SafelyMake the incremental evolution concrete, especially around data ownership and migration.

• ○Separating Shared DataHow do we establish clear data ownership when everything shares SQL Server?
• ○Moving the Data Without Moving the ProblemHow do we transition data ownership without requiring a big-bang migration?May grow to cover: initial seeding, coexistence during migration, synchronization, cutover sequencing, reconciliation, rollback, historical data, temporary duplication, and incremental rather than single-conversion migration.
• ○The Front DoorHow should old and new capabilities coexist behind a stable entry point?
• ○One Backend, Different ExperiencesShould every user experience consume the same backend shape?
• ○Untangling the PartnersHow do we keep external partner models from shaping internal business logic?

Part IVChanging How Systems CollaborateHow independently owned domains collaborate, including the messy realities of asynchronous messaging.

• ○When Synchronous Stops WorkingWhich workflows really require an immediate response?
• ○Events Are FactsWhat should become an event?
• ○What If the Event Arrives Twice?What does reliable asynchronous collaboration require in the real world?May grow to cover: at-least-once delivery, duplicate messages, idempotency, ordering, retries, poison messages, dead-letter handling, outbox patterns, replay, consumer recovery, and eventual consistency.
• ○Reading Without OwningHow do we build views across domains without recreating the shared database?
• ○Orchestration or Choreography?Who coordinates a business process that crosses domain boundaries?

Part VOperating the New PlatformDecomposition is not finished when the code is split: the platform must also be observable, resilient, independently deployable, and able to evolve contracts safely.

• ○Can We See What Is Happening?How do we operate a system once requests cross multiple components?
• ○What Happens When Dependencies Fail?How should the platform behave when something it depends on is slow or unavailable?
• ○Can We Deploy This Independently?What has to change before architectural boundaries become real deployment boundaries?May grow to cover: independent deployment, CI/CD boundaries, release coordination, backward compatibility, rollout and rollback, feature flags, and progressive delivery.
• ○When Contracts ChangeHow do independently evolving systems change APIs and events without breaking one another?May grow to cover: API compatibility, event contract evolution, versioning, consumer compatibility, schema evolution, and deployment skew.
• ○Resilience or Recovery?What failures do we design through, and what failures do we recover from?
• ○How Portable Should We Be?How much cloud-specific capability should ZibiWorks embrace?

Part VIPreparing for the Next Growth PhaseShow the business payoff of the modernization, and the new pressures created by success.

• ○What Did We Buy With All This?What business capabilities became easier because of the modernization?
• ○From Product to PlatformWhat happens when capabilities originally built for ZibiWorks itself become useful to partners or other consumers?
• ○One Company, Many Customers?What new architectural pressures appear if ZibiWorks begins moving toward SaaS or multitenancy?
• ○The Next ZibiWorksWhat new pressures appear now that the company is ready to grow again?

The plan can change

The journey will evolve as ZibiWorks does. Topics may move, split, or combine as new pressures emerge. The sequence above is the current plan, and it is a real one.

Start reading

The story begins after the two orientation pages: the business and the platform it runs on today. From there, Part I opens the first real decision.

The Story →Follow ZibiWorks from the beginning, one installment at a time.