Architects, Engineers, and Developers

Few municipalities would allow a general contractor to build a commercial building without a licensed architect on the job. The reason is not bureaucratic — it is structural. The architect is required to produce blueprints that demonstrate the building's conformance to local codes, verify its structural integrity, and ensure that the construction meets quality standards. The general contractor may perform every hour of physical work, but the architect is accountable for the design that governs that work.

In e-engineering, the same relationship applies. The architect provides the blueprints of the commercial enterprise — specifying the building blocks, the interfaces between them, the standards they must conform to, and the quality criteria they must meet. The developer or engineer provides the implementation according to that specification. The work is the developer's. The design is the architect's. When that distinction is respected, the resulting system has integrity. When it is collapsed — when a developer makes architectural decisions without the perspective or accountability of an architect — the consequences are predictable and expensive.

A retailer decided to build their e-commerce platform around a specific technology stack because one of their web developers was familiar and experienced with it. Both the retailer and the developer believed this choice would accelerate time-to-market and reduce development cost by leveraging existing expertise. The reasoning was not unreasonable on its face — developer familiarity does reduce ramp-up time, and speed-to-market is a legitimate business priority.

What neither the retailer nor the developer considered was the ongoing effort required to manage and extend the platform once it was live. No tools existed to interface with the retailer's product data system. No tooling could be found to work with the commerce engine to make product data refresh practical. The platform that had been selected for its developer familiarity had no integration story for the retailer's actual business operations.

The retailer was left with three choices:

1. Continue using a manual process to update product data on the site — accepting the operational cost and error rate that manual processes produce at scale.
2. Develop a custom integration tool — an investment that deepens lock-in to the chosen architecture and creates a long-term maintenance burden.
3. Start over — discarding the investment already made and rebuilding on a platform that had been evaluated architecturally rather than selected by developer preference.

None of these choices is one you would want to present to a client. The answer is to prevent the dilemma from occurring through solid up-front architecture — evaluating platforms against business requirements, integration needs, and long-term extensibility before a line of code is written.

This scenario plays out in modern e-commerce with the same frequency and the same consequences. A developer familiar with a particular headless commerce platform — Shopify Hydrogen, Commerce.js, or similar — advocates for it based on personal experience. The retailer approves, optimizing for speed. Six months later, the team discovers that the platform has no standard connectors for their ERP system, that product catalog updates require manual CSV imports, and that the vendor's API rate limits make real-time inventory synchronization impractical. The three choices are identical to the ones the retailer faced in the original case study — because the root cause is identical: a developer made an architectural decision without architectural analysis.

The distinction between the architect and the developer is not a matter of seniority or technical skill — it is a matter of perspective and accountability. Both roles require deep technical knowledge. What differs is the level at which that knowledge is applied and the set of concerns each role is responsible for.

These roles are not mutually exclusive. The same individual may function as architect during the design phase of a project and as developer during implementation — particularly in smaller organizations or on smaller-scope engagements where the team does not have the scale to support dedicated role separation. This is the "wearing many hats" reality of e-business development in practice.

What matters is not that the roles are held by different people, but that both perspectives are applied at the appropriate stages. An individual who switches between architectural and developer thinking at the right moments — who holds the system view during design and the implementation view during build — can cover both effectively. An individual who applies only the developer perspective throughout, never stepping back to evaluate the system as a whole from the outside, cannot.

Although architecture is not about designing systems, it leads directly to design criteria. The architect does not produce the detailed design — that is the developer's and engineer's work — but the architect produces the constraints and standards within which design must occur.

In modern e-business architecture, these outputs take several concrete forms. API contracts — specified using OpenAPI or GraphQL schemas — define the interfaces between services precisely enough that development teams can build against them independently and in parallel. Architecture Decision Records (ADRs) document the reasoning behind key architectural choices, so that developers who encounter a constraint understand why it exists and what would be required to change it. Infrastructure-as-code templates — written in Terraform or Pulumi — define the cloud infrastructure within which development teams deploy, ensuring that the operational environment matches the architectural specification. Data contracts define the schema and semantics of data exchanged between systems, preventing the integration failures that occur when producer and consumer teams make different assumptions about data structure.

Together, these artifacts constitute the architect's design contribution — not a detailed system design, but a precise specification of the boundaries, interfaces, and standards within which detailed design must occur. The architect supports design efforts by providing these artifacts and by remaining available to resolve questions that arise when implementation encounters the edge cases that specification always leaves open.

In an e-engineering project, it is the architect who develops the metrics, requirements, and approaches to solutions. The architect maintains the overall view of the e-business initiative — the view that no individual development team can hold, because each team sees only the component it is responsible for.

The result of the architectural process is a blueprint and a bill of materials that conform to standards and best practices. In traditional construction, the blueprint is a set of drawings and the bill of materials is a list of components. In e-business architecture, the equivalent outputs are:

• Architecture diagrams — system context diagrams, component diagrams, deployment diagrams — that show how the system is organized and how its parts relate to each other and to external systems.
• Architecture Decision Records that document the key choices made and the reasoning behind them.
• API specifications that define the interfaces between components.
• Infrastructure-as-code that defines the deployment environment.
• Data models and data contracts that define the information architecture.
• Non-functional requirements — availability targets, performance budgets, security controls, compliance requirements, that constrain the implementation without dictating it.

This set of artifacts is the architect's deliverable. It is what makes the difference between a development team that builds confidently toward a coherent outcome and a development team that makes local decisions that collectively produce a system no one designed and no one fully understands. The architect who produces these artifacts clearly and maintains them as the project evolves provides the insurance that the retailer in the case study lacked — the insurance that the platform being built will be manageable, extensible, and integrated with the business it is meant to serve.