Perspectives Impact Architectural Requirements

In e-business, functionality is the minimum price of admission. A site that works is not a competitive advantage — it is a baseline expectation. The question that determines whether users return is not whether the site functions, but whether it performs well enough, feels fast enough, and delivers enough value to compete with every alternative available to the user at that moment.

This is the lens through which an architect must evaluate every design decision: not "does this work?" but "does this meet the performance and experience criteria that stakeholders have defined?" Those two questions produce very different architectures.

Performance metrics differ fundamentally across industries, and the architect must understand the metrics that matter to each stakeholder group before prescribing a solution.

Consider an automobile manufacturer. Their process building blocks are measured by:

1. the number of cars produced,
2. the number of defective parts per car,
3. the number of employee accidents,
4. the number of cars sold.

These metrics are output-oriented and largely internal. The customer does not see them directly — they see the result.

E-commerce performance metrics are different in character. They are interaction-oriented, customer-visible, and measured in real time:

1. the number of visits to the site,
2. the number of clicks required to complete a customer-driven process,
3. site availability — how often the site is up vs. down,
4. the conversion rate — visitors vs. buyers,
5. availability of help during customer-driven processes,
6. the ratio of new customers to returning customers.

In 2026, this list extends further. Modern e-commerce platforms are evaluated against Core Web Vitals — Google's framework for measuring real-world page experience. The three primary signals are Largest Contentful Paint (LCP, which measures loading performance), Cumulative Layout Shift (CLS, which measures visual stability), and Interaction to Next Paint (INP, which measures responsiveness). These metrics directly affect both user experience and organic search ranking, which means the architect's platform decisions have measurable SEO consequences.

Beyond Core Web Vitals, the metrics that stakeholders care about in 2026 include customer acquisition cost (CAC), customer lifetime value (CLV), cart abandonment rate, and Net Promoter Score (NPS). Each of these is shaped by architectural decisions — page load time, checkout flow complexity, personalization capability, and system availability all drive these numbers. The architect who does not understand these metrics cannot design a system that improves them.

Architecture is about performance against stakeholder-defined criteria. The architect does not define what success looks like — stakeholders do. The architect's job is to understand those criteria precisely enough to translate them into technical requirements, and then to design a system that demonstrably meets them.

This requires the architect to view the problem space from the perspective of each stakeholder. Those perspectives will vary, sometimes significantly, depending on the relationship each stakeholder maintains with the business. A CFO defining success in terms of cost per transaction will arrive at different requirements than a CMO defining success in terms of customer retention. A fulfillment operations manager concerned with inventory accuracy will have different priorities than a product manager focused on feature velocity. The architect must hold all of these perspectives simultaneously and produce an architecture that satisfies them without creating irreconcilable conflicts.

Successful architecture must not only meet functional requirements — it must also differentiate itself from alternative solutions. A site that does what every competitor's site does, at the same speed, with the same experience, provides no competitive advantage. The architect must understand where differentiation is possible and worth investing in, and where commodity solutions are sufficient.

The distinction between an architect and a general contractor clarifies what stakeholder-driven design actually means in practice.

A general contractor builds houses that meet the needs of most buyers. The result is often a coherent enough structure, but one that reflects a general-purpose solution set rather than a specific client's priorities. The styles may not cohere. The trade-offs made during construction reflect the contractor's experience of what most people want, not what this client needs.

An architect creates a best-fit solution for a specific client. The components used may be entirely standard — there is no requirement that a bespoke solution use bespoke parts — but they are selected to work together in a specific environment, against specific performance objectives, for a specific set of stakeholders. The result is a system that fits the client's context rather than approximating it.

Consider a simpler version of the same problem. You need a house with four bedrooms. Two houses meet that requirement: a ranch and a bi-level. Both have four bedrooms. How do you choose? The functional requirement is identical, so the decision comes down to perceived characteristics — how each house fits the way you actually live. One stakeholder values single-floor accessibility. Another values the separation of living and sleeping spaces. Neither is wrong. The architect's job is to understand which characteristics matter to this client, weight them appropriately, and recommend accordingly.

