01. What's Driving Change?

Before designing anything, find where the current platform is starting to limit the business, and which touch points deserve a closer look.

Modernization

ZibiWorks believes they need to modernize, but that conclusion did not come from an architecture diagram. It came from mounting pressure on the business and the teams supporting it. Changes take longer than they should. Deployments carry more risk. Partner integrations are getting harder to manage. New customer experiences and connected-product capabilities are placing demands on a platform that was built for a simpler business.

Those pressures are real, but they do not yet tell us what architecture to build. The instinct is often to jump directly to services, a message bus, the cloud, or a cleaner data model. That is premature. Before choosing an architecture, we need to understand where the current one is actually getting in the way, what business outcomes are being affected, and which problems are significant enough to justify change.

So this installment is about where modernization should start, not what to build. We will identify the business and technical pressures worth addressing, turn them into an initial set of success criteria, and establish the guiding principles that later architecture choices can be weighed against. Those criteria and principles become the decision lens for everything that follows.

What should guide the decision?

Before choosing an architecture, we need to know what should guide the choice. That comes from combining two things: the business context, which tells us what matters, and the technical context, which tells us what is feasible, sustainable, and responsible to build and operate. The business rarely asks for “changeability” or “resilience” by name; those are architectural interpretations. Neither side provides the answer alone.

In brownfield work that business context often shows up as existing pain; in greenfield work it more often arrives as goals, constraints, and assumptions. Either way, the two inputs are:

Business context

Desired outcomes and business capabilities
Where the pressure is (for ZibiWorks, existing pain)
Cost, delivery, and timing
Customer expectations and growth assumptions
Risk tolerance and regulatory constraints

Technical context

Current platform capabilities, where one exists
Available technology choices and constraints
Team skills and operational maturity
Resilience, security, data integrity, observability
Technical debt (where applicable) and cost to operate

Combining the two produces the first useful output, and it is not a target architecture. It gives us two things we can use to evaluate architecture choices: success criteria, which describe what needs to improve and how we will know, and guiding principles, which describe how we make decisions while pursuing those improvements.

Those criteria and principles become the lens for the decisions that follow.

flowchart LR
    R["Business +<br/>technical context"] --> P["Principles &amp;<br/>success criteria"]
    P --> E["Evaluate<br/>options"]
    E --> D["Tradeoffs &amp;<br/>decisions"]
    D --> O["Outcomes &amp;<br/>learning"]
    O -->|"revisit as context changes"| R

These are working criteria and principles, not commandments. As the business and technical context change, the decision lens changes with them.

For ZibiWorks, then, the first step is not to redesign the platform because the architecture looks old. It is to find where the current architecture is actually creating meaningful friction, trace those pressures into the platform, and mark where architectural change might create leverage, stopping short of choosing a solution. Each pressure below follows the same path:

Business pressure→Business constraint→Architectural touch point→Options examined later

The platform still works

The platform is doing its job. Orders are placed, Zibis are shipped, customers and partners are served. The business is operating.

The original architecture was a good fit for an earlier ZibiWorks. What changed is the business around it. Growth has changed the consequences of the original tradeoffs.

The result is not a broken platform. It is a working platform beginning to show wear in a few important places. Those pressures are where the rest of this installment focuses.

Pressure 01 · Brittleness

The platform is getting harder to change safely

Over time, ZibiWorks’ concerns have grown into one another. Orders reach into Pricing, Inventory, Payments, Fulfillment, Shipping, Customer, and Zibi Lifecycle, with product and catalog logic close behind. Shared models span several business areas. Entity Framework entities flow upward through the stack. Common models are reused broadly, and shared tables carry ambiguous ownership.

No single one of these dependencies is wrong. An Order genuinely needs pricing and inventory. The trouble comes from how many of them accumulate and cross through the same shared models, so a change in one area rarely stays in one area.

