What Is Headless Architecture and Why It Is So Important For Ecommerce Future

This post on headless architecture is in the format of a dialogue between a Business owner and Oleg Zhuk, technical product owner of Virto Commerce.

Welcome to find out everything that most decision makers want to know about the headless principle in ecommerce architecture. According to Virto Commerce’s practice, people from established B2B businesses are most often interested in headless platforms. Many such organizations have been forced to develop B2B ecommerce portals during the pandemic and due to recent legal restrictions. 

In search of a suitable ecommerce solution, companies turn to various vendors, where they also hear the term headless as something very technological. And at the same time, vendors do not explain the advantages and disadvantages of headless architecture, which we will disclose today. 

The interview consists of some sections on headless benefits for business growth, and why headless makes the development process cheaper and faster.

Business Owner: What is headless anyway? I’ve talked with various vendors, and many try to create mystery around this technology. It prevents me from understanding the essence. 

Oleg Zhuk: In fact, it is quite simple. The idea of ​​headless has long been used in various fields, including solving complex business challenges. Suppose there is a complex task, or you need to create a technical system. If all this seems completely unrealizable due to its high complexity, you can divide the task or system into simpler parts and execute each of them separately. 

The term headless is such a confusing one that I think it was coined mechanically. That is, clumsy or with a core misunderstanding of its essence. In fact, this is a fairly simple term as the separation of the front end module(s) from the rest of the complex software system, and a tool for making small, simple parts out of a large complex application. This is actually a standard practice, that is, since the advent of science and industry, known as modularity. 

An excellent example of headless architecture would be a modern car; the accelerator pedal has no mechanical connection with the engine, nor does the brake pedal has a mechanical connection to the brake pads on the wheels. These connections have software implementation via the board computer. This makes the car more technologically advanced in production.  There is no need to figure out how to run cables and pipelines for cars with left- and right-hand driving. The pedals can generally be placed anywhere, even at the rear passenger seat (just kidding). 

Applied to ecommerce platforms, it looks like this — we are developing such an application, but it will most likely be very complex. The complexity comes because this application must interact with customers, whether it is a retail customer or a corporate purchasing officer. Accordingly, an interface is needed (website, mobile application, sales through social networks, etc.), where a single business logic can be implemented. Here, to simplify the development, testing and update processes in the application, you can separate the UI (user interface) for customer interaction and the business logic of the sales process separately. And give this to different groups of developers, let them each work separately.

Business Owner: Are there any criteria for when a headless ecommerce architecture is needed that you can convince me of as a businessperson, not as a developer? 

Oleg Zhuk: Of course, let's talk about situations where you need a headless architecture. Suppose you have a business idea for which you can build an application from existing software. It is hard for people with a business background to judge if that's the case, but people around you, like the CIO or a consultant, can tell you.This is where headless architecture comes in handy. For example, the brothers Orville and Wilbur Wright assembled the first airplane from wooden slats and fabric. They also invented the first aircraft engine but used automobile motor parts there as well. These parts were already on the market, but they created a completely new product from existing components and thus stand in history. 

Likewise, the headless architecture helps you take existing components, in this case computer programs, and use them to create a unique new product. Headless ecommerce allows you to decouple the business logic of the sales process from the implementation of the UI. 

You work with ERP integrations, PMI, front end and other applications and merge them into a system, like Lego and enable customers to interact with your product. This is an opportunity to create UI by extending your business idea through various applications, so they work together to get the client to press the "Buy" button. The headless architecture allows you to experiment.  

Otherwise, you need to duplicate all this logic for all front end options or, in other words, touchpoints (website, mobile application, messengers, etc.). This is expensive to develop and leads to chaos when implementing business rules in different touchpoints [for example, somewhere these rules were changed and updated, in other touchpoints they were not]. The principle of omnichannel sales may be violated when prices and promotions in different channels may not coincide or are even contradictory. 

Let’s take an example of a billboard-type website that we had compiled using Excel (this application has its own API). The site visitor didn't know that Excel was running internally. They went to the site and filled out the registration form without seeing what it was built on or what was inside. It was easier for us to do that, and the employee then opened the Excel file and saw all the registration data. This data could be transferred to the sales department to start working with these clients. 

The headless architecture allowed us to replace the standard Excel interface with a site-friendly one. And on the other hand, the implementation of the headless principle became possible thanks to the availability of API in Office 365. 

Business Owner: Now let's say a few words in the opposite direction. As far as I know, the term “headless” appeared quite recently, while online commerce has been around for a couple of decades. How did people do without headless before, and can we do without it now? 

Oleg Zhuk: Let's talk about cases where the principle of headless architecture is not necessary for you. There may be several situations, but one of the most common is when you want to make your application extremely fast, whether it is online commerce or another subject area. Suppose you want to build your system as quickly as possible to show to investors or key customers, demonstrate the viability of your idea, or test it for yourself. 

That is a situation where you need to make an application more straightforward and faster. Then, when commercializing the idea for the market, you can redo the application [i.e., rebuild it]. We had a good example where the developers put together a marketplace website in a few days to test a unique business idea. 

