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.

This article is part of ZibiWorks, an ongoing fictional modernization case study. The ZibiWorks site is the canonical home of the series, with the full company context, starting architecture, and related installments. Explore the full series at ZibiWorks.

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.

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.

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.

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.

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.

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.

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.