Platform Strategy and Commerce Technology Architecture

Introduction

An e-commerce venture is not merely a website with a payment button. It is a socio-technical system that connects customers, products, prices, inventory, payments, fulfillment, marketing, analytics, employees, suppliers, and regulators. The technology architecture determines how these elements interact and therefore affects speed to market, customer experience, operating cost, resilience, data ownership, and strategic flexibility.

A platform decision is consequently a strategic decision. An entrepreneur choosing a hosted storefront, an open-source system, a marketplace, or a headless architecture is also choosing a governance model, a pattern of dependence on vendors, a level of technical responsibility, and a likely path for future growth. The central managerial question is not “Which platform is best?” but “Which architecture best fits the venture’s strategy, capabilities, constraints, and expected evolution?”

This chapter compares the principal commerce models and develops a structured approach to build-versus-buy decisions, integration design, APIs, scalability, interoperability, technical debt, and total cost of ownership (TCO).

Learning Objectives

By the end of this chapter, you should be able to:

1. Compare hosted, open-source, marketplace, headless, and composable commerce models.
2. Distinguish a commerce platform from a channel, integration layer, and system of record.
3. Evaluate build-versus-buy decisions using strategic, technical, financial, and organizational criteria.
4. Explain APIs, webhooks, data models, interoperability, integration patterns, and failure handling.
5. Assess scalability, resilience, security, technical debt, vendor lock-in, and governance.
6. Estimate and interpret the total cost of ownership of alternative architectures.
7. Recommend an architecture using explicit assumptions and evidence rather than technological fashion.

1. Commerce Architecture as a Strategic Capability

A commerce architecture is the arrangement of applications, data, infrastructure, interfaces, people, and operating processes that support commercial transactions. It includes both customer-facing components and internal capabilities.

A useful distinction is between four architectural layers:

Architecture should be evaluated against business requirements such as product complexity, transaction volume, geographic scope, regulatory exposure, customization, channel diversity, and growth uncertainty. A small business selling standardized products may benefit from a managed platform. A multinational retailer with multiple brands, markets, and channels may require a more modular design. Neither conclusion follows from size alone; complexity and strategic differentiation matter more than revenue by itself.

1.1 Platform, channel, and system of record

A platform is a technological foundation that provides reusable capabilities. A channel is a route through which customers discover or purchase products, such as a website, mobile application, social-commerce interface, or third-party marketplace. A system of record is the authoritative source for a particular class of data. For example, an ERP may be authoritative for financial accounting, while a product information management system may own enriched product attributes.

Confusing these roles causes duplication and inconsistent data. If price is independently edited in a storefront, marketplace, and spreadsheet, discrepancies become likely. Architecture therefore requires explicit ownership rules: who can create, modify, approve, and publish each type of data?

2. Principal Commerce Models

2.1 Hosted or software-as-a-service commerce

A hosted platform provides the application and usually manages infrastructure, upgrades, security patches, availability, and core operational tooling. The merchant configures the storefront, catalog, payment methods, and workflows within platform constraints.

Advantages include rapid deployment, predictable administration, lower initial technical burden, managed security controls, and access to an ecosystem of extensions. Hosted platforms are attractive when speed, standardization, and managerial focus are more valuable than deep control.

Limitations include recurring subscription and transaction fees, dependence on the provider’s roadmap, restrictions on data models or checkout behavior, and possible vendor lock-in. A platform may be highly configurable without being genuinely customizable: configuration changes supported by the vendor are not equivalent to changing the underlying software.

Hosted commerce is often appropriate for an early-stage venture testing product-market fit, provided that data can be exported and integrations are designed to preserve future options.

2.2 Open-source commerce

Open-source commerce software makes source code available under a license that permits specified forms of use, modification, and redistribution. The merchant may self-host it or purchase managed hosting and professional support.

Open source offers control over code, deployment, data structures, and extensions. It can be useful when a firm has distinctive workflows, unusual product configurations, or a capable engineering team. However, “open source” does not mean “free.” The firm remains responsible, directly or indirectly, for hosting, upgrades, security, monitoring, backups, compatibility, and incident response.

Licensing must be examined carefully. Different licenses impose different obligations concerning distribution, modification, attribution, and proprietary extensions. A legal review is appropriate where software is modified or embedded in a commercial product.

2.3 Marketplace commerce

