There are very few PIM solution providers who have not yet made the leap to the cloud, offering only an on-premise version of their application. While some have opted for SaaS by design from the outset, such as French publisher Quable or American Salsify, others have preferred to opt for PaaS at first, offering greater integration flexibility. But the current trend is towards full SaaS, which is not without its constraints on the overall architecture of an information system. That’s what we’ll be looking at in this article.
But, first, let’s clarify the meanings of the terms On-Premise, PaaS, and SaaS.
First of all, On Premise means that the solution will be integrated into the customer’s own infrastructure, with the customer responsible for installation and maintenance
With PaaS (Platform as a Service), the provider offers its own cloud infrastructure to host the application. This allows the client to share some responsibility with the provider, who manages the infrastructure, while the client (or its integrator) remains responsible for software maintenance (including version updates) and data.
Finally, SaaS (Software as a Service)is a mode of operation in which not only the cloud infrastructure is managed by the publisher, but also the entire software component. In this way, responsibility for hosting and maintenance is transferred to the publisher.
In the SaaS model, the PIM can evolve seamlessly for the client: there are no more version upgrades to manage. Moreover, these are not annual or bi-annual versions but rather continuous improvement with monthly, weekly, or even daily updates. This allows you to benefit as quickly as possible from functional evolutions or patches (security patches, for example).
The following diagram illustrates the different levels of provider service and responsibility, depending on the choice of hosting solution:
For some, the choice of on-premise hosting is not up for debate due to a desire to control and secure their entire information system. However, the SaaS model is appealing for many because it allows the delegation of a significant portion of responsibilities. Naturally, there’s also a financial dimension, as PaaS / SaaS hosting logically represents an additional cost item. Recently, there has been a significant increase in pricing by SaaS solution providers (see Le Monde Informatique article “Gartner calls for vigilance on SaaS solution price rises” FR version). Therefore, it is necessary to carefully assess the benefits of SaaS solutions relative to the associated costs compared to the implementation and maintenance costs of an entire internal infrastructure.
Another crucial aspect to consider when making infrastructure choices is the need to customize the PIM solution. At the start of any project, everyone is aligned to integrate the chosen solution with its native features without customizing it. This is where upfront solution selection and framing become invaluable, ensuring that the chosen solution best aligns with the client’s expectations.
However, often, the constraints of the information system or business team requirements necessitate adding specific developments. This can be done to manage incoming or outgoing data flows if the information system lacks an ESB or ETL component, or to extend the tool’s native functionalities to meet specific business processes.
If we consider an architecture based on on-premise integration, specific developments can naturally be added to the application.
In the case of PaaS, if the application is hosted outside the customer’s IS, it can still be accessed to add specific layers.
This is where SaaS, while inherently simple and convenient, becomes somewhat more complex..
The implementation of connectors can no longer be done on the dedicated PIM infrastructure. Instead, a middleware is required, either within the internal information system or on an external component, to carry the business logic of these interfaces.
Hence, integration must be done via full APIs, as very few solutions still allow SSH or sFTP access, rendering the use of file-based imports/exports obsolete. These APIs must be a highly stable foundation independent of frequent version updates. If there are functional additions, changing an API method’s signature must be avoided at all costs to prevent jeopardizing integrations based on it.
To further enhance the possibilities of PIM integration via APIs, some providers offer event-driven APIs (as is the case with Akeneo). This allows the reversal of the triggering logic: it is no longer the middleware calling the PIM to perform an action but the PIM notifying the middleware of an event (e.g., a product creation by a user, a status change), enabling it to trigger an action in turn.
Furthermore, any tool customization, such as interface branding, can no longer be done. APIs offered by SaaS solutions very often focus solely on data processing and do not offer ways to add features to the user interface or personalize the user experience (it is impossible via an API to add a button, insert a menu entry, push custom notifications, etc.).
Feedback
One of our B2B food distributor clients has an Akeneo PIM in PaaS connected, among others, to an on-premise SAP ERP and a SaaS-based Mirakl marketplace.
In order to reduce the costs associated with PIM version upgrades (1 major version per year) and motivated by the vendor’s strategy to favor their SaaS version, the client is looking to transition their PIM from PaaS to SaaS.
With this in mind, work has begun to transfer certain connectors, including the ERP connector, present in the form of bundles (extensions developed specifically for the PIM platform) to the IS’s internal ESB.
However, the question remains regarding how to connect the future SaaS version of the PIM with Mirakl, which is also SaaS-based. The interface is currently managed via a bundle “on the PIM,” which provides a configuration interface and manages Mirakl API calls. This brings us right to the heart of our second case study.
On behalf of a publisher of a translation solution, we’ve been developing their connector to one of the market’s PIM solutions for several years (see our article). As these 2 solutions are based on a SaaS model, it is not possible to add a specific development component to manage the interfacing, along with the associated business logic and configuration screen, which is minimal but essential for setting up the connection between the SaaS instances. Therefore, we developed a third-party application to handle all of this, a simple one based on Symfony.
However, the crucial question at this stage is, “where to host this application”?
For a client who chose to use two SaaS solutions to abstract themselves from infrastructure issues, it would not be reasonable to end up having to host an application to connect them. In our case, it was the provider of the translation solution, who initiated the connector, that chose to host this third-party application and offer this service to its users.
Clever Age’s Perspective
As we’ve seen, each hosting method has its advantages and disadvantages, and there’s no single “right” solution. There is a growing trend among providers to move towards SaaS, which offers flexibility for both parties. We encourage this movement when it aligns with the IT department’s mindset because it genuinely benefits our clients by abstracting them from technical hosting issues and allowing them to focus on functionalities, where the true value-added by these solutions lies. Furthermore, SaaS solutions are a fundamental pillar of MACH (or “composable”) architectures.
Nevertheless, SaaS may not always be compatible with projects that have demanding requirements if the solution’s features do not sufficiently meet expectations and necessitate customization. It is also essential to be vigilant about interdependencies between solutions during version upgrades, as different connectors can sometimes take several months to catch up (as was the case with the arrival of Magento 2, for example).
Hence, it is vital to evaluate the different architectural approaches against the needs and constraints of each PIM project. These characteristics should be studied at the project’s outset during a preliminary framing phase, which allows selecting the solution that offers the closest functional coverage to expressed needs and best meets integration constraints with the information system
