Credit: Dreamstime
In 2012, digital subscriptions at the Financial Times surpassed those of print for the first time. The transition to a digital-first approach that followed allowed the newspaper's IT team to provide readers with new videos, interactive graphics and podcasts, but their monolithic architecture was struggling to keep up.
Code and data were tightly coupled in a relational database, which required developers to strictly structure the data used in their applications and limited their ability to experiment with new digital services.
The FT adopted micro-services architecture to structure its applications into independently deployed services.
This made it easier to release and iterate and replace and decommission when required and devolve decision-making to the teams doing each job, but it created maintenance problems when priorities changed and staff moved to different roles.
"Like a lot of other companies, at the FT a lot of important stuff runs on bits of tech which are are quite old, and built by people who either have left the company or have different responsibilities at the company now, and it's sometimes not documented particularly well," Rhys Evans, principle engineer at The Financial Times tells Computerworld UK.
"We decided that to tackle this we needed to first establish what we had, who was responsible for each bit, and make sure they looked after it properly and document it properly.”
They turned to the to the Neo4J graph database platform databases to work all this out. The system allowed the FT team to model complex relationships between data without the need to simplify it or lose important details, while providing greater clarity on who the stakeholders were.
When the IT team create a system, they pick a unique, human-readable code, remove any infrastructure that's not tagged with that code, and connect the system record to a team in their graph.
They can use this to give an organisation such as Barclays a unique identifier and then connect it with other information from different systems.
To make it easier build full stack graph applications, the FT has alos been using GRANDstack, a framework that combines the Neo4J native graph database with the GraphQL query language and the protocol for APIs, the Reach JavaScript library for building component-based user interfaces, and the Apollo suite of tools to create better GraphQL workflows.
"In the more traditional databases, you have to connect everything to everything directly, and that's a lot of links to maintain," says Evans.
"Whereas graph databases can connect through an intermediary node, which means that although all the connections are still there you don't have to maintain each one so carefully, and it's a lot easier to manage."
Graph creations
The FT has used the graph database to launch a new website as well as the personalised myFT section that makes article recommendations.
The publication has also used Neo4J for more experimental storytelling methods, such as six degrees of Angela Merkel, which shows the connections between people featured in the FT.
The graph database has also proven to be popular with staff. The system's simple diagrams are far easier to understand than other languages for modelling. It also helps the company comply with GDPR by providing a cleaner record of where data is and who is responsible for it.
The FT's different IT teams are now more empowered to make their own decisions, improving both business results and staff satisfaction.
"It's now got to the point where pretty much everything is attached to a team that’s responsible for it," says Evans. "Before we had an awful lot of stuff that was just abandoned. Graph has helped a lot with that."
