Why integration with Virto Commerce would never be a problem?

Feature name: Integration
Readiness: high
Development Effort: low

Designed to be integrated with everything

Virto Commerce is designed to be a part of an enterprise digital commerce ecosystem. We have never expected that (any) vendor can cover all business needs so we don’t expect that some software should be better integrated with Virto than others.

When a vendor states that his products are better integrated with each other and position it as an advantage, it usually means that either he wants to upsell or his products are technologically antique.

In the modern world of 2020th, any good software is easily integrated with any other good software.

Virto Commerce, being an enterprise API-based e-commerce solution, is supposed to integrate with any modern business software.

Below we disclose how Virto Commerce solutions resolve main requirements dictated by enterprise e-commerce projects nowadays.

Each and every function must be available via API

Each and every function that you can use in your software must be available via API.

Virto Commerce is designed and developed as a modular API based e-commerce platform. It means that there are literally no functions that can be used bypassing API.

What does it mean for business?

It means that any action that can be executed inside the system can be integrated with the external software without any restrictions from the platform side. It opens a huge amount of opportunities to combine different kinds of software, replace labor routines with automation, and delegate to your customers any responsibilities or access to any information.

There is only one API, instead of “internal” or “external” APIs

There should be only global API to make any function in the system available for integration: no difference between “internal” and “external” API.

Having “internal” and “external” API usually points to the fact that the system was designed as a monolith without the focus on seamless integration with other software. It usually brings problems and overheads to development and maintenance teams. That would be also a problem for external service users as soon as many functions are unavailable via the “external” API.

You can see enough solutions on the market where only some functions are available via the API for end customers. In the modern world, it causes integration problems that can not be overcomed easily.

Being the API based software by design Virto Commerce doesn’t contain any archaic rudiments of “pre-API” existence: Virto Commerce has global API that is easy to maintain and every function you decide can be integrated with any modern software.

No out-of-the-box integration for complex software

Talking about the value of out-of-the-box integrations with ERP, WHS, or CMS our partners constantly return to the same statement:

When I see that some e-commerce vendor promises to me an out-of-the-box integration with ERP, I know I will never use it for enterprise projects. Enterprise business is quite unique, ERP is always customized and the only purpose of this integration for me is to prove that it is possible to develop my custom integration.

Finally, there is no difference if a vendor has this integration or has a case-study that proves that this kind of integration has been already done by someone else.

And the value of these point-to-point integrations is zero for me because enterprises use middleware for any async connections (ERP, DWH).

Middleware instead of point-to-point integrations

Using middleware for integrating Virto with other applications is a good practice that is normal for enterprises and middle-size companies rather than point-to-point integrations.

Reasons are quite obvious:

  • Security – the middleware is central governance for data security and compliance
  • Cost of development – when delivering a new application or new system to the enterprise, it’s easy to extend workflow and new items into the pipeline. No development efforts and hidden integration cost.
  • Unlimited capabilities – the middleware is described in open JSON-format, no-hardcoding business rules, or data-transformation. A lot of ready to use connections with databases, messaging services, data services, applications, and network protocols.
  • Supportability & scalability - the middleware has out-of-the-box asynchronous processing, versioning, retry policy, error handling, monitoring, alerts, and logging.

References

Enterprise Integration in Actions

Keywords

integration, ERP, CMS, WMS, API, API-based, ecosystem

3 Likes