A marketplace is a third-party environment in which multiple sellers offer products to customers. Examples include general marketplaces, specialist platforms, app stores, and business-to-business exchanges. A marketplace provides demand access, search, trust mechanisms, payment infrastructure, and sometimes fulfillment.

Its benefits include traffic acquisition, customer trust, standardized listing tools, and potential operational services. Its risks include commissions, intense price comparison, limited customer-data access, policy dependence, counterfeit or unauthorized-seller exposure, and weak control over the customer relationship. Marketplace participation should therefore be treated as a channel strategy, not necessarily as a substitute for owning a direct customer relationship.

An omnichannel venture may use a marketplace for reach while retaining a direct storefront for brand experience, loyalty, richer data, and differentiated service.

2.4 Headless commerce

In a headless architecture, the presentation layer is separated from the commerce engine. A web application, mobile app, digital signage system, or other client consumes commerce capabilities through APIs rather than relying on a platform’s built-in storefront templates.

Headless design can support distinctive experiences, multiple channels, experimentation, and independent release cycles. It is especially relevant when the experience itself is strategically differentiated or when a business must publish commerce capabilities across many interfaces.

The trade-off is complexity. The firm must design and operate the frontend, content delivery, search, caching, authentication flows, observability, and integration behavior. Headless does not automatically improve performance or flexibility; poor API design, excessive network calls, or fragmented ownership can make the customer experience slower and more fragile.

2.5 Composable commerce

Composable commerce assembles specialized services—such as search, content management, promotions, checkout, tax, payments, and order management—through APIs and integration mechanisms. The architecture is modular rather than centered on one monolithic product.

Composable design can allow best-of-breed selection, independent replacement of components, and closer alignment between capabilities and strategic needs. It may reduce dependence on one supplier but can increase coordination costs. Each component has its own contract, release cycle, security model, pricing, and failure modes. The enterprise must provide architecture governance, identity management, observability, data consistency, and vendor coordination.

Headless and composable are related but not identical. Headless primarily describes separation between presentation and commerce logic. Composable describes assembly of multiple business capabilities. A system can be headless but largely monolithic, or composable while offering a conventional storefront.

2.6 Comparative assessment

These categories are not mutually exclusive. A merchant may use a hosted commerce engine, a headless frontend, marketplace channels, and selected external services. The relevant unit of analysis is the total operating architecture.

3. Build-versus-Buy as a Strategic Decision

Build-versus-buy is often presented as a cost comparison, but it is fundamentally a capability decision. A firm should consider whether a function is strategically differentiating, whether it possesses the skills to operate it, and whether the market supplies a reliable solution.

A practical evaluation uses six questions:

1. Strategic uniqueness: Does the capability create a defensible customer or operating advantage?
2. Availability: Are mature, interoperable products available?
3. Speed: How quickly is the capability needed?
4. Risk: What are the security, regulatory, continuity, and failure consequences?
5. Capability: Can the organization maintain the solution over its full life?
6. Reversibility: How difficult will it be to replace or migrate the choice?

The answer is frequently “buy the commodity, build the differentiator, and integrate carefully.” Payment processing, tax calculation, email delivery, and basic search are often purchased because specialist providers achieve scale and compliance. Distinctive product configuration, workflow, or customer experience may justify internal development.

A hybrid option is often superior to either extreme: purchase a core platform, configure standard capabilities, extend only where necessary, and isolate custom logic behind stable interfaces.

3.1 TCO model

A simple annualized total cost of ownership model is:

Here, C₀ is initial implementation and migration cost; S_t is subscription, license, or hosting cost in year t; I_t is integration and extension cost; O_t is operations, support, and staffing cost; R_t is risk, security, compliance, and expected remediation cost; D_t is data, training, and change-management cost; and V_n is residual value or recoverable asset value at the end of period n. The model assumes costs are measured on a consistent time basis. For investment comparison, future costs should normally be discounted to present value.

If annual costs are expected to remain constant and discounting is ignored, the average annual cost is:

This is a descriptive comparison, not a complete investment appraisal. A more rigorous analysis includes discounting, probability-weighted risk, switching costs, and the value of faster market entry.

Worked example: comparing two architectures

An entrepreneur compares a hosted solution with an open-source solution over three years.

