The Times Digital Transformation Programme
Part 1: The Business Case
In this article, I describe the business rationale and processes that triggered a transformation programme to rebuild the platform that serves our digital content. I describe how The Times has innovated for more than 200 years, the growing importance of digital consumption and why we realised the need to rebuild our platform. I also explain how we are making a success of a programme of scale.
This article is part one of four:
Part 1: Our business rationale and processes
In this article, I examine why we have taken on such a large, complex and challenging project. What are the business benefits? What are the key challenges? How did we get buy in?
Part 2: Choosing the technical approach
Part 3: The technical implementation
Our print history meets the digital future
The word ‘innovation’ might not spring to mind when you think of a newspaper that started life in 1785, long before iOS was a twinkle in Steve Jobs’ eye. In its 233 year history, The Times has a number of firsts to its name in editorial, production, typography, distribution, technology and more.
For instance we have been early adopters of new print techniques since the nineteenth century, our print room was one of the first places in England where electric light was in permanent use and we were the first newspaper to offer home delivery. Here are a few of our other innovations, some of which seem technologically underwhelming now but were amazing at the time:
Building for the future
We are still innovating today and are seeing a growing digital readership on top of a solid print distribution. But what of the future? Where are we going, what innovations will come and does our current technology platform enable them?
We have bold plans for delivering amazing content in new and interesting ways, mostly — of course — via digital channels. For example, our editorial teams create rich, interactive, dynamic, data driven features to support major events like elections and The World Cup or simply to make today’s top story easier to digest. Depending on their complexity, these can be created and released in a matter of days; often quicker.
Our immediate vision is that our editors can freely create this content and it is quickly, easily and seamlessly rendered however our readers choose to consume it; be that web, tablet or mobile. The tech stack and processes that enable and support this must be unobtrusive, simple and easy to support.
We know for sure that we are not delivering on this objective right now. Not all of this rich content renders on our apps, so our tablet and mobile readers are missing out relative to our web readers.
There are reasons for this. Our current ecosystem has emerged from years of embellishment to our print platform, which was not designed for digital consumption. The systems and processes have been adapted to accommodate digital, but we have arrived at a place we would not have designed.
We want to do more now than we did in past years. Our systems, technology and codebases have become fragmented. The editorial processes, products and — importantly — user experience are not consistent across all our distribution channels.
We decided to fix that.
Deciding to rebuild
We decided that it’s time to stop evolving legacy systems and build new tools that can take us well into the future. The Replatforming Project was born.
Programme objectives
The overall objective of the programme is to provide a platform that enables the editorial team to publish digital content without needing development resource. It would be a platform onto which features could be added, rather than a product constructed with a feature set.
We will know we have delivered on this when:
- We offer a consistent user experience however our digital readers access our content.
- We have a seamless platform that enables the digital editors to create and publish their interactive features everywhere, uniformly.
- There is a consolidated, unified and rationalised technology stack that enables this and allows true cross functional development.
When complete — apart from removing heaps of legacy systems — we will also have reduced thirteen codebases to three. This is:
- So much easier to maintain and build on.
- Makes changes simpler and faster.
- Reduces time to market dramatically.
Going JavaScript
After analysis, investigation and proofs of concept we decided to use a JavaScript stack; principally Node.js and GraphQL at the back end and React Native at the front end.
The solution revolves around a library of components built in React. The components can be mixed and matched by digital editors to create the content safe in the knowledge that the final output will be published consistently to the web, Android and iOS — including the interactive features they build themselves. From a technology standpoint this means we can write code once and know it will render correctly to multiple platforms.
It’s a big project and it’s not easy
Replatforming is a huge task, estimated to last for more than a year and it will continue to evolve well into the future. This is a serious investment in our digital future and is a major commitment by the company.
It’s not easy either. Apart from Facebook (who built React Native) we are one of the few (the only?) companies to try this. We do not have the luxury and freedom of writing something from scratch. We are progressively migrating an existing disparate product to one codebase that delivers content natively to web and mobile.
Every day we are discovering that working with React Native web, in particular, is challenging because it is relatively new and still forming.
The benefits
There are clear technical, process and product benefits to this work, but there are other less obvious ones too. For example:
- The engineers are learning new skills and conquering new challenges, some of which no one has faced before.
- It has brought about new and improved ways of working.
- It has strengthened the relationships between technology, the editorial teams and our other internal customers.
- We are rationalising our technology estate, removing or consolidating legacy apps and services that we can now do without.
This all adds up to a more productive, efficient and effective organisation that is well positioned for the foreseeable future.
The opportunity cost
It also comes with opportunity cost. As we are focussed on rebuilding the platform we can’t respond to normal requests for feature improvement. Only really important changes are being considered during the programme; that was a key part in securing the project’s success. As a result, we are not diverted and distracted by too many BAU requests.
How we are delivering the programme
As with any replatforming project it’s a hard sell to spend a lot of time and money to end up with a site and apps that are — at some levels, at least — exactly the same as they were. Making sure we replatform in a way that provides business value in terms of cost reduction, time to market and better user experience is paramount.
To get the programme off the ground we scaled up the product, delivery and engineering teams. The tech stack was partly chosen because it uses a standard set of coding skills and this allows us to form and reform truly flexible, properly cross-functional teams. Although it’s a fairly rare skillset, it does make hiring much more targeted.
Ways of working, agile and pods
We fully adopted agile to improve productivity, transparency and flexibility. We moved to a pod system, where sprint teams are formed, dissolved and mixed up frequently to deliver features quickly and consistently. As each pod nears its feature completion we start to form the next pod and undertake sprint zero activities. In practice, the core of each team has stayed fairly well intact, but there has also been a lot of portability between them. Pods allow us to respond rapidly to current needs.
Keeping things on track
The replatforming programme feeds directly into the company’s wider goal of reaching target subscriber levels. Our contribution is streamlining the creative processes, improving the product and making sure we can scale. We have set internal programme objectives and measurable key results to ensure we are delivering on our commitment. We hold daily and weekly meetings between the product, delivery and engineering teams who are responsible for the programme to review progress against these OKRs.
At a higher level, the Product Leadership Group, Times Newspaper Limited and the Senior Leadership Team sync ups allows the business to be kept up to date with the streams of work delivering the replatformed product.
Progress so far
The first third of the project has been very low level; designing architecture, refining technologies and building better ways of working. We have done a lot of exploring and learning, as well as setting up repos, coding standards and technical requirements.
Much of what we have delivered is behind feature flags, or not immediately obvious to the business. So far, we have built large parts of a new public API to serve content, based on GraphQL. We have internal end points for writing and updating content too. We have a growing library of React Native components and we’ve begun to deliver some parts of the site into the products. All of our components are open source.
We are now into the middle third of the programme, emerging from the deep dive technical phase and starting to deliver value that the business and our users can recognise.
The final phase will be embellishing the product, adding and migrating the final set of features and reacting to change requests from the earlier phases.
In truth, this programme does not have a set end date. Of course we have a timeline and we know when we will be ‘done’ with the transition, but we are building a whole new platform that will take on a life of its own. It will grow and evolve well into the future; and who really knows what that will look like? Technology changes rapidly and often. The replatforming programme gets us ready to respond to that change.
How do you make a success of something as big as this?
In the good old days, this would have been a two year waterfall project and would almost certainly have failed. What the business needs at the end of the project is completely different to what the business wanted when it started.
So thank goodness for agile! Agile believes that each sprint delivers fully tested code that adds value. Our primary challenge with this is that we are rewriting lots of systems and there isn’t a gradual transition where we can deliver constant business value.
But we can eat the monster one bite at a time, and by doing regular reviews and having constant dialogue we can be sure that we are still doing the most important thing almost every day.
Our sprint demos show progress and future value. We have delivered quite a lot of code into production behind feature flags, and some product features have been completely rewritten and delivered even if it’s hard to see the difference.
Keep an eye on true north
We are finding that the key thing is to have a persistent view on true north. What are the key objectives of the project? How will we know when we have got there? What are the benefits of doing this work?
This is so important because two years is a long time, especially when the first year makes no tangible difference to the business. It’s easy to lose faith and question the investment, unless there is a common understanding and commitment to true north.
I won’t say that this is easy. There are always questions about what the project team are doing, and even the team itself loses focus now and again. But bringing everything back to basic project principles, regrouping and heading back towards true north makes everything keep moving towards that finishing line. And we are getting there.
The technical solution
In the next article I dive into the technical implementation and challenges faced.
Be sure to follow us on Twitter for future announcements.
We are open source
We open sourced the repo, a first for News UK. We auto-publish to public npm on merge to prove out the CI/CD culture with open source CI such as Travis and Coveralls. The backend has a threshold of 100% test coverage with the front-end currently running at ~96%.
