Recipes for Extending SaaS Platforms

The Era of the Software Package Is Over

The advent of service supplied software is not a new phenomenon. From email to marketplace’s such as eBay, through to content delivery services such as Netflix, consumers have been using software supplied through a service delivery model since the beginning of the Internet’s widespread usage. However, enterprise software has often been provided in a traditional product package where ownership is rolled into a licensing model supplying the purchaser with total rights to run, operate and modify the software. This has been true of enterprise e-commerce platforms since ATG dominated the enterprise market in the 00’s and where Hybris picked up where Oracle left off. At the mid-to-lower end of retailer market capitalisation, software vendors such as Demandware and Shopify have been supplying service based software for over a decade.

The benefits Software-as-a-Service (SaaS) are multitudinous no separate hardware or operational costs, limited set-up and knowledge costs, the ability to scale the cost of usage and no-migration updates to name a few. One of the main blockers to large scale retailers using SaaS based e-commerce platforms in the past was the ability to customise the software to their specific operational needs. This often meant multi-year implementation projects to customise the product, followed by multi-month version migration projects because the product had been customised from the out-the-box solution.

Customisation in a SaaS world is still required and we will discuss how we can achieve that in one of the latest SaaS e-commerce platforms — commercetools. We’ll discuss with a mindset to ensure that the benefits of SaaS are still maintained

Not All SaaS Are Born Equal

Before looking at extending a SaaS platform like commercetools we need to consider what SaaS means.

We have mentioned some of the benefits a SaaS platform can provide, however not all platforms which offer their solution as a service do so in a way which will support those advantages. This is typically the distinction between a ‘hosted’ solution and a true SaaS offer. Hosted solutions typically mean that a monolithic on-premise solution is installed, hosted and specifically for a customer. This can invalidate some of the benefits such as ‘no-migration updates’ and limit scaling capabilities. Look out for the following when assessing the solution selection:

  • Multi-tenancy — solution providers who do not offer their services in a multi-tenanted fashion often do so because they are operating hosted solutions. This is frequently a good tell, however some might be force by design decisions such as legitimate security concerns.
  • Instance Provisioning — how long does the solution provider take to provision an ‘instance’ of their solution. This should be seconds or at worst, minutes. Ideally a SaaS provider will not make a distinction between an instance and the internal concepts of an application because of multi-tenancy.
  • Version upgrades and downtime — does the solution provider need to take a solution offline to roll out updates or perform hardware maintenance? If so, this could imply that the solution is not architected to scale horizontally and is also a hosted solution with a restrictive update process.

Understanding how the solution is architected and deployed can provide valuable insight into how a solution will be supported. From experience, we have seen that solutions marketed as SaaS which are actually , will invariably be supported by an organisation who treat problems like an on-premise solution provider. For example, will they take the responsibility to scale the application elastically seriously? Do you want to wait to find this out on black Friday when your traffic spikes?

The Value of an Abstracted Approach

Because software supplied in a service format is typically accessed over a network, often the internet, when a retailer wants to create the functionality to allow shoppers to interact, and hopefully transact, they will need to manage access. A retailer might use a number of SaaS solutions to support all the business functions of an omni-channel commerce platform. Aggregation of the solutions into one unified set of services is the ideal. It allows different user-interfaces to seamlessly access the same view of the business domain such as inventory, product data, or shopping carts from . Aggregation becomes even more powerful when imbued with abstraction because it hides the implementation detail which in turn yields flexibility.

Imagine being able to a search engine with minimal or no user-interface changes and then A/B test to ensure that customer and business value is being achieved. Alternatively you could interchangeably use a different payment service provider to save costs in different regions. Perhaps a new fulfillment partner is used and the order detail provided back to the customer can now include more accurate delivery detail. In all these situations the use of aggregation and abstraction supports rolling these updates through development into production with minimal impact to existing backoffice software and without the need to ring wholesales changes in the user interface.

A retailer will often use multiple SaaS software vendors, for example, a simplified solution might include one supplier providing commerce functions, one for product recommendations, another for social-media single sign-on and finally one to support advanced search. From the perspective of the retailer, the view of how each solution is performing will quickly become complex without some form of unified visibility. Observing a HTTP request from the client-side application through to the backend software can provide invaluable insights to both operational performance and security. Why is there a sudden spike in requests to forgotten password function? Possibly there is a weakness which requires investigation. How often is the recommendations engine, which costs multiple thousands a month, being used? in a sale conversion? Observing and collecting data as well as comparing it to existing analytics can generate major proactive benefits. Observation can take place in the same location as aggregation.

