07. Juli 2020
What do we get out of the box with platform product x from vendor y? This is a question I often get from the clients that I am serving. In this blog, I’d like to tell the honest story about how I see the term out-of-the-box being used in the field versus the realities of what it actually means to an implementation with a platform product.
There are many different kinds of software products, but given my background as a Senior Technical Consultant at a digital agency, I am specifically writing this blog from that context because that is the world I’m living in. In this blog, I am talking about the Digital Experience platforms we are using from our partners like Adobe, Sitecore, Optimizely, Bloomreach and Magento but also the new wave of MACH enabled technologies like Commercetools, Contentstack and Contentful.
The Term Out-Of -The-Box
The main issue I see with the question “what is out-of-the-box?” is that I see the term being used with varying definitions. The question by itself is a valid one that often stems from the real knowledge that heavy customisation of an off-the-shelf software product can result in a system that becomes problematic to maintain and upgrade. In most cases, my clients have also been talking to vendors because they are in the process of selecting a platform and are now seeking impartial advice about whether the picture the vendor paints is real and whether the product is really a good fit for their organization.
What I have noticed over the years is that different people tend to use very different definitions for the term out-of-the-box. In my opinion, a particular cause of this seems to originate from the all too known big RFP documents with impressive requirement lists that sometimes can reach more than 200 items.
During the RFP, a vendor needs to indicate for each requirement whether it is covered by the vendor’s product or not. Since I have done a large number of RFPs, I know from my own experience that answering some of the requirements with “no” can mean a swift exit and removal from the RFP process. This is why these RFP requirement lists tend to be answered in a very positive way. And although it most certainly is not lying, I think it is good to know that in most cases it is more nuanced than the answer might indicate. Working at a digital agency like Valtech, I have seen that there is often quite a big mismatch between the potential buyer’s expectation about out-of-the-box functionality and what I know is actually out-of-the-box. It is important to be aware of the fact that you at least need some sort of an implementation with the product before an end-user can actually start using it.
Connecting the Ecosystem
Nowadays, a platform is not just about the platform anymore. Instead, it is more about the ecosystem and the way it is embedded into that context. It is safe to say that in today’s age, 99.9% of the time, the platform also needs integrations with external systems. This can be any kind of system like premise internal systems, a third-party Data Management Platform, external analytics solutions, business process management components or cloud-based SaaS third party systems.
In my experience, in most cases there is at least some implementation work needed to connect to those systems.
Most vendors offer a number of standard connectors to most common external systems. Some examples of this are SharePoint connectors, Dynamics CRM connectors, marketing automation connectors and even SAP ERP connectors.
Although it is true that these connectors exist and that they can be useful, it is also true that in most cases they do not exactly fit the actual use case that you are trying to solve. This is especially true when the external system has been customized or configured to adapt it to the company’s exact processes and domain architecture. In these cases, there is always work needed to integrate these systems, especially when a deep integration is required.
Different Types of Implementation
Looking at a typical implementation project, there are different kinds of implementation that can be needed, ranging from completely out-of-the-box to heavy customization. A total of five different implementation types are distinguishable. The different types are depicted in the diagram below, and they range from lightweight implementation on the left to (very) heavy implementation on the right.
Out of the Box
This is completely out of the box. In other words, the software is directly installed as it is received from the vendor. The result of this would (at best) be a standard application with standard functionality, a standard look and feel that does not adhere to your company’s brand guidelines and an application that does not integrate well or deep enough with your specific ecosystem. The point with this variant is that no company actually does this because it does not meet the needs of the business.
Configuration
This type of implementation is actually what most customers expect when they talk about out of the box. Configuration type work is typically the day-to-day work being done by the end users in your organization in the back-end area of the product. They use what has been given to them as re-usable technical components to manage the platform.
It covers roles like content authors, editors, campaign editors, marketeers and also technical administrators. Typical activities of configuration work are things like creating pages/landing pages, adding navigation items, creating and managing an email campaign, a/b testing, targeting user segments with personalization, creating the content taxonomy, enriching product data and approving content in a workflow.
Standard Implementation
Standard implementation work is done by a developer resource. This is the creation of the technical components that are needed to build the digital touchpoint. It is a normal part of a standard implementation. These are for instance things like the creation of landing page templates, content components, the product data model, the content data model, search page templates, product detail templates and article pages. These components are created with the tools and technology that are given to you by experience platform. It is the aim of the standard implementation to give the end-user the functionality and components to do the type-two configuration work they do when using the solution on a day-to-day basis without further involvement of development.
Standard Customization
This kind of implementation is actually what most vendors mean when they say that a certain functionality is possible out of the box. All platform products offer some way to customize or extend the product. This kind of standard customization is possible out of the box, but it does not mean that it is already there when you switch on the platform. Standard customization is also done by a developer.
In this type of implementation, the developer adds functionality to the platform that is not present yet. Like the previous type, it is also part of a normal implementation. Important aspects of these additions are that they stay within the intended use of the platform, that it does not impact the core of the solution itself and that it stays within the customization capabilities the platform offers. Examples of this are connecting the platform to an external bespoke API for pricing, linking it to an external CRM solution or linking it to your company’s AI recommendation engine.
Custom Customization
This is the problematic kind of customization that everybody is afraid of and that will hurt the longevity of the platform. Unlike the previous type, these customizations are going beyond the platform’s customization capabilities and the core of the product is affected. Any company should try to steer clear from this kind of heavy customization. This is because the solution will be so heavily customized that it will hurt long-term stability, quality and upgradability. What qualifies as custom customizations varies per platform product. For the Sitecore platform, some examples would be replacing the internal workflow engine with an external workflow engine, modifying the way the engagement scoring mechanism works or linking it to a JSR type content repository as content storage.
In Conclusion
A platform is never completely out-of-the box when you install it and turn the key. You always need some sort of implementation on top of the platform. When doing an implementation, most customizations are considered a normal part of your implementation. These kinds of implementations will not have an impact on the quality, maintainability and upgradability of your platform. Only the fifth variant is dangerous and should be prevented. Also, be careful of how you interpret the answers you get from a vendor. The vendor might mean the fourth implementation type while you have type one or two in your head.