flowchart LR
    Product["Product / Catalog"] --> Orders
    Zibi["Zibi Lifecycle"] --> Orders
    Orders(["Orders"]) --> Pricing
    Orders --> Payments
    Orders --> Customer
    Orders --> Inventory
    Inventory --> Fulfillment --> Shipping
    Shipping --> Orders

A local change around Orders rarely stays local, because Orders is entangled with several surrounding concerns.

Interwoven concerns→Larger blast radius→Broader testing→More coordination→Slower delivery

A local change can have non-local effects. Making a change safely takes broader knowledge of the system, regression testing expands, releases need more coordination, and one change is harder to isolate from everything else.

Pressure 02 · Partner Coupling

External change has become an internal delivery problem

ZibiWorks depends on PayPaw, Handle With Care, Paw & Circuit, RoboMotion Systems, and HomeSphere. As covered in The Starting Point, partner-specific fields, statuses, identifiers, workflows, payload shapes, and batch formats have worked their way into internal logic and shared models.

flowchart TB
    P["Partner concerns leaking inward"]
    Orders["Orders"]
    Shipping["Shipping"]
    Inventory["Inventory"]
    Shared["Shared models"]
    Zibi["Zibi"]

    P -.-> Orders
    P -.-> Shipping
    P -.-> Inventory
    Orders --> Shared
    Shipping --> Shared
    Inventory --> Shared
    Shared --> Zibi

Partner change now reaches beyond the partner boundary.

The business impact is specific: a partner change can require changes in parts of ZibiWorks that look unrelated to that partner. A new API version, changed payload, revised status model, new capability, deprecated interface, or new compliance requirement can all ripple inward.

There is a second cost that is easy to miss. Because the integrations are woven so deeply into the platform, ZibiWorks may not be able to adopt a better partner API or a new partner feature quickly. That quietly limits its options.

Pressure 03 · Growth

Each new capability increases the cost of the next one

ZibiWorks wants to expand: more connected Zibis, more partners, more customer and internal capabilities, new products and services, more reporting, and eventually new platform opportunities. The current platform can support all of it. The problem is that each new capability tends to make the next one harder. That points at a kind of scalability people often skip past.

Runtime scalability

More requests
More transactions
More connected devices
Can the infrastructure handle growth?

Change scalability

More capabilities
More teams changing the system
More dependencies and coordination
Can the organization keep changing safely?

Scalability is not only about runtime capacity. Runtime scaling and change scaling are different problems. Right now, change scalability is the bigger problem.

Pressure 04 · Capacity

Normal demand or peak demand?

ZibiWorks runs on traditional infrastructure, so it has to size capacity ahead of demand. Demand is not steady. Holidays, promotions, product launches, partner campaigns, and seasonal buying all push it around.

Peak-sized: headroom, idle most of the yearNormal-sized: efficient, but spikes overrun it

Size for normal demand: lower steady-state cost, greater peak risk. Size for peak demand: more headroom, more idle capacity.

The architecture makes this sharper. Much of the platform scales as a coordinated unit, so a spike in one area can force ZibiWorks to add capacity broadly rather than where the load actually is. The conclusion is not that cloud is the answer. ZibiWorks needs a better answer to variable demand, and cloud elasticity may eventually be one option worth weighing.

Pressure 05 · Customer Experience

Reliability is becoming part of the product

ZibiWorks is increasingly customer-facing. When the platform mostly supported internal operations, downtime was an internal disruption. As more of it faces customers, downtime becomes something customers see: a slow storefront, a failed checkout, account functions that will not load, delayed order information, Zibi management that is unavailable, connected features that degrade.

This connects directly to the capacity pressure. The periods of highest customer demand are often the periods of highest infrastructure strain, so a capacity shortfall tends to show up as a customer-facing outage at the worst possible time.

Customer demand ↑→Infrastructure pressure ↑→Performance / availability risk→Customer experience

