On architecture, 2nd post: Desking of NRK Radio

The first post I wrote on architecture is really abstract, vague and lacking of context. In this blog post I will discuss the principles of alignment between problem space vs solution space, autonomous teams and how strategy should be the driver for architecture. Instead of being general I will discuss a recent case-study from NRK Radio.

The domain

The term desking, as we use it in NRK TV and Radio, is the editorial presentation of programs and series on the front-page of tv.nrk.no, on smart TVs, on TV and Radio apps etc. It is where we manually recommend to our audience (viewers and listeners) what to see and hear on TV and Radio. This capability of letting our audience discover our content definitely belongs in the core domain. Other, related subdomains serve similar purposes, such as personalized content, recommendations and search, but are not part of desking and I will not go into these in this post.

Before

The current desked content is a list of programs as shown in the application below:

After

One of the missions in the product strategy is to enable the discovery of our content. Based on user-insight, a concept was defined and the first iteration of “Oppdag” (Discovery) on NRK Radio was defined: to be able to serve up a page that organizes content by different “modes” from the listener’s perspective.

The new solution of discovery as implemented:

via GIPHY

(This functionality is currently available on Android and iPhone, please check it out in the app store:
https://itunes.apple.com/no/app/nrk-radio/id401928833
https://play.google.com/store/apps/details?id=no.nrk.mobil.radio )

Complex systems

From the cynefin model, we can argue desking is a complex problem. It requires interaction with people doing the desking and the listeners that are consuming the content. When people are involved consequences are seldom known up front. We need the capability to iterate after having gathered insight on how the new concepts are being used in the wild. This capability for iteration calls for autonomous teams and a system with clear boundaries.

How similar is desking for viewers on TV and listeners on Radio really? Before this project started, the two concepts were identical. All we know is that it would be nice if they could evolve in separate directions if it turns out they are not as similar as we thought. However, if they are similar, it would be nice to be able to have a common system in place. We do not know this upfront. One possible strategy is to try out something new for radio first, and then independently start working on concepts for TV and see how well they match. However, even a good initial fit does not necessarily mean that they will evolve in the same direction once we start iterating and improving. Whether or not desking on TV and Radio is the same problem domain with one solution, or two problem domains requiring two different solutions is a decision we would like to postpone.

Implementing desking for radio

So far we have only been mentioning strategy (defining desking as core domain, defining capabilities) and UX (how should a first version look). Regarding architecture and implementation, the story is more complicated. Let us look at how to implement it.

Now, if we had perfect alignment between problem space (desking on radio) and the solution space (a system dedicated to desking and exposing desking to clients), making the required changes would not be that hard. We already have an autonomous team for NRK Radio that could handle all the required changes. Unfortunately, in dealing with legacy, this is seldom the case.

The desking as it was before was only based on categories, which tied to other metadata about the programs. This means changing desking can not really be done separately from changing the structure of the program catalogue. This hard coupling between the catalogue- and the desking domain can be challenging when experimenting with desking.

The system that handles metadata also handles distribution of media files to CDNs, merging metadata for programs and series from a variety of production systems. Also, it treats radio and TV as the same concept. This means that changing the concept for Radio will also affect TV, which might make changes harder to do and require more coordination between teams.

There is also the case that the monolithic application that deals with this exposes its data to a monolithic API by database integration, so changes required schema changes that must be synchronized across relatively large applications.

We see that the current problem space – solution space mapping tells us that we need to make some changes to obtain properties such as the capability to iterate fast, to make independent changes without consulting the TV team etc. (For an explanation of sub-domains and bounded contexts see http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/)

As discussed in the previous blogpost, I believe good architecture discussions happen when they are driven by strategy. When our system architecture is hindering effective implementation of the strategy, the architecture must change. When we identify a core domain trapped in a larger system, that is shared between teams that require autonomy, ripping out the subdomain and re-implementing it in a smaller system owned and maintained by a single team seems like a good way forward. Using the strangler pattern, we can gradually phase the old system out.

Solution

The solution we ended up with was a simple desking tool with a simple mission statement was built by a small team, with backend/frontend devs and UX in the same team. The total time building the new API, new desking tool, adapting the Android/iPhone clients was approximately 3-4 months to production. Changes in the application is visible, hopefully this gives some insight to what changes on the inside of the organization as well and the thoughts behind it.