Hosted TCO is $18,000 + $36,000 + $15,000 + $21,000 + $6,000 + $5,000 − $2,000 = $99,000. Open-source TCO is $45,000 + $18,000 + $30,000 + $54,000 + $12,000 + $8,000 − $8,000 = $159,000. In this illustrative case, the hosted option is less expensive over three years despite higher recurring fees. The result would change if the open-source platform generated substantial strategic value, avoided expensive platform constraints, or supported revenues not achievable through the hosted option.

4. Integration Architecture and Interoperability

Commerce systems rarely operate alone. Common integrations include payment service providers, tax engines, fraud detection, inventory, fulfillment, ERP, CRM, customer-service platforms, email and marketing automation, analytics, search, identity, and marketplaces.

4.1 APIs and contracts

An application programming interface (API) is a defined way for software components to request data or actions. A good API contract specifies resources, operations, authentication, authorization, data formats, validation rules, error responses, rate limits, versioning, and service-level expectations.

REST APIs commonly use HTTP methods such as GET, POST, PUT, PATCH, and DELETE. GraphQL allows clients to request selected fields through a typed query model. Event-driven interfaces publish occurrences such as OrderPlaced or PaymentAuthorized. The choice should follow the interaction need rather than fashion.

A synchronous request is useful when a response is required immediately, such as validating a payment authorization. An asynchronous message is useful for work that can complete later, such as sending an order to a warehouse. Reliable systems must address retries, duplicate messages, timeouts, partial failure, and reconciliation.

Idempotency means that repeating an operation has the same business effect as performing it once. It is essential for payment and order APIs because a network timeout can leave the client uncertain whether an operation succeeded. An idempotency key allows the server to recognize a repeated request and return the original result rather than creating a second order or charge.

4.2 Data interoperability

Interoperability is more than the ability to connect technically. It includes:

• Syntactic interoperability: systems can exchange data in agreed formats.
• Semantic interoperability: exchanged fields have the same meaning.
• Process interoperability: systems agree on workflow states and responsibilities.
• Organizational interoperability: policies, ownership, and incentives support cooperation.

For example, “available inventory” may mean physical stock, sellable stock after safety reserves, or stock available in a particular channel. Without semantic agreement, an apparently successful integration can produce incorrect promises to customers.

Canonical data models can reduce translation between systems, but excessive centralization may become a bottleneck. A practical approach defines canonical concepts—such as Product, Customer, Order, Payment, and Shipment—while allowing bounded contexts to retain local representations. Mapping documents, data dictionaries, and contract tests are important governance artifacts.

4.3 Integration patterns

Point-to-point integration is quick for a small number of systems but grows difficult to govern as connections multiply. An integration platform or message broker can centralize routing, transformation, monitoring, and retry behavior. However, middleware itself becomes a critical dependency and must be designed to avoid becoming an opaque “spaghetti” layer.

Useful patterns include:

• Request-response: immediate interaction with a defined response.
• Publish-subscribe: one event is consumed by multiple interested systems.
• Queue-based processing: work is buffered and handled asynchronously.
• Batch exchange: records are transferred periodically, useful where real-time data is unnecessary.
• Change data capture: changes are propagated from a source system, subject to data governance and consistency constraints.

The architecture should distinguish business events from technical events. “Order confirmed” is a business event; “database row updated” is a technical event. Business events are generally more stable and meaningful to downstream consumers.

5. Scalability, Reliability, and Performance

Scalability is the ability to handle increased demand while maintaining acceptable service levels. Vertical scaling increases the capacity of an existing component; horizontal scaling adds instances. Stateless application services are usually easier to scale horizontally, while databases and inventory systems may require more careful consistency design.

Capacity planning should begin with workload assumptions: requests per second, average and peak order rates, catalog size, concurrent users, integration latency, and storage growth. Average demand can conceal extreme peaks caused by campaigns, product launches, or seasonal events.

Reliability is not simply a property of individual components. A system with many dependencies may fail when any critical dependency fails. Useful design practices include caching, queues, timeouts, circuit breakers, graceful degradation, backups, disaster recovery exercises, and clear recovery objectives.

Two governance measures are particularly important:

• Recovery time objective (RTO): maximum acceptable time to restore service.
• Recovery point objective (RPO): maximum acceptable amount of data loss measured in time.

Performance should be evaluated from the customer’s perspective. A fast homepage does not compensate for a slow checkout, inaccurate inventory, or delayed order confirmation. Observability should connect technical metrics—latency, error rate, saturation, queue depth—with business metrics such as checkout completion, payment failures, and order-processing delay.