Reliability and scalability are becoming part of the customer experience, which raises later questions about resilience, observability, failure isolation, graceful degradation, and recovery.

None of these pressures selects an architecture. They mark where the current platform constrains the business. Patterns and technologies come later.

From business pressure to architectural touch point

Each pressure points at an area of the architecture worth examining later. These touch points show where the series will look next without assuming the eventual solution.

Business pressureArchitectural touch point

Changes ripple→Boundaries, dependency structure, modularity

Partner blast radius→Integration boundaries, anti-corruption layers (ACLs), contract isolation

Growth cost rises→Extensibility, deployment boundaries, incremental evolution

Variable demand→Scaling model, workload isolation, elasticity

Visible downtime→Resilience, failure isolation, observability, recovery

Ambiguous ownership→Domain modeling, data ownership, contextual models

Diverging experiences→API boundaries, consumer-specific contracts

Reporting pressure→Analytical separation, read models, data movement

Sorting what is fine from what is not

Not everything imperfect in the platform is worth changing. Some of what looks dated is still doing its job perfectly well, and some of what works today is already starting to strain. The point of sorting is to separate the parts that are fine from the parts that are actually costing the business something.

Still serving the business

.NET
SQL Server
Entity Framework
Responsive web application
Relational transactions
Shared deployment where it still simplifies operations

Creating measurable friction

Cross-domain business coupling
Ambiguous data ownership
Partner logic inside core services
Coordinated deployment
Broad regression impact

The business is beginning to require

Stable API contracts
Additional user experiences
More independent scaling
Clear telemetry and state ownership
Separation of operational and analytical workloads
Higher customer-facing availability

If this does not materially affect delivery speed, risk, scalability, availability, security, cost, or a business capability, why are we changing it?

We carry forward only the areas where a technical constraint can be tied to meaningful business impact.

The initial decision lens

The pressures point to five areas worth deeper investigation. Together they become the first working success criteria for ZibiWorks: for each, the current strain and what improvement would look like.

Area & current strain	What success looks like
Changeability. Cross-domain coupling, shared ownership, and broad regression impact are raising the cost of change.	A smaller blast radius, less regression and coordination effort, and more changes that stay local.
Extensibility. Partner coupling and the rising cost of adding capabilities make external change expensive.	Less effort to absorb partner and capability changes, with fewer unrelated areas affected.
Scalability. Variable demand and increasingly different workload profiles expose both runtime and change-scaling constraints.	Handling variable demand without scaling the platform as one unit, while improving the system’s ability to absorb ongoing change.
Reliability. Performance and availability problems are becoming visible to customers.	Fewer customer-visible failures, with better failure isolation and recovery where the business impact justifies it.
Data. Ambiguous ownership and competing operational and analytical needs are creating friction.	Clearer ownership and meaning, with less interference between operational and analytical workloads.

These are directions, not numeric targets. The evidence tells us what needs to improve; the levels worth committing to come as specific decisions get made.

These criteria describe what needs to improve. The guiding principles describe how ZibiWorks should make decisions while pursuing those improvements. They are not intended to map one-to-one to the criteria; most apply across several of them.

Favor change isolation where coupling is materially slowing delivery.
Improve resilience where failures are becoming customer-visible.
Prefer reversible changes while the cost of being wrong is high.
Add complexity only when it buys a capability the business actually needs.
Preserve simplicity where the current design is still serving the business.
Design for foreseeable growth, not every theoretical future.
Treat security, data integrity, and operability as baseline constraints.

These are ZibiWorks’ first working criteria and principles, not permanent rules. They give the next decisions a consistent starting point and will be revisited as the context changes.

With the pressures identified, the criteria named, and the principles in hand, ZibiWorks can take on its first real choice: do we address these constraints before moving the platform, or move first and modernize afterward?

ZibiWorks is fictional. The ideas and opinions expressed throughout the series are my own and do not represent the views, positions, or practices of my employer.