Aggregation and abstraction can be achieved through a form of middleware between your user interfaces and the backend systems performing your business logic. The simple step of proxying a HTTP request provides a basic form of abstraction because it means you can in theory change the implementation without modifying the format of the request. This disentangles this migration from the perspective of the user interface. In practice a middleware solution which provides greater functionality is more useful, take for example the observability point above. If proxying is at one end of the spectrum then bespoke services is at the other for this style of middleware. The question is, are you replacing the on-premise monolith of the past with more custom code which will in turn negate the benefits of using SaaS software? To answer that question, we need to ask another do you have the capabilities to develop and manage a lightweight middleware comprising of a number of domain-driven services? The ability to do this is a key strategic decision.

Extension By Abstraction

Middleware, in its many forms, has been an established pattern of integration for distributed systems since the dawn of enterprise software. In our context, it provides a mechanism to perform the aggregation and abstraction previously mentioned. A middleware such as a classic API gateway can do this. However, to enable extension we need the to modify both inbound and outbound requests whilst supporting the ability to include bespoke functionality.

When establishing middleware, proxying a request without modifying its composition will tie you to the design decisions of the SaaS provider. Most API enabled SaaS software organise their services by domain, this can be mirrored in the middleware. Using a domain-driven approach enables the organisation of services by domain function and provides the chance to question how the organisation’s business function is supported. For example, can the stock availability systems expose their data accurately to support ‘click-and-collect’ retail journeys. Ratifying the capability of the ‘inventory’ domain will allow you to both surface existing functionality while planning for future change.

Payment Extensions

A classic e-commerce customisation is to integrate a payment service provider. The style of integration supported by payment service providers has improved significantly within the last few years, this has enabled a lot of the payment integration grunt to be moved client-side to reduce PCI scope. Client-side encryption and JavaScript frameworks have done much to improve this area. However, in e-commerce systems a mechanism to transactionally acknowledge a successful payment means that server-to-server communication is almost always required. This means that a server-side system, bespoke or otherwise, needs to communicate with the payment service provider to validate successful authorisation of the payment so that a customer’s order can be processed safely. In the case of commercetools, the platform is agnostic of payment integration, and therefore does not handle this server-to-server processing without restriction (to be discussed in Extension By Function section). Whether using a custom code deployment or using a Function-as-a-Service enabled cloud solution this introduces a custom-made application element which needs to be considered with respect to development and maintenance.

In the case of payment, by using the abstraction tier to extend the application it can add additional benefit. Allowing the introduction of another payment service provider, if their functionality is sufficiently similar, is often a necessity for retailers operating in multiple geographic regions. It also supports the possibility of aggregating multiple payment service providers which can benefit the solution by providing additional redundancy to a critical function. we have supported the ability to extend, abstract and aggregate functionality using an established enterprise pattern.

Extension By Function

An alternative to middleware extension is the ability to extend an application as prescribed by the SaaS software provider. This might mean tapping into a ‘plugin’ store or configuring the service through APIs or an admin interface. The commercetools platform supports two main mechanisms for extending the application with custom code. Firstly, API Extensions provide hooks to gain a synchronous control of a request. Secondly, Subscriptions allow downstream asynchronous notification of data modifications. Both extension mechanisms are very sensible approaches to enabling customisation of the platform because they both inherently support scaling the customisation with minimal effort. API Extensions can invoke functions in the cloud (FaaS) implementations from the leading cloud providers such as Google Cloud and AWS. The scaling and management of the functions are implicitly provided by the cloud provider. Equally, Subscriptions support the use of cloud provided message queues such as Google Cloud’s Pub/Sub or AWS’s SQS which means that again the scaling and management of the customisation is handled. This makes for a very compelling argument for using these approaches to customise your solution and in a number of situations this will be the recommended approach for extension.

When using the extension point provided by the SaaS provider you will always be bounded by both way the extension is provided and by the function of the extension. In the case of commercetools we have seen the way the extensions are provided are very good. But there are restrictions which need to be considered. API Extensions have a 2 second response limit, while the number of supported at once is also restricted. These restrictions will influence how flexible the extension point is. If we take our earlier payment service integration example, the API Extension might not be appropriate because it would necessitate that the payment service provider would need to reply to a request within 2 seconds, this cannot be guaranteed. Likewise Subscriptions might not be appropriate for the same use-case because they are asynchronous and there might be a requirement to provide instant feedback to a customer about their payment. There are probably workarounds for the examples provided, however the point still stands. If using extension points of the solution provider, you will be bound by the way they are supplied.

The of the approaches presented should be balanced with some realism. This means we would not advocate any one mechanism of extension on its own, and would therefore suggest an approach where all situational considerations are made. The common ground will be using the correct approach for the specific task. An abstraction layer supports the benefits outlined and can be used alongside the specific capabilities of the SaaS platform in question. Marrying the best of both worlds provides the most flexibility. This, however, requires both extensive knowledge of the SaaS platforms being used, alongside the know-how to stand-up and manage the middleware glue used to support ultimate .

In short, we have shown that adoption of a SaaS paradigm doesn’t restrict your ability to customise. In fact, with commercetools, you have many opportunities for customisation that other platforms do not have.

Originally published at