Federated platforms – future-proof content management for the 21st century?

• Content management is evolving to serve up new, demanding content-forms.
• Increasing flexibility in your content management allows you to future-proof your system.
• Federated content platforms allow for much richer content environments.

In Part 1 of this article, we spoke to Michael Lukaszcyk, CEO of Hygraph, about the challenges that companies are already beginning to face when it comes to offering their audiences the content-driven experiences they are coming to demand as standard.

Michael introduced us to what Hygraph calls federated content platforms, which go a step beyond both traditional content management systems, and the more up-to-date headless versions.

The idea of a federated content platform is to at least partially future-proof content delivery, to enrich the experiences that can be offered, and – by no means inconsequentially – to reduce what Michael identified as an “innovation bottleneck” when it comes to building sites.

He was able to identify that bottleneck as existing in the building of the middleware needed to connect the various parts of a headless content management system, which he said was not only expensive, but highly complicated to do, and also, because of its complexity, a potential time-bomb from the moment it’s up and running.

That begged a particular question for us.

Under the hood of federated content management.

THQ:

So – how exactly does a federated content platform work, in contrast to traditional and headless content management systems? What should companies know about it?

ML:

We use Graph QL, which is an API technology that’s seen as an alternative to REST APIs. REST (representational state transfer architecture) APIs are already 20-25 years old, whereas Graph QL is a technology that’s only around 6 years old.

Graph QL is a key enabling component for the federation of content, but what we’re doing under the hood is connecting the APIs that you configure to pull the data together, or make it easy to pull data together.

We also take care of the hosting and the caching, so we’re adding performance optimizations on top. So if one of the components that you’re federating has a slow API response, because it was never designed for exposing into applications that have high traffic or high volumes, (like any old school SAP or Salesforce API), we put a caching layer on top so we can make it perform as you’d hope.

We take away from the operational effort that it takes to build this middleware, but also to host this middleware, because we host, we cache, and we take care of the security aspects as well.

That takes the developer on at least a stage or two from where they currently think they are. Building this middleware by itself is very expensive and hard, but content federation is making complex architectures feasible.

If you have a very small tech team on a very small budget, but you still have the ambition to build a complex architecture for more demanding digital experiences that needs to communicate under the hood with multiple systems, federated content platforms can make that possible.

THQ:

Great. Who’s buying it at this point?

Our user base right now consists of enterprise customers on the higher end, so companies between 500-5000 employees. And then we have self-service tiers, which are more SMB-focused.

With self-service content federation, the people or organizations who buy it usually buy it because they’ve already made the transition to a composable architecture and a modern software stack – where they run into the problems that haven’t been there with monolithic architectures (like traditional content management systems), because they have been integrated. That’s the whole promise of a monolithic architecture, after all – it may be clunky, but at least it’s integrated.

THQ:

And people understand it from a long history of web design.

ML:

Yeah. So I would say it’s forward-thinking companies that are looking into content federation right now, because they think about API first, about cloud native, about modular architecture.

There are two situations. Either they’re considering going from a monolithic to a modular architecture, and they start right away with content federation, or they have built their stack, they’re already on a modular architecture, and they’ve built the middleware, but they’ve found that they’re investing way too much and they have this innovation bottleneck, as we talked about in Part 1. So this is a logical step forward for them.

Content management beyond the Netflix experience.

THQ:

We keep coming back to this idea of a Netflix-type content service. And obviously, that’s a good visual shortcut to the way content can be used without a rigid site architecture, but what sort of additional services does going federated give you?

ML:

OK – let’s stick with the Netflix idea for a second. Think of a movie database that can be federated in. But maybe there’s an external API, like the Internet Movie Database, or Rotten Tomatoes, that has reviews and ratings for the movies, so you can join them together and actually build an experience that doesn’t just present the movies. It also presents the ratings, maybe adds in an ecommerce offering, maybe has a product catalogue of merchandise, tailored to what you’re watching.

Game of Thrones merch for a Game of Thrones fan, all while in the same environment.

THQ:

Let the record show that we have ADHD, and you had us at the point where we could look up the cast members of any movie while it was going on, and find out every other thing they’ve ever been in, and with whom…

ML:

Right? So you can colocate this data and content by federating them in. Also commercial offerings, maybe the digital assets for the movies and series – they don’t even live in the movie database. They live in a digital asset management system, so you can federate them in too.

What you’re getting – or indeed, from the business’ point of view, what they’re delivering at that point is not just the main content that you’d get from a traditional website with a traditional or headless content management system. You’re getting a whole enriched, content-based environment that gives you a much deeper experience of the content.

One of our enterprise customers is a B2B publishing service in the pharmaceutical industry, and what they’ve built for their industry is an industry database for the pharmaceutical and biotech industry. So it’s not a product, it’s a homegrown development database, but it has an API, and because it has an API, they can federate it in.

And then the content they build within Hygraph for their website and for the publications? They can colocate it directly with the company information from their own internal database, and without needing to bring in those services. There are simply two different services. One is the Hygraph content management system, the other is an internal homegrown database – they don’t need to build the middleware anymore to bring it together, they can skip that step –

THQ:

– the expensive, complex, step –

ML:

– And instead, they can just federate it in, and add the distributed data jointly together into their applications.

Future-proof content management?

THQ:

That sounds like a very ‘now’ concept. How can you future-proof a federated content platform?

ML:

The modular stack, or a modern API, can be future-proof for two reasons.

First of all the modularity. If some of the components have to be switched out – say if a vendor goes out of business – in a modular stack, you don’t have to switch out the complete stack, you just switch out that particular vendor – for the CMS or the PIM part, or the personalization, or the search.

Or say there’s a new search vendor that has AI capabilities, on top of the capabilities of the vendor you’re currently using. You just replace that element and keep on trucking – which is about as close to a definition of future-proof as we’re likely to get.

In general, I would say API-first offerings are more future-proof as hatful services, like page builders, because the front-end ecosystem and technology landscape is much more short-lived than the back-end ecosystem.

So, every two years, you’re looking at a complete turnaround of how you want to build front-ends. And because they’re detached from the back-end, because you have an API, you can simply switch the front-end stack to a new technology to which all of the developers have migrated their interest.

THQ:

That sounds like a kind of flexibility that could well become a new normal. Especially with some of the new technologies like generative AI and AR/VR, people are going to expect this sort of thing as a norm, aren’t they? That there’s always going to be “extra” depth to their experiences?

The federated nuts and bolts.

ML:

Yeah, we think so. It will be the new normal. And what I’ve always found intriguing about the headless CMS idea itself was the sustainability and the durability of the product model. With federated content platforms, whatever the next big thing is, say if AR/VR becomes a thing with the new Apple glasses finally, then you’re already set. And you can build a front-end product for this platform with the content that is already there.

So what you get with federated content platforms is that kind of future-proof sustainable content strategy that more and more businesses are going to need.