The same dynamic plays out at enterprise scale. When an organization is evaluating e-commerce platforms, the functional checklist — catalog management, checkout, payment processing, order management — may be identical across three finalists. The architectural decision comes down to how each platform fits the organization's specific environment: their existing ERP integrations, their development team's capabilities, their traffic patterns, their compliance requirements, and their three-year growth trajectory.

Business architecture provides the formal framework within which stakeholder perspectives are reconciled and translated into executable requirements. The Business Architecture Working Group of the Object Management Group (OMG) defined it in 2010 as a model of the enterprise that provides a common understanding of the organization and is used to align strategic objectives with the requirements of execution. According to the OMG, this blueprint describes the enterprise in terms of its governance structure, business processes, and business information.

Business architecture is the bridge between enterprise strategy on one side and business functionality on the other. It is the layer that makes it possible to evaluate a proposed technical solution against a strategic objective — to ask not just "does this feature work?" but "does this feature serve the business model we are trying to build?"

Modern enterprise architecture frameworks extend this thinking further. TOGAF (The Open Group Architecture Framework) provides a structured method for developing and managing enterprise architectures through its Architecture Development Method (ADM), which explicitly addresses stakeholder concerns at each phase of the architecture lifecycle. The Zachman Framework organizes architectural artifacts by both the stakeholder perspective (executive, business manager, architect, developer, subcontractor) and the interrogative dimension (what, how, where, who, when, why), making stakeholder perspective a first-class organizing principle of the entire framework.

Both frameworks reflect the same underlying insight: architecture that does not account for stakeholder perspective will not be adopted, regardless of its technical merit.

Amazon's evolution from online bookstore to the world's largest e-commerce and cloud computing platform is the most instructive case study in stakeholder-driven architectural decision-making available.

When Amazon launched in 1995, its stakeholder set was simple: book buyers who wanted selection, price, and convenience. Every architectural decision — the catalog structure, the recommendation engine, the one-click checkout — was made in service of those three criteria as perceived by that stakeholder group.

As Amazon grew, its stakeholder set multiplied. Third-party sellers needed a marketplace infrastructure. Enterprise customers needed cloud computing (AWS, launched in 2006). Prime subscribers needed fast delivery and streaming media. Alexa users needed voice commerce. Healthcare customers needed pharmacy services. Advertisers needed a targeting platform that could compete with Google and Meta.

Each of these stakeholder groups defined success differently. The architectural challenge Amazon faced — and continues to face — is maintaining differentiation within each service offering while operating them on shared infrastructure. AWS does not compete with Prime. Marketplace does not cannibalize first-party retail. Alexa creates a commerce channel that reinforces Prime loyalty. The architecture holds these separate stakeholder experiences together without allowing them to collapse into a single undifferentiated mass.

The lesson for the e-business architect is not to build Amazon — it is to understand that stakeholder perspective defines what differentiation means, and that differentiation is the mechanism by which architecture creates competitive value.

One of the most important judgments an architect makes is knowing where the line between good and good enough exists. It is easy to over-engineer a solution — to invest architectural complexity in areas where a simpler approach would satisfy the stakeholder's actual criteria. It is equally easy to under-engineer — to defer complexity that will become expensive to address later.

The architect's guide in making this judgment is always the stakeholder-defined criteria. If a stakeholder requires 99.9% uptime and the current architecture delivers 99.95%, adding further redundancy has diminishing returns. If a stakeholder requires sub-two-second page loads and the current architecture delivers 2.3 seconds, the gap is worth closing. If personalization is not a stated requirement, building a recommendation engine is over-engineering. If it is a stated requirement, building a rule-based system when a machine learning approach would significantly outperform it is under-engineering.

The architect's responsibility is to identify and implement the things that will increase the probability of meeting specified objectives — not to build the most technically sophisticated system possible, and not to cut corners that will create downstream costs. That judgment, applied consistently across every architectural decision, is what separates architecture from engineering.