What Three Disciplines Taught Me About Systems

My route into systems analysis was not a straight line through one discipline. It moved through economics, eCommerce, and computer engineering.

For a while, those subjects looked like separate chapters. Economics concerned incentives and allocation. eCommerce connected customers, operations, markets, and digital services. Computer engineering focused on logic, interfaces, architecture, and the behavior of technical systems.

In practice, they became three views of the same question:

How do many independent parts coordinate well enough to produce a reliable outcome?

That question now sits at the center of how I approach software. A system is never only its code. It also contains people with incentives, organizations with responsibilities, policies with consequences, information with ownership, and technology with physical and logical limits.

Systems thinking begins when we stop asking only whether each part works and start asking whether the relationships between the parts produce the intended behavior.

Economics taught me to look for constraints

Economics is sometimes reduced to markets or money. What stayed with me most was a way of observing choices under constraints.

People and organizations do not act inside ideal diagrams. They respond to limited information, competing objectives, risk, time, incentives, and the costs of coordination. A process that ignores those forces may be logically consistent and operationally unrealistic.

When I analyze a software requirement, the economic lens prompts questions such as:

• Who benefits from this decision, and who absorbs its cost?
• Which resource is scarce: time, trust, attention, authority, data, or money?
• What behavior does the current process reward?
• Where does one team transfer risk or effort to another?
• Which information is unavailable when a decision must be made?
• What would a rational actor do if the rule were implemented exactly as written?

These questions are not outside software design. They help explain why users create workarounds, why manual approvals accumulate, why organizations centralize some decisions and delegate others, and why a technically efficient flow can fail to gain adoption.

Incentives are part of system behavior

Suppose a workflow requires a team to provide high-quality data but offers them no benefit for doing so, while another team receives all the value. The field may be mandatory, yet the information will still be weak. The interface can enforce completion, not meaning.

A systems design response might change ownership, provide feedback, reuse the data for the contributor’s work, or move validation closer to the source. The issue cannot be solved by adding another required marker.

This lens keeps me attentive to the difference between formal process and actual behavior.

eCommerce taught me to connect business and technology

eCommerce made the boundary between business and software impossible to ignore. A digital product is simultaneously a customer experience, an operational process, a commercial model, a data system, and a set of technical services.

A small change to checkout can affect conversion, payment operations, fraud controls, inventory, customer support, accounting, and analytics. No single team owns the entire result, but the customer experiences it as one system.

This taught me to follow a capability across boundaries rather than stop at a departmental handoff.

Journeys are only one view

Customer journeys are useful because they organize behavior around a goal. They become much more powerful when connected to the systems underneath them:

Customer view	Operational view	System view
“I submitted my order”	Fulfilment responsibility begins	Order state is created and events are published
“My payment failed”	Support needs a recoverable explanation	Payment outcome and retry safety are known
“I changed my address”	Delivery commitments may change	Address ownership and recalculation rules execute
“My refund is complete”	Finance and service commitments close	Ledger, payment provider, and order states agree

If we model only the visible journey, hidden operational obligations surprise us later. If we model only services, we can build technically correct behavior that makes no sense to the customer. Systems analysis must keep both views connected.

A feature is a temporary name for a capability

Product conversations often begin with features because features are easy to name and prioritize. Underneath each feature is a capability with actors, rules, data, states, and dependencies.

Thinking in capabilities makes the design more durable. Interfaces can change, channels can multiply, and one service can be replaced, while the underlying business responsibility remains. This idea now shapes how I move from product language to system boundaries.

Computer engineering taught me to respect structure

Computer engineering added another scale of thinking. Digital logic, architecture, memory, interfaces, concurrency, and communication protocols show how correct local behavior can still produce incorrect system behavior.

A component may work and the composition may fail. A state can be valid in one place and stale in another. An interface can be clear while its timing assumptions are not. Reliability emerges from structure, not intention.

The technical lens changed the questions I ask during analysis:

• Where is state held, and who may change it?
• Which operation must be atomic?
• What happens when messages arrive late, twice, or out of order?
• Which interface is a contract and which is an implementation detail?
• What must remain consistent, and what may become eventually consistent?
• Where does trust begin and end?
• How does the system fail when one component is unavailable?

These questions help turn a business flow into service behavior that engineering teams can actually implement.

Abstraction should preserve the important constraint

Good abstraction removes detail without removing meaning. That principle applies equally to a domain model and a technical interface.

A business model that ignores technical constraints becomes aspirational. A technical model that removes business meaning becomes reusable in theory and confusing in practice. The useful abstraction preserves the constraint that determines behavior.

For example, “a user has a role” may be too abstract if organizational scope determines access. “A request calls a service” may be too abstract if idempotency determines whether retry is safe. Detail is valuable when it changes a decision.

Systems analysis is the work of translation

The three disciplines meet in translation—not word-for-word translation, but preserving meaning across different representations.

A stakeholder describes an organizational goal. The analyst identifies actors, decisions, and constraints. A process model arranges responsibility over time. A domain model gives concepts stable meaning. A data model defines durable relationships. A service contract expresses behavior at a boundary. Acceptance conditions describe observable proof.

Each artifact is a translation of the same system for a different question and audience.

The work fails when meaning is lost between representations: a policy exception disappears in an API specification, an organizational boundary becomes a global role, or a temporary workflow state becomes permanent data. The analyst’s responsibility is to notice that loss.

One method, three lenses

Today I use a simple sequence:

1. Understand the forces. Identify goals, incentives, constraints, ownership, and missing information.
2. Structure the capability. Model actors, processes, states, concepts, data, boundaries, and rules.
3. Make behavior executable. Specify interactions, services, exceptions, authorization, and acceptance conditions.

Economics strengthens the first step. eCommerce connects the first and second. Computer engineering gives depth to the second and third. Systems analysis brings them into one working practice.

This progression is visible across my systems work: authorization architecture requires organizational and technical models to agree; banking integrations require lifecycle and external constraints to align; digital identity requires business language to survive its translation into process, data, and service design.

Interdisciplinary does not mean unfocused

Moving across disciplines can look like a lack of specialization. For me, the recurring subject has been consistent: complex systems and the relationships that make them work.

Economics showed me systems of incentives. eCommerce showed me systems of value and service. Computer engineering showed me systems of logic and computation. Software analysis gives me a place to combine those perspectives in concrete, testable designs.

The result is not an attempt to make every project theoretical. It is a practical habit: look beyond the requested screen or endpoint, find the surrounding system, make its decisions explicit, and translate them into something people can build.

That is the kind of work I want this portfolio—and this blog—to make visible.