# Why API-based open architecture is good for an e-commerce ecosystem

### Static view

*In 'Static view' we look at an e-commerce system as part of an existing business ecosystem and compare closed (single-vendor) and open (modular) architectures in action.*

Gone are the days when the Internet was composed of simple HTML pages, and e-commerce was driven by monolith scripts. Nowadays, a e-commerce platform is a zoo of multiple services and applications that make it a part of the business' ecosystem. Some expamples are:

- an ERP that has all the master data
- a CMS to easily create and change the frontend content
- a payment provider integration
- a pricing module for B2B e-commerce
- a tax provider integration to make automatic tax calculations
- a shipment provider integration for multiple postal and express services
- a PIM system that controls all the product information
- analysis, data visualization, and business intelligence tools
- online marketing tools
- multiple communication channels interfaces
- and so on

The number of these tools is constantly growing, and all of them are important for a healthy e-commerce business. It's near impossible to incorporate everything into a single solution. Thus, these tools are becoming separate applications that compose a big e-commerce system. According to Gartner [citation?], this granularity will grow further, so that in the end each business function will become a separate application.

And it's becoming increasingly difficult to collect all of these applications in a single developer's software suite. In most cases, e-commerce developers that are providing such suites are excellent at doing the tools that they specialize in, good at a lot of others, and omit some obscure functionality that is not needed by the majority of their customers, but may be vital for a particular business.

A business has choice: either build an ecosystem around a single developer's e-commerce solution, or follow the open architecture road and build it around the tools from different vendors according to the business' needs.

In the first case the business will have to adapt to the tools provided, as it has no power to change their selection (nor quality). This may be a good decision in some cases, especially if the tools that the developer excels in are exactly the ones the business initially relies on.

The second case is business-centric: it means finding the best tools on the market to build a unique system tailored to the business' specific needs and aspirations. This approach provides greater system versatility, wider budgeting options, and also allows developing own connected applications to get an edge on competition by creating unique services.

Let's take a B2B pricing module as an example. VirtoCommerce solution has a flexible pricing tool that should be suitable for most e-commerce ecosystems. However, some customers already have their own complex pricing engines integral to their ERP, and want to use these in the e-commerce system:

1. Some need a gateway between that engine and the e-commerce front that will grab the prices needed and arrange them in the frontend format.
2. Some B2B clients have relatively low load on their frontends, so their ERP can provide pricing information on the fly; in this case the e-commerce core should be able to connect to it directly.

With modular approach, such use-cases can be served using applications tailored to the specific client's ecosystem.

### Dynamic view

*In 'Dynamic view' we check how closed and open architecture models compare during the e-commerce inception, growth and maturing as part of the business ecosystem.*

When a business starts a process of digital transformation, the same two paths described above are open to it:

- obtain an out-of-the box solution and build the ecosystem around it;
- start with a simple e-commerce core and add new modules to it according to the business'/customers' needs.

Both have advantages and disadvantages. To recap:
Single vendor | Open architecture
----|----
Faster deployment of a fully-featured system | Quick MVP deployment
Excellent connectivity of available tools | Wider selection of tools, but some tailoring may be required
The system evolution depends on the vendor | The system changes according to the business'/customers' needs
If it doesn't take off, it's a failure | The system is versatile and may change until it suits everyone involved

It is extremely hard to predict what path the digital transformation process will take, what tools will be most relevant, what features will customers and employees require most. There are just too many factors that impact the process, and the technology evolves rapidly, providing new solutions even while the transformation is happening. For most businesses, a trial and error approach will help get a clearer picture and build an e-commerce solution that will suit the existing ecosystem most. Open architecture is ideal for checking hypotheses and testing different approaches.

Another important aspect, especially for the B2B e-commerce, is the user adoption. If customers don't accept the e-commerce solution, it's a failure, there's no way to coerce them into using it. The earlier a business starts to acquaint customers with the e-commerce system being deployed, the better. Even a rudimentary MVP will provide valuable feedback that will help avoid costly mistakes in the future.

Once an e-commerce system is past its infancy, a cloud of hypotheses surrounding it during inception starts to turn into solid plans that need to be implemented. These decisions are based on customers actions and feedback; that's valuable information that was not available earlier. Now the business knows what must be done first: maybe it's a catalog structure improvement, maybe it's additional communication channels, maybe it's ML tools. There is a virtually endless selection of tools that may be desirable at this point, and with open architecture it's possible to deploy, adapt or even develop them from the scratch. The business doesn't have to follow a pre-determined path at his point, it can adapt to the changing circumstances and the recently acquired information.

An open architecture e-commerce system doesn't stop evolving even after it reaches maturity. New software gets released, new and better tools become available, new ML algorithms emerge. Open architecture allows a e-commerce system to remain cutting-edge at all times, seamlessly integrate the best and latest API-based solutions available, allowing the businesses to continue uninterripted growth.