In a situation where time is the main criterion, you can use such old architectural solutions as a monolith and temporarily forget about latest trends. But it must be said a monolith is not a suitable architecture for a commercial system planned to be operated and updated for a long time. There is a huge amount of code in a monolith, which is hard to edit. It is difficult to change any technologies in the monolith. 

Therefore, the message here is to evaluate your business challenge and choose the application architecture accordingly. 

Business Owner: Is the convenience for developers this remarkable with the headless principle? 

Oleg Zhuk: Let's now consider when headless is beneficial. Do you want to develop your sales channels? You have a website that works, you have created an online store website, which works for you. If the technology remained in place, you would not need headless; sales would go as usual. 

But the world is changing rapidly; customers are getting new communication opportunities as new sales channels in the field of online commerce. The next step can be creating a mobile application or connecting a chatbot as a new sales channel. 

Then you assign such tasks to your IT team, and they just replicate your front end from the site. All this logic is transferred to the mobile application. That is, you actually make copies of your business, your product. The effort increases, the likelihood of errors increases, and inefficiencies arise because nothing can be reused. This is especially difficult for B2B, where there are contracts, its own special business logic, and so on. 

In this case, headless for ecommerce allows you to decouple the business logic from the implementation of front end options. Your application becomes like a fairytale multiheaded dragon, able to attack more effectively. Attack the market to expand market share and be more resistant to competitors’ actions in the market. 

More importantly, such development is cheaper while the full omnichannel principle would be implemented. Any change in business logic at the lower levels would automatically be transferred to the touchpoints. It won’t occur that prices have changed on the website, but not yet in the mobile application, and vice versa. After all, especially in B2B, when orders are large, there can be as many as 1000 items in the basket. Manually retrieving the reason for showing incorrect prices in one of the touchpoints is then exceedingly difficult.

Business Owner: How difficult is it to migrate to a headless architecture if you don't build it into the foundation of an ecommerce platform to begin with? 

Oleg Zhuk: If you already have an ecommerce website, even on WordPress, there are certain approaches, techniques that allow you to transform to a headless architecture. Of course, there will be costs initially, but then you will start to benefit from this transformation, which will allow you maintain omnichannel sales easily. 

