Four principles that guided Fitch Ratings’ move to an API-first content platform

Published on May 12, 2022

Four principles that guided Fitch Ratings’ move to an API-first content platform

For more than a century, Fitch Ratings has been a global leader in the credit rating business. By 2019, we had continued to expand our media offerings to keep up with evolving demands for digital content. But we were still struggling to deliver the experience that our customers expect.

You could see this by looking at the website and other digital touchpoints, but the real problem lay underneath, in our content strategy and the tooling used to support it. 

Originally, the Fitch Ratings website was designed as a content marketing tool. It used an editorial approach to delivering content. We wanted to evolve this to become a brand showcase to market our business and drive sales of our primary product: credit ratings. This involved increasing engagement with our primary audience by offering a personalized experience, where we know the user and selectively surface content and messaging throughout their visit.

To achieve this, we needed a full transformation of our content architecture. We set out to restructure information across the business so we could present a unified, programmatic, and targeted content experience. 

We knew that moving from a monolithic CMS to Contentful was a very good start. This would free us from the restrictions of our legacy technology, reduce overhead, and be easier for internal teams to manage and scale.

But we also knew that building out the rest of our content architecture wouldn’t be so simple. The system would need to satisfy the requirements of internal groups, like marketing and IT, while remaining true to our vision for our customers. 

We found success by working with Contentful partner Appnovation, and sticking to four core principles — what we called our “lighthouse” — through the project. These principles helped us build a robust and flexible platform around Contentful to meet all of our requirements.

In this post, I’ll break them down for you.

Principle #1: Security by design and default

Fitch Ratings operates in a regulatory compliant space, so security isn’t optional. Ten to fifteen years ago security was “nice to have.” Now our industry demands it.

Ensuring high security for our new architecture meant we had to consider the issue from a number of angles: Our technologies need to provide network security, user information security, and even content security. Every product we use has to meet our strict security design goals. 

And all the layers of our architecture need to be secure by default. That way, it's not up to the user to opt in, and everyone can count on high security in their interactions with us.

Principle #2: High speed, while still being relevant

We knew that our website was going to be media-heavy, but we didn’t want that to affect the user experience. A slow user experience is bad for customer interaction, and this is reflected in research. Every time you increase the delivery speed of your content — even by a few milliseconds — your conversion rate doubles.

Another reason we prioritized speed is that our customers are distributed around the globe. Fitch Ratings has customers in Asia, Europe, Oceania, and every other place that you can think of. Our content is hosted primarily in North America and China, so we needed to take extra steps to deliver quickly everywhere in the world 

But the content can’t just be fast, it also has to be relevant. We are a rating business, and that means we can’t cache all of our media. If we did, a customer might access a piece of content and find out-of-date financial analysis. 

Our architecture needed to cache what could be cached, and then quickly deliver what couldn’t be cached. We needed to strike a balance.

Principle #3: Assimilate information-as-a-service

When we say “information,” that could be content, data, infrastructure, or any other part of the architecture. This principle says that whatever technology we need to make our platform work, it should be available as a service.

These services couldn’t be fully integrated into the architecture. Since technology and companies evolve, the service that’s best today may not be best tomorrow. The context can change, so our platform will need to be nimble. 

The aim was to build our core architecture to enable plug-and-play services. That way, we’d ensure that our platform always used the best technology for the job.

Principle #4: Auto-healing and auto-scaling infrastructure

Essentially, this meant that our infrastructure needed to be cloud native.

But to explain why we needed auto-healing infrastructure, let’s say we have a DDOS attack us on our services. And we were able to put in some measures to address that. But before those measures kick in, the infrastructure might slow down.

Self-healing infrastructure can help with this. When we isolate and address the DDOS attack, this infrastructure would return to its normal state automatically.

Autoscaling is a simpler idea. It means that when our platform experiences a sudden spike in activity, it can scale up to handle the load without degrading our customer services. That way, our customers can always have a smooth experience.

How Contentful helped us align with these principles

Moving from our monolithic CMS to Contentful's headless CMS helped us simplify editorial operations and build a unified content experience for our customers. But that’s not all it did. The API-first approach also enabled us to build out a Jamstack architecture that satisfied our four principles. 

We built an API layer on top of Contentful where we selected services — like a GraphQL API and React-based server-side rendering — that were plug-and-play with our basic architecture. That made it easy to achieve our goals for engineering, security, auto-healing, and auto-scaling.

This approach enabled us to balance our customer’s conflicting demands for speed and relevance. With our current architecture, the internal teams can create a static version of the site and build it multiple times a day to ensure fast loading. Only the most time-sensitive content is loaded on demand. 

Contentful also helped us with the website’s speed by serving imagery much faster. We used the image optimization techniques that are available by default to configure different viewpoints, select different device types, and optimize imagery in other ways. Now, we can serve them with the content for our various mutual funds, and make the site even more efficient for our customers.

Contentful’s headless CMS and its easy API-first approach made it possible to build a high-fidelity, highly secure infrastructure that is flexible and fast. With our new website, we’re able to meet all of our internal requirements and deliver customers the unified content experience they’re looking for.

Curious to learn more? Read our case study about how Fitch Ratings enters into a sophisticated digital age with Contentful and Appnovation.

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.

Related articles

How the Hydrow engineering team are using Contentful. Next.js and Vercel to provide a richer experience for their editorial team (and their customers, too).
Insights

It just works: Hydrow’s instant publishing workflow with Contentful and Next.js

July 13, 2023

Contentful enables content creators to structure content as building blocks. Define an author, recipe or blog post structure with a few button clicks.
Insights

Structured content: Make stronger, scalable websites and apps

March 15, 2022

This post explains the difference between CMSes and DXPs.
Insights

What’s a digital experience platform? Get the scoop on DXPs, CMSes and where content platforms fit into the modern stack

July 12, 2021

Contentful Logo 2.5 Dark

Ready to start building?

Put everything you learned into action. Create and publish your content with Contentful — no credit card required.

Get started