| Lesson 5 | Separation of Concerns by an Architect |
| Objective | Explain how an architect approaches complex problems. |
Separation of Concerns for e-business Architects
A brick-and-mortar retailer implementing an online presence does not face a single problem — it faces seven simultaneous problems, each owned by a different part of the organization, each defined by a different set of priorities, and each capable of derailing the project if not addressed on its own terms.
The diagram above identifies the seven stakeholder groups whose concerns shape the e-business architecture. Each group perceives the implementation challenge differently, and each perception is legitimate. The architect's job is not to choose one perspective over another — it is to hold all seven simultaneously and design a system that addresses each on its own terms.
The Seven Stakeholder Concerns
Stores worry about channel conflict — the risk that online sales will cannibalize in-store revenue rather than complement it. They are also concerned with inventory synchronization: if a customer orders online and selects in-store pickup (BOPIS), the inventory system must reflect real-time stock levels across every location. Returns present a related challenge — online purchases returned to physical stores create excess inventory that the store was not planned to absorb. Staff training for omnichannel operations adds operational complexity that store managers must absorb without additional headcount.
Finance focuses on ROI justification for e-business investment, which is difficult to model accurately before the platform is live. Transaction fee structures — payment processor fees, marketplace commissions, chargeback costs — erode margins in ways that are not always visible in early projections. Multi-currency support and tax compliance across jurisdictions add accounting complexity. Fraud loss management is a recurring cost that Finance must budget for and the architect must design controls around.
Customer Service faces a structural challenge: online customers expect 24×7 support across multiple channels — live chat, email, phone, and self-service — while physical store customer service is typically staffed during store hours at a desk in the back office. Centralizing customer service for online operations requires new tooling, new workflows, and new escalation paths. Returns and refunds for online purchases are more complex than in-store returns, requiring integration between the e-commerce platform, the order management system, and the warehouse.
Buyers — the customers — care about trust, speed, and convenience. They need to trust that their payment data is secure, that the product they receive will match what they ordered, and that returns will be handled without friction. They expect the mobile experience to be as capable as the desktop experience. They expect personalization — recommendations based on their history, promotions relevant to their preferences — and they expect delivery to be fast and trackable. Each of these expectations is an architectural requirement.
The Board of Directors is concerned with strategic alignment and competitive positioning. If the platform goes down during a peak period — a holiday sale, a product launch — the reputational and financial consequences are visible to analysts and investors. The Board must approve the level of investment in redundancy and disaster recovery, which means the architect must be able to translate technical risk into business risk in terms the Board can evaluate. Long-range viability in international markets, partnership and alliance decisions, and regulatory compliance in new geographies are all Board-level concerns with architectural implications.
Merchandisers worry about what will sell online and how to present it. Product catalog management for an e-commerce platform is more complex than for a physical store — every product needs images, descriptions, dimensions, variants, and pricing rules that work across device sizes and markets. Promotional execution must be coordinated across channels without creating price inconsistencies that erode customer trust. Seasonal inventory planning must account for the longer lead times that online fulfillment requires compared to in-store replenishment.
IT is concerned with the full technical stack: platform selection, system integration complexity, security architecture, scalability, uptime, disaster recovery, and the interfaces between the new e-commerce platform and existing legacy systems. Every other stakeholder group's concerns ultimately arrive at IT as a technical requirement. The architect must translate those requirements into a coherent technical architecture and communicate it in terms that each stakeholder group can evaluate against their own criteria.
Separation of Concerns as an Architectural Method
The separation of concerns is the architect's primary method for managing the complexity that these seven stakeholder groups generate. The principle is straightforward: separate different aspects of the system into distinct, independent components, so that each component can be designed, built, tested, and maintained without requiring knowledge of the others.
Applied to e-business architecture, separation of concerns operates across five key dimensions:
User interface design is separated from the systems that deliver the data it displays. Component-based frameworks — React, Vue, Next.js — enforce this separation structurally, enabling UI teams to iterate on the customer experience without modifying business logic or data access layers. Headless commerce architectures take this further, decoupling the frontend presentation layer entirely from the commerce engine behind it.
Business logic defines the rules that govern how the system operates — pricing calculations, discount eligibility, inventory allocation, fraud scoring. In modern e-business architecture, business logic is increasingly organized around microservices and domain-driven design principles, which assign ownership of specific business domains to specific services. This prevents business rules from being scattered across multiple systems and makes them easier to test, modify, and audit independently.
Data management addresses how data is modeled, stored, and accessed. Cloud-native databases — PostgreSQL, MongoDB Atlas, Supabase — and modern ORMs — Prisma, Hibernate, SQLAlchemy — provide structured access patterns that enforce separation between the data layer and the application layers above it. Event sourcing and CQRS (Command Query Responsibility Segregation) patterns further separate the write path from the read path, enabling independent scaling of each.
Integration and interoperability addresses how the e-business platform communicates with the systems around it. API-first architecture — REST and GraphQL for synchronous communication, webhook-driven event architectures for asynchronous communication — provides stable, versioned interfaces between systems. iPaaS platforms — MuleSoft, Boomi — manage integration complexity for organizations with large numbers of third-party connections.
Security and privacy is separated from application logic and enforced at the infrastructure and API gateway level. Zero-trust architecture principles require explicit verification at every access point, regardless of network location. PCI DSS compliance is enforced through tokenization of payment data and scope reduction — keeping card data off application servers entirely by delegating payment processing to certified providers such as Stripe or Adyen.
Consequences of Separation of Concerns
Without separation of concerns, the seven stakeholder concerns described above collapse into a single undifferentiated problem that is too large and too complex to reason about coherently. The architect who attempts to address all concerns simultaneously, without partitioning, will produce a design that satisfies none of them fully.
Separation of concerns allows the architect to partition the problem space using whichever lens is most useful at a given stage of the process. Geographic distribution of constituents suggests one partitioning — separating concerns by market or region. Organizational roles and responsibilities suggest another — separating concerns by the business function that owns them. Application functionality suggests a third — separating concerns by the capability domain they belong to.
The choice of partitioning strategy is itself an architectural decision, and it shapes everything that follows. An architect who partitions by organizational role will produce a system that mirrors the org chart — which may be appropriate for a large enterprise with stable, well-defined business units, but will create problems for an organization that reorganizes frequently. An architect who partitions by application functionality will produce a system that is easier to evolve technically, but may create ownership ambiguity across business units.
Interfaces Defined by Selecting Boundaries
When the architect partitions the problem space, the boundaries she draws define the interfaces between components. This is not incidental — it is the mechanism by which separation of concerns becomes operational. The interface between two components determines what each component knows about the other, what data flows across the boundary, and what each component can change independently without affecting the other.
In information management systems, what is visible across a boundary is determined by access privileges. A customer sees order status and delivery tracking. A customer service agent sees order history, payment method, and return eligibility. A finance analyst sees transaction totals, refund rates, and chargeback ratios. Each view is a different slice of the same underlying data, presented through a boundary that enforces what each role is permitted to see.
In ERP integration, boundaries are created by business function domains. Modern ERP platforms — SAP S/4HANA, Oracle Fusion Cloud, Microsoft Dynamics 365 — organize these boundaries around modules: Finance, Human Resources, Supply Chain, Order Management. Each module exposes APIs that allow external systems to interact with its data without accessing its internal implementation. Connecting an e-commerce platform to an ERP system means defining which data crosses which boundary, at what frequency, and through which integration pattern.
Supply chain integration previously relied on VPN tunnels and secure socket connections between company networks. In 2026, the standard approach is API-based B2B integration — EDI over HTTPS, supply chain APIs, and iPaaS platforms that manage data transformation and routing between the ERP and supply chain providers. The boundary is still drawn between the company's internal systems and the supplier's systems, but the interface across that boundary is now an API contract rather than a network tunnel.
Drawing boundaries — or deliberately expanding them — has strategic consequences. Tighter boundaries create cleaner interfaces and reduce integration complexity, but limit flexibility. Looser boundaries enable richer data sharing and tighter coordination between systems, but increase coupling and make independent evolution harder. The architect must make these trade-offs explicitly, in full awareness of their downstream consequences.
The Architect's Role in Package Selection
When the organization is evaluating packaged solutions — an e-commerce platform, an ERP system, a CRM — the architect's involvement is defined by the boundaries of the architectural role itself.
The architect's involvement in package selection includes:
- Package selection through standards, guidelines, and cost/benefit analysis — evaluating options against the architectural requirements and organizational constraints.
- Recommendation of package customization approaches — identifying where standard configuration is sufficient and where custom development is necessary to meet requirements.
It does not include:
- Focus on the internal workings of software packages — the architect is concerned with external interfaces, not implementation details.
- Detailed integration specifications or package implementation design — those are the responsibility of the development and implementation teams.
This boundary on the architect's role is itself an application of separation of concerns. The architect operates at the level of interfaces and trade-offs. The implementation team operates at the level of internal workings and detailed specifications. Keeping these responsibilities separate produces better outcomes in both domains.
Architect Determines Boundaries
The final principle of this lesson is the most fundamental: the architect determines boundaries. The level of granularity at which boundaries are drawn depends entirely on what the architect needs to reason about at a given stage of the process.
If the architect is evaluating overall system performance, she draws the boundary at the system level and treats each major component as a black box. Internal implementation details are irrelevant at this level of abstraction — what matters is the behavior of each component at its interface.
If the architect is evaluating how two specific components interact, she draws the boundary between them and examines the interface in detail — what data is exchanged, at what frequency, under what error conditions, and with what latency requirements.
The ability to move fluidly between levels of abstraction — to zoom out to system-level reasoning and zoom in to component-level detail without losing coherence — is the defining skill of the effective e-business architect. Separation of concerns is the method that makes this possible.