The company’s usual requirements in the early stages of the development of a B2B portal are that customers can see the online status of their orders [and not have to call the supplier's sales department], that customers can connect employees of their organization to the portal, enter a delivery address for ordering. The shopping cart and automatic payment are already the final stages in the development of the B2B portal. We wrote a particular article on this topic, showing how customers can adapt to purchase on the B2B portal, and get accustomed to ecommerce instead of calling a supplier or sending an email, all in 10 steps or just a few months. 

Next, what about improving the user experience, UX? When your project grows and changes, it always contributes to sales; people react to changes; this is how our psyche works. People shop more actively, and conversions increase. Such new functions of the B2B portal as re-ordering or adding bulk goods to the cart via an Excel file can increase sales and can improve buyers’ productivity. 

If we are talking about B2B, buyers spend a lot of time on the vendors’ sites; this is their job. By making improvements to the UI, you improve their UX. Basically, we improve their workplace in a way, increasing their productivity. 

At the same time, with headless architecture implemented, the people in your IT team will also have a more specialized and creative approach to their tasks. Simply because their area of ​​expertise is shrinking, and they grow as vertical niche professionals while helping your business grow. Each group in your IT team would have its own roadmap, allowing you to accelerate development and accelerate implementation. 

It is especially useful to have such specialization of people in the IT team and such focus with the help of headless because it also makes the development cheaper. In fact, this leads to the fact that the business is moving faster, which is one of the primary purposes, isn’t it? 

Business Owner: There is nothing worse than rebuilding an online store repeatedly while everything around is changing so fast. Will headless help me with this?

Oleg Zhuk: Another reason that can lead to the transition to headless, even if we are only talking about the store's website, is business continuity. After all, you want to maintain the work of the site for at least several years, and preferably longer. You are planning a long-term strategy for the development of your digital system within your company, and you understand that technologies are changing very quickly. And, again, it makes perfect sense to divide the system into smaller pieces, separating the "head" in the form of the UI interface from the business logic so they can be changed independently. 

For example, many posts on the Internet say that in software development, front end technologies change every 3 years, and their total lifespan is about 5 years. Then the technology is totally outdated. 

Accordingly, front end and back end technologies have different development cycles. If we consider all of this as a monolith, as a whole, then, consequently, we will constantly be updating in order not to left behind and will have a constantly raw product. 

We need to synchronize the development cycles of our product, our digital platform within the company with the cycles of technology change. So, it is logical to separate technologies that have different rates of development rates. 

As an illustration, once I had a project experience that I had to stop because one key technology within the project was outdated, and it was very difficult to rewrite what had been done for 5 years. It was very expensive and meant repeating everything we had been doing for 5 years from scratch, but with a new technology. Therefore, the project was simply discontinued. If we could then make a project following the principles of headless and change the technology, but not everything in its entirety, but in parts, say once a month to replace some pieces, the project would be successful. 

But I do not want to absolutize headless. If you see that technologies are changing very quickly, again, you can plan your strategy and understand that in 3 years this all needs to be thrown out, and even hiring new developers is also an option. But you will have to invest in describing business processes so when another team comes in, they understand what your business is logically and technically, what data streams it consists of, what your application ecosystem looks like. This way, you can give the new team a technical task, say that all the information is there, go ahead, and rebuild the system using innovative technologies.

Business Owner: Yes, we all know that developers are expensive guys, and hiring smart ones is not easy either. Therefore, any opportunity to save money is welcome. 

Oleg Zhuk: Therefore, the next point to be noted is technical things such as automation, integration, testing. One of the benefits of headless is IT automation. The headless architecture is built on communication through standard protocols, REST, GraphQL, HTTP and others. The presence of protocols allows you to build and organize a development automation system. 

For example, the Chrome browser currently supports 2 modes. It can maintain normal behavior as you launch it in a window, and it can maintain headless when you interact via an API, receiving and sending data from the Internet, or using the browser as a code debugging platform. The presence of an API in the browser allows you to customize diagnostics. 

Further, many managers do not know how much time their developers spend fixing bugs in the code. They don’t find out how these bugs appear — because of writing new code or because of fixing other bugs? How often do these critical errors reach the product stage? How much time is spent on testing? And these are all essential savings factors in the software development department. 

My experience is that by adding the first 8 simple automated tests for critical business logic for placing orders on the ecommerce portal allowed us to identify up to 80% errors and issues in the initial stages. We discovered bugs before the client reported them. And precisely headless is the architecture that allows you to start building development automation and get the acceleration of work processes in the team until the product is completed. 

But you must have certain metrics in order to use headless effectively. You need to control developer time; if you don’t, the use of headless will not increase development efficiency. If you don't know how much time a developer spends on a task, it's not a savings but a waste of money. 

Using headless for DevOps automation could save you team resources, and you should bet that the cost of project development will be reduced.

Business Owner: Let's summarize what has been said about headless for my Board of Directors.

Oleg Zhuk: Yes, let's do that. In fact, companies that want to launch a B2B portal have 3 ways.

The first way is to buy an ecommerce solution "out of the box", usually a cloud solution. Using one of the vendor-ready templates you can get the online store there. This can be done quickly and inexpensively. If later some kind of customization is required, there will be difficulties and, most likely, you will have to change the platform.

The second and third way is when system write you a solution from scratch or help your team do so. This is where the choice of the platform architecture will be including the principle of headless. Reject the proposals to make a monolithic solution for you, starting to write code from a blank screen. Instead, using the headless principle, begin to assemble a platform from ready-made modules. The last ones will take existing API-driven applications and build a solution from them. It is fast, flexible and, what is important, the already tested functional modules with a minimum of bugs are used. You are able to take the best applications on the market in your niche and integrate them into an ecommerce solution.

Now, let’s review the essence point by point:

1. Headless architecture is not an absolute and definitive advantage in IT development and ecommerce. If you see that something can be done faster with a more traditional application architecture, do it that way. Give it a try, see the customer reaction, and get a response. You may not need headless at the very beginning of this journey. You just need to test your ideas, get a response from your customers. Many out-of-the-box systems are suitable for this.

2. The situation changes when you plan to develop different sales channels. If you see you can improve the speed of development, reduce the cost of development since specialization appears, then use headless. Employees begin to focus better through team specialization. For example, you see that you can change the design faster than in the current version of the product. Or suppose you can develop your application at the same pace as the technologies around you, you want to take full advantage of new technologies, use development automation — just do it. This is all easier to implement using the headless architecture.

The headless architecture allows for faster organization of product development. Since it is possible to divide developers into groups, each dealing with a specialized module, and then dock based on standard protocols, it is possible to reduce the time to market for a software product significantly. Moreover, with headless, you are ready to change technologies since the docking protocols remain, and the modules themselves can be altered for new frameworks, new sales channels. If new client communication opportunities come along, you add such technology support to your platform, and everything continues to work within the single business logic.

3. You must be careful. That is, for every point of investment in IT, you must have an understanding and assessment criteria that technologies bring you and your business a corresponding advantage. In the absence of such metrics, then sometimes technology can even be harmful. In fact, the team should focus on the product side of the business, understand the benefits of technology and what innovative technologies will be used for.

4. Remember that working with a headless architecture requires a company to have a development team, and an experienced one. Or you will have to sign a contract with an implementation partner (aka system integrator) who will follow you, write down your wishes and do this work.

Flexibility to adapt to future technologies is the most significant advantage of headless. And the business must understand this and use this advantage for their own purposes.

If you have any questions, please contact me at Virto Commerce by email: [email protected].

Make sure to learn from other materials:

Headless Ecommerce Explanation and Platforms Overview

The Ultimate Guide of Headless Approach in Commerce