You are here: / / Frontend Management Platform

Frontend Management Platform

Entry question: Who needs a Frontend Management Platform (FMP)?

Answer: At least all companies that use a flexible API first architecture.

In this blog post, I’ll try to explain the different approaches and the advantages of the API economy. In the last section, I’ll describe what I think are the main success factors for (frontend) projects.

“As little dependencies as possible (but maximum communication) between the individual project participants — in my experience, that’s an essential factor for project success!”

Portrait of Henning

Frontend Management Platform or System?

I’d have to ask the question which has certainly already caused sleepless nights for hundreds of thousands of people, more precisely:

“Frontend Management Platform-as-a-Service” or “Frontend Management System?”

And so that readers don’t have to wait long to be tortured: I would call “Frontend Management System” something from the old world, that’s the on-premise world in which software had to be installed and maintained.

Instead, the “Frontend Management Platform-as-a-Service” (FPaaS in short) is a cloud service. Specialized in managing frontends, various APIs can be docked here. The task of FPaaS is on the one hand to tap into the most diverse content sources, such as eCommerce or Content Management Systems (CMS), but also Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), or Machine Learning (ML) APIs. And on the other hand, it’s about the representation of modeled contents in many different digital frontends. These are, for example, desktop, tablet, and smartphone browsers but also displays at the point of sale or TV apps, and so on.

Frontend Management Platform (FMP) versus Content Management System (CMS)

A classic Content Management System or eCommerce system, as we know it from the past, takes care of content, its structuring, publication, or translation processes if necessary, as well as its presentation on all possible displays.

Originally “on all possible displays” was a simple thing: actually only a browser on the computer monitor. Today, the desktop, tablet, and smartphone alone offer (almost) infinite resolutions. Added to this is the different operation by mouse or finger (touch). Depending on the business model, many more visual, digital user interfaces will be added in the next few years. The frontend, or the output on the most diverse frontends, is today a specialist discipline in its own right.

“For relatively simple, straightforward operations, a classic CMS can be a very fitting solution. However, as soon as content tasks become more complicated or complex, it does usually make more sense to use the CMS system to structure your content while using a specialized Frontend Management System to generate content output.”

Portrait of Henning

Decoupled or headless

This means that many CMS and eCommerce manufacturers have chosen to separate the presentation from the rest (decoupled CMS/eCommerce) or to completely dispense with it (headless CMS/eCommerce). One also speaks of the API first approach. First, the API is developed, and only then a frontend component is developed if necessary.

With a classic CMS or eCommerce system, there’s no need for a Frontend Management Platform. But if I want to take a decoupled or headless approach to work more flexibly and dynamically, I need something that takes care of the presentation, management, and delivery of the content. And that can be a Frontend Management Platform.

As an alternative to a Frontend Management Platform, there’s basically in-house development (see box). Especially the user interface for the content editors or the online team is usually neglected here — although they have the most to accomplish (and suffer) through their daily work.

Some DXP providers also position themselves in this area. More about this later…

IN-HOUSE DEVELOPMENT

An in-house development can make sense if your company has a very unusual business idea or if a large part of the added value is generated by the special characteristics of the frontend.

Otherwise, I’d advise you to think carefully about what it takes to run a frontend platform. We’re happy to help you with a comparison.

Frontend Management Platform (FMP) versus Digital Experience Platform (DXP)

The difference between a Digital Experience Platform (DXP) and a modern Frontend Management Platform (as-a-Service) is somewhat more difficult. This is mainly due to the fact that the definition of DXP is still very young and “fluid.”

But most systems are already rather old: Many Digital Experience Platforms were originally self-contained Digital Experience Systems. So they were originally closed systems (all-rounders/on-premise monoliths) that were subsequently drilled out so that they could also cooperate with other sources such as eCommerce systems and serve as a frontend for them. If you take a closer look at the individual providers, you’ll see that each system has its roots either in content management, eCommerce, or search. However, hardly any of the systems were created as a generalistic frontend for the API economy.

If one compares a Digital Experience Platform (DXP) with a Frontend Management Platform (FMP), the DXP is a rather closed platform, which tries to do most of the work itself and also allows other applications for some services. The FMP, on the other hand, is designed to orchestrate other applications. In addition to orchestrating the sources, its focus is also on orchestrating or managing the frontends, so the digital shop counters.

Moreover, many DXPs are still exclusively available on-premise or in a pseudo cloud (private cloud), which in my opinion has little future.

“For relatively simple, straightforward operations, a classic CMS can be a very fitting solution. However, as soon as content tasks become more complicated or complex, it does usually make more sense to use the CMS system to structure your content while using a specialized Frontend Management System to generate content output.”

Portrait of Henning

Success factors for a Frontend Management Platform

For about 25 years I’ve been managing various IT projects — many internal (as customer or user) some external (as a service provider).

My personal experience from this time is the following:

  1. Simple solutions bring more than those, which can solve presumably all problems of the world.
  2. The fewer dependencies there are in the project, the higher the probability for success.

Simplicity

Short story about “simple solution”: A very good employee of mine successfully fought to replace Mailchimp and introduce Silverpop instead. The functionality was really impressive and the user interface looked the same. After one year she was able to do about what we used in Mailchimp before with the new tool. And we hadn’t fully exploited Mailchimp yet…

What I want to say is: I’m a big fan of getting my feet on the ground quickly and then walking fast and continuously. Software has to help me get to a first live release quickly.

What helps is that the software follows common standards. This applies both to the user interfaces and to the programming standards. Here, too, the wheel doesn’t have to be reinvented — which usually leads to a high level of acceptance among software developers.

“What makes the difference? Not the software, but the people who work with it. And the easier it is to get started with the software and the easier it is to use, the greater its acceptance and the more likely it is to be successful.”

Portrait of Henning

Independence

If I succeed in setting up a project or an architecture in such a way that there are as few dependencies as possible between the people involved and the software components involved, I have — in my experience — a greater chance of a relaxed, successful project.

A service-oriented architecture can help to develop the components independently of each other. However, it’s also important to be able to push technical topics as independently as possible: Design, functions, integrations, and content. I’ve often experienced frustration and delays in projects because the Gordian knot between these areas is too tight and one waits for the other.

A good Frontend Management Platform-as-a-Service can help to resolve these dependencies.

Communication

And last but not least, have everyone talk to each other. A common Slack channel or something similar, where you can also hear what the others are discussing, can nip many problems in the bud. I’m intentionally not talking about “regulated” communication, for example, meetings. I think there’s enough of that anyway.

Agility

Agility is the most common thing that is currently driven by every company. What’s that all about? My credo: “Simple. Start doing.” or in other words “Doing is like wanting, only more extreme.” To put it less flippantly: go live quickly with the 1st prototype and then continuously improve it. And if the 1st version doesn’t fulfill 100%: Better now 60% then in a year maybe 100%. After all, who knows what will happen in a year’s time given today’s market dynamics?

Stay in the loop

Subscribe to our newsletter to keep up-to-date on all the latest Frontastic news.

Related

operational efficiency as metric for headless commerce

Operational efficiency: The future metric for headless eCommerce platforms

,
This blog post explores how operational efficiency will be the future metric for headless eCommerce platforms. If you've moved to headless or are planning towards headless transition then this article will serve as the best guide for you.
Read more

Frontastic architecture: Frontastic studio

,
In our architecture blog series, we'll look at each part of the Frontastic architecture, how it works, and what you can do with it. In this post, we'll focus on the Frontastic studio.
Read more
MACH Alliance Logo