6. Technical Debt and Architectural Governance

Technical debt is the future cost created by expedient technical choices. Some debt is deliberate and rational—for example, launching with a simple integration to test demand. Unmanaged debt becomes harmful when the organization no longer understands its consequences or cannot repay it safely.

Commerce-specific sources include excessive platform customization, undocumented APIs, duplicated customer records, obsolete plugins, unsupported versions, hard-coded tax rules, fragile data synchronization, and manual spreadsheet workarounds. Debt increases change lead time and incident risk.

A useful debt register records the issue, cause, affected capability, risk, estimated remediation effort, and decision owner. Debt should be prioritized according to business impact rather than aesthetic preference. A temporary workaround that threatens duplicate payments has greater urgency than a minor code-style inconsistency.

Architecture governance should establish:

• ownership of business data and interfaces;
• approved integration and authentication patterns;
• versioning and deprecation policies;
• security and privacy requirements;
• testing and release controls;
• monitoring and incident procedures;
• vendor exit and data-export requirements.

7. Security, Privacy, Ethics, and Regulation

Commerce architecture handles identity, behavioral data, payment information, addresses, and sometimes sensitive attributes. Security must therefore be designed into the architecture rather than added after launch.

Important controls include least-privilege access, strong authentication, encryption in transit and at rest where appropriate, secrets management, dependency patching, logging, vulnerability management, backup protection, and separation of development and production environments. Payment tokenization can reduce exposure to raw card data, but it does not eliminate the merchant’s broader security obligations.

Privacy governance requires purpose limitation, data minimization, retention rules, transparency, lawful processing, access and deletion procedures, and careful treatment of third-party tracking. Data should not be collected merely because a platform makes collection easy.

Ethical risks include dark patterns in consent or cancellation, discriminatory personalization, opaque ranking, manipulative scarcity claims, surveillance-oriented analytics, and automated decisions that disadvantage groups. Artificial intelligence may improve search, recommendations, forecasting, and service automation, but models require governance for data quality, explainability, bias, security, human escalation, and performance monitoring. Generative AI should not be allowed to invent product claims, legal terms, or safety information.

8. Contemporary Architectural Direction

Several developments are influencing platform strategy. Cloud services make elastic infrastructure and managed capabilities more accessible. API-first and event-driven designs support channel expansion. Edge delivery and caching can improve global performance. Embedded finance and social commerce shorten the path from discovery to purchase. Product information and order management are increasingly treated as shared enterprise capabilities rather than website features.

Yet architectural decentralization is not automatically progress. The organization must possess the capability to operate the resulting network of vendors and services. A modular architecture with weak governance can be less resilient than a well-managed integrated platform. Strategic maturity is shown by selecting appropriate modularity, not maximum modularity.

9. Illustrative Case: Northstar Outdoor Equipment

Background

Northstar Outdoor Equipment is a fictional mid-sized retailer selling camping equipment through 180 stores and a growing online channel. It has a legacy ERP, a warehouse system, a loyalty database, and a basic hosted storefront. Online revenue is increasing, but product information is inconsistent and inventory promises are unreliable.

Problem

The leadership team proposes replacing the hosted platform with a fully composable architecture. The technology team argues that the current platform cannot support richer product configuration and international expansion. Finance is concerned about cost, while operations is concerned about order duplication and inventory accuracy.

Analysis

The firm identifies three distinct needs: improved product content, reliable inventory visibility, and a more flexible customer experience. Only the third necessarily requires a new storefront architecture. A capability assessment finds that Northstar has strong merchandising expertise but limited experience operating distributed services.

A TCO analysis shows that a full composable replacement would require substantial migration, integration, observability, and specialist staffing. A staged alternative would retain the hosted commerce core, introduce a product information management capability, improve inventory synchronization, and implement selected APIs for mobile and international channels. This preserves speed while testing whether headless delivery creates measurable customer value.

Approach and solution

Northstar adopts a hybrid roadmap:

1. Define ownership for product, inventory, price, customer, order, and payment data.
2. Establish an API layer for catalog and inventory queries.
3. Introduce event-driven order notifications with idempotent processing.
4. Improve product information governance before expanding channels.
5. Pilot a headless experience for one high-value product category.
6. Measure conversion, page performance, support contacts, stock accuracy, and operating cost.
7. Reassess platform replacement only after evidence from the pilot.

Outcome

The staged approach reduces immediate migration risk and exposes the actual bottleneck: product-data quality rather than storefront rendering. The pilot produces useful evidence about experience-led design without forcing the business to operate every commerce component independently.

Learning points

First, architecture should solve the limiting business capability, not the most visible technical dissatisfaction. Second, a hybrid architecture can be a deliberate strategy rather than an incomplete transition. Third, platform choices should include exit options, operational capability, and data governance. Finally, composability creates value only when the organization can coordinate the components it composes.

10. A Decision Framework for Entrepreneurs

A disciplined platform assessment can proceed through the following sequence:

1. Clarify strategy: identify target customers, value proposition, channels, markets, and differentiation.
2. Map capabilities: distinguish commodity functions from strategically distinctive functions.
3. Document constraints: budget, talent, compliance, launch date, legacy systems, and risk tolerance.
4. Define quality attributes: availability, performance, security, portability, maintainability, and scalability.
5. Model alternatives: include hosted, open-source, marketplace, headless, composable, and hybrid options where relevant.
6. Estimate full-life cost: include people, integrations, migration, support, risk, and exit costs.
7. Test interoperability: examine APIs, data export, webhooks, versioning, limits, and authentication.
8. Run a bounded pilot: validate the riskiest assumption with measurable outcomes.
9. Plan governance: assign ownership, document contracts, and establish monitoring and incident response.
10. Review periodically: architecture should evolve with evidence, strategy, and organizational capability.

A decision matrix can weight criteria according to strategic importance. For example, a regulated enterprise may assign greater weight to security and auditability, whereas a start-up may assign greater weight to speed and reversibility. Scores should be accompanied by evidence and confidence levels; false precision is worse than transparent uncertainty.

Challenges and Limitations

No architecture eliminates trade-offs. Hosted systems can constrain differentiation; open-source systems can consume scarce engineering capacity; marketplaces can weaken direct relationships; headless systems can increase operational complexity; and composable systems can distribute responsibility across vendors. TCO estimates are uncertain because traffic, staffing, incidents, and strategic requirements change.

Architecture frameworks can also become politically contested. Teams may prefer technologies that improve their status or skill portfolios, while executives may underestimate operating costs. Independent review, pilot evidence, explicit assumptions, and post-implementation evaluation reduce these biases.

Chapter Summary

Commerce technology architecture is a strategic arrangement of experience layers, commerce services, enterprise systems, data, integrations, and operating capabilities. Hosted platforms emphasize speed and managed operations; open-source platforms emphasize control; marketplaces provide reach but limit customer ownership; headless architectures separate experience from commerce logic; and composable architectures assemble specialized capabilities through interfaces.

Build-versus-buy decisions should consider strategic differentiation, availability, speed, risk, internal capability, and reversibility. Total cost of ownership includes implementation, subscriptions, integrations, operations, security, training, migration, risk, and residual value—not merely license price. APIs, events, queues, canonical concepts, idempotency, versioning, and reconciliation are central to reliable interoperability.

Scalability and resilience require attention to peaks, dependencies, recovery objectives, observability, and graceful degradation. Technical debt should be managed as a portfolio of business risks. Security, privacy, ethical design, regulatory compliance, and AI governance are architectural responsibilities. The most effective strategy is often staged and hybrid: buy mature commodity capabilities, build genuine differentiators, preserve data portability, and increase modularity only when organizational capability justifies it.

Key Terms

API: A defined interface through which software components request data or actions.

Build-versus-buy: Evaluation of whether a capability should be developed internally or acquired externally.

Canonical data model: A shared representation of important business concepts used to support integration.

Composable commerce: Assembly of specialized commerce capabilities into a modular architecture.

Headless commerce: Separation of the customer-facing presentation layer from the commerce engine.

Hosted commerce: Commerce software operated and maintained by an external provider.

Idempotency: Property whereby repeating an operation does not create an additional business effect.

Integration: Connection and coordination of systems, data, and processes.

Interoperability: Ability of systems and organizations to exchange and correctly use information.

Marketplace: A third-party environment where multiple sellers offer products to customers.

Open-source commerce: Commerce software whose source code is available under an applicable open-source license.

RPO: Recovery point objective; the maximum acceptable period of data loss.

RTO: Recovery time objective; the maximum acceptable time to restore service.

System of record: Authoritative source for a defined category of data.

Technical debt: Future cost or risk created by expedient technical choices.

Total cost of ownership: Full cost of acquiring, operating, maintaining, and retiring a solution.

Vendor lock-in: Difficulty or cost associated with changing suppliers or migrating away from a platform.

Webhook: An event-triggered HTTP notification sent from one system to another.

Review Questions

Short Answer Questions

1. What is the difference between a commerce platform and a commerce channel?
2. State two advantages and two limitations of hosted commerce.
3. Why is idempotency important in payment and order processing?
4. Distinguish headless commerce from composable commerce.
5. What costs should be included in a TCO estimate?

Long Answer Questions

1. Compare hosted, open-source, marketplace, headless, and composable commerce models for a growing direct-to-consumer firm.
2. Explain how data ownership and semantic interoperability affect commerce integration.
3. Develop a build-versus-buy framework for deciding whether to develop a recommendation engine internally.
4. Discuss how technical debt can emerge in a multi-channel commerce architecture and how it should be governed.
5. Explain why security, privacy, ethics, and AI governance should be treated as architecture concerns.

Analytical / Application Questions

1. A start-up has limited engineering capacity, a standardized product range, and a six-week launch target. Recommend an architecture and justify it using strategic fit, TCO, risk, and reversibility.
2. A retailer’s marketplace sales are growing rapidly, but it has little customer-data access and frequent policy changes. Analyze the strategic benefits and risks of continuing marketplace dependence, and propose a channel portfolio.
3. Using the TCO framework in this chapter, construct a three-year comparison between a hosted and an open-source solution for a hypothetical retailer. State assumptions, include operational and risk costs, and explain why the cheaper option may not be the superior strategic choice.

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes headless commerce?

A. It is available only under an open-source license.

B. It separates the presentation layer from the commerce engine.

C. It eliminates the need for APIs.

D. It requires selling through a third-party marketplace.

Correct Answer: B. It separates the presentation layer from the commerce engine.

Question 2

Which cost is most likely to be omitted in an overly narrow platform comparison?

A. The color of the storefront logo

B. The number of product photographs

C. Operations, support, security, and migration costs

D. The merchant’s preferred payment-card brand

Correct Answer: C. Operations, support, security, and migration costs

Question 3

What is the principal purpose of an idempotency key in an order API?

A. To increase product image resolution

B. To prevent a repeated request from creating a duplicate business effect

C. To replace customer authentication

D. To compress database storage

Correct Answer: B. To prevent a repeated request from creating a duplicate business effect

Question 4

Which model generally provides immediate access to an external audience but less control over the customer relationship?

A. Marketplace commerce

B. Self-hosted open-source commerce

C. Internal ERP commerce

D. Private product-information management

Correct Answer: A. Marketplace commerce

Question 5

In the chapter’s illustrative TCO example, which option had the lower three-year TCO?

A. The hosted solution

B. The open-source solution

C. Both had exactly the same TCO

D. The marketplace solution

Correct Answer: A. The hosted solution

Question 6

What is semantic interoperability concerned with?

A. Whether systems use the same physical server

B. Whether exchanged data has the same meaning

C. Whether all systems use identical programming languages

D. Whether a website uses a mobile layout

Correct Answer: B. Whether exchanged data has the same meaning

Question 7

Which statement best describes composable commerce?

A. A single fixed storefront with no external services

B. A marketplace that prohibits direct sales

C. An architecture assembled from specialized capabilities connected through interfaces

D. A licensing model that guarantees zero operating cost

Correct Answer: C. An architecture assembled from specialized capabilities connected through interfaces

Question 8

What does RTO measure?

A. The maximum acceptable time to restore service

B. The maximum number of products in a catalog

C. The average time required to authorize a payment

D. The percentage of revenue from online channels

Correct Answer: A. The maximum acceptable time to restore service

Question 9

Which is an example of deliberate but potentially manageable technical debt?

A. Launching a simple integration to test demand with a documented repayment plan

B. Deleting all monitoring from production

C. Storing payment credentials in plain text

D. Ignoring an unsupported security dependency indefinitely

Correct Answer: A. Launching a simple integration to test demand with a documented repayment plan

Question 10

Why might a hybrid architecture be preferable to an immediate full composable replacement?

A. It prevents all future integration work.

B. It can address priority constraints while limiting migration and operating risk.

C. It guarantees that every vendor uses the same data model.

D. It removes the need for governance.

Correct Answer: B. It can address priority constraints while limiting migration and operating risk.