Skip to main content
Robert Taylor

Common Platform and Services - Project Report

•
#project management #systems thinking #enterprise architecture #team structure #agile

A reflection on the progress made with an initiative to simplify how ITV exposes its descriptive metadata from source business systems.

Common Platform and Services: Project Report

Author: Robert C. Taylor
Post Date: Oct 08, 2014 1:54:56 PM

Abstract

Purpose – The purpose of this paper is to reflect on the progress made with an initiative to simplify how ITV exposes its descriptive metadata from source business systems. The initiative has involved several stages, multiple stakeholders, many leadership and management challenges, and plentiful learning opportunities for the author.

This paper shows how organisational structure, team composition, and a project mindset influence a team’s ability to deliver successfully.

Design/methodology/approach – The paper is based on the author’s personal experience throughout the initiative, illustrating learning opportunities and proposing practical solutions to challenges inherent in leading and managing teams in software delivery projects within large organisations.

Findings – The report demonstrates the strong influence of organisational structure on solution design, highlights the challenges of forming cross‐functional teams in organisations dominated by functional silos, and discusses the implications for software delivery. It poses significant questions regarding the need for organisational change when tackling such endeavours and proposes changes to the way teams involved in software, platform, and infrastructure delivery are organised.

Paper type: Viewpoint

Introduction

Background

In August 2010, ITV announced a strategy to transform the business over five years. The vision was to create world-class content that ITV could showcase on its channels and then exploit the content’s value across multiple platforms—both free and pay—in the UK and internationally. The transformation strategy was based on four key strategic priorities:

  • Get Fit
  • Maximise Free to Air
  • New Revenues, New Platforms
  • Build an International Content Business

This strategy was further supported by several new working principles:

  • Become embedded in the business, be much more visible, and develop relationships of trust.
  • Communicate in plain English.
  • Put more emphasis on fixing the basics.
  • Devise the best solutions for ITV without having to build everything internally.
  • Maintain a constant focus on simplification—both within the Technology function and for the organisation as a whole.

ITV Organisational Structure

ITV, like many large enterprises, is characterised by a bureaucratic organisation structure. As Mullins (2009) describes, individuals are grouped around a Major Purpose or Function—in other words, specialist departments exist in silos. For instance, the skills required for a software delivery project are typically split across:

  • Commercial and Online: Product Management, User Experience Design
  • Technology: Business Analysis, Testing/QA, Operations, Infrastructure, and Software Engineering

Often, these specialists only come together temporarily for projects where the primary means of communication is via documents and email.

While this form of grouping can reduce costs and increase resource utilisation, it also impacts software design and delivery. Projects are often considered finished when their initial requirements have been met—even though continuous software evolution is required as underlying components (operating systems, programming languages, libraries, etc.) are perpetually evolving.

Organisation by Major Function

Within ITV’s Technology Division, there are three primary Major Function departments providing the necessary skills for day-to-day software operations. Although these formal structures optimise local operations (similarly to shared legal or HR services), they can lead to a sub-optimal outcome when viewed holistically at the business level.

Organisation by Service or Product

An alternative model is to organise work by Service or Product. This shifts the focus to a single team that handles all aspects of the Software Delivery Lifecycle (SDLC) instead of pulling required skills from various specialist silos. However, this approach may be constrained by the existing organisational structure, traditional project mindsets, and inertia in operational strategy.

Hybrid of Major Function and Product/Service

A hybrid model is often adopted in organisations striving to implement agile software delivery. In my experience at ITV, this change emerged organically in 2011/2012 by amalgamating the Software Development and QA/Software Testing teams into a single Engineering capability. This cross-functional team structure now primarily serves the Online division.

ITV Online

ITV Online focuses on delivering an exceptional user experience for ITV’s content via the ITV Player products. Aligning with the rebranding efforts, the strategy centers on deepening the relationship between ITV and its viewers.

Weekly performance metrics for the Online business include:

  • The number of Long Form Video requests (across 7 ITV Player products).
  • Consumption hours per platform.
  • Unique client numbers.

These metrics drive advertising revenue, where more screen availability means more users, and consequently, higher revenue through pre-roll and mid-roll advertising.

Online Simplification

One of ITV’s modernisation programmes, funded in 2013/14, was aimed at simplifying the technology estate for ITV Online. The existing technology platforms and accompanying operational processes were too cumbersome and costly to deliver new ITV Player products quickly and efficiently. As a result, the Online Simplification Portfolio (OSP) was established to manage and fund projects that specifically address these challenges.

In my role as a Solutions Architect, I focused on the challenge of simplifying the way descriptive metadata is exposed and consumed by ITV systems.

Situation

Over three years at ITV, involvement in numerous projects delivering and enhancing ITV Player products provided deep insights into a complex technology estate that spans the Online business and beyond. This complexity is compounded by:

  • Interdependencies among various internal systems.
  • High staff turnover leading to a degree of corporate amnesia.
  • Organisational silos that impede holistic problem-solving and learning.

Such issues raise the broader question of how organisational structure shapes individual behaviours—and by extension, the choices made within the business. As famously noted by Drucker, culture may be as important as strategy. Einstein’s remark that “problems cannot be solved with the same thinking that created them” further underscores the need to break away from silo-based thinking.

"Nine Dots" Puzzle

The classic 'nine dots' puzzle—a task in which all nine dots must be connected with four straight lines without lifting the pen—symbolises the necessity of broad thinking and is a constant reminder not to restrict problem-solving within established paradigms.

Problem Statement

ITV’s descriptive metadata, which includes Programme Catalogue, Rights, Licence, and Schedule data, resides in core business Source Systems of Record (SSoR). These systems, though interdependent, are developed and operated in isolation. Data is traditionally moved through export, transform, and load cycles into multiple downstream systems. This method of working:

  • Obscures responsibility for the data.
  • Blurs control between the business and IT.
  • Leads to multiple, sometimes inconsistent, representations of the same data.

Heavy reliance on manual testing, split responsibilities across teams, and a backlog of change requests have rendered these SSoR systems risk averse and slow to change.

Relevance to Online Simplification

I believe that the complexity of ITV’s Online technology estate stems directly from the issues mentioned above. Addressing these challenges requires looking beyond just the Online division and taking a strategic, company-wide approach.

A key part of my task was to better understand, explore, and share the broader problem context to gain support and sponsorship for changes that extend beyond the Online business.

Flow of ITV’s descriptive metadata between SSoR and Online systems:
(Diagram or visualisation placeholder)

Approach

To gain support for my proposal, I identified and engaged the right stakeholders through a mapping exercise that plotted their influence versus interest. This enabled me to prioritise engagement efforts and refine my proposal through one-on-one meetings and group sessions, including OSP Senior Stakeholder Meetings.

Proposal

Objective:
Enable ITV Player client applications to obtain descriptive metadata directly from the SSoR via an API layer, thereby simplifying the data flow and reducing complexity.

Controversial Element:
The proposal called for extracting data directly from legacy SSoR systems (such as Paris and Generys, which are nearly 20 years old and widely used across various ITV divisions). This was meant to challenge the status quo and stimulate rethinking of current practices.

Long-Term Vision:
Develop domain-specific services (APIs) around each core business system. Initially driven by a specific ITV Player Use Case, these APIs would eventually become the standard method of data exchange across ITV’s ecosystem.

Personal Development

The process of pitching the proposal to senior stakeholders was a significant personal challenge that expanded my presentation skills and network within ITV.

Online Simplification Proof of Concept

Hypothesis

ITV's metadata can be made available from the SSoR through a set of APIs. The PoC was designed to test whether exposing this metadata via APIs is a viable solution for a new ITV Player client.

Client Selection

We started by listing all existing ITV Player clients:

  • iOS
  • Android
  • PS3
  • Samsung
  • YouView
  • Dotcom
  • Freesat
  • New HTML5 Smart TV Platform
  • Responsive Web PoC

Selection Criteria (Ranked):

  1. Expected Frontend client resource cost
  2. Resource availability
  3. Existence of the client
  4. Whether the client is already API driven
  5. Alignment with strategic technology stacks (e.g., Native vs Adobe Air)
  6. Client/frontend change complexity

After discussion and a quick vote, Android was chosen as the client for the OSP Pilot.

Success Criteria

The PoC was aimed to verify that:

  • Integration with ITV’s core business systems (to extract Programme Catalogue, Licence, and Schedule data) is viable within a three-month period.
  • The new API-driven approach delivers:
    • Reduced data acquisition times.
    • Smaller payloads and improved client performance,
    • Ultimately lowering the Total Cost of Ownership (TCO) for the Online estate.

Additionally, personal learning outcomes were set to:

  • Deepen understanding of ITV’s core systems and cross-team collaboration.
  • Demonstrate the benefits of a cross-functional product team versus traditional project-based delivery.

Team Structure

A small, focused cross-functional product team was assembled with the following roles:

  • 1× Front End Software Engineer: Android Client UI
  • 2× Software Engineers: API Services and Build Pipeline
  • 1× Developer-in-Test: Automated Testing across UI, Services, and Platform
  • 1× Operations Platform Engineer: Build Pipeline, Platform, and Infrastructure
  • 1× Product Owner: Vision, facilitation, backlog, and budget

This co-located team structure reduced communication overhead and accelerated decision-making.

Delivery and Agile Approach

Agile Methodology

The project used an agile approach—a blend of Scrum and Kanban—to manage both discovery and delivery. This iterative method provided:

  • Continuous feedback through planning sessions, demos, and retrospectives.
  • An evolving backlog where high-level Epics were decomposed into smaller, manageable User Stories.
  • High visibility via a physical Kanban board with defined work stages and Work-In-Process (WIP) limits.

Planning and Collaboration

Key practices included:

  • Planning Poker: For estimating effort using a Fibonacci scale.

  • Behaviour Driven Development (BDD): To define test scenarios that could be automated (using tools like Cucumber). For example:

    Scenario X: Title
Given <some context>
And <some more context>
When <an event happens>
Then <I expect this outcome>
And <this other outcome>

Retrospectives

Held after each iteration to discuss what worked, surface issues, and generate actionable improvement items. This process supported “double loop learning” (Argyris, 2002) through continuous inspection and adaptation.

Outcomes

Within three months, the team successfully delivered a version of the Android ITV Player application that sourced its data from the new PoC API.

Learnings

Although the PoC was deemed successful, several challenges emerged:

  • Scope vs. Budget:
    While I was responsible for the scope and vision, I did not control the project budget. This separation sometimes led to challenges when escalating requirements without a corresponding financial check.

  • Cross-Functional Dependencies:
    The co-located team greatly improved collaboration between development, test, and operations. However, dependency on the Infrastructure team—organised as a separate functional unit—remained a bottleneck.

  • Organisational Impact:
    Optimising at the departmental level can undermine the overall product offering. These learnings continue to inform ongoing improvements across ITV.

Next Steps

Following the PoC’s success, senior management has endorsed this API-driven approach to simplify ITV’s Online technology estate. The immediate next phase is to develop a new ITV Player reference application for Samsung Smart TVs, which will:

  • Build on the PoC outcomes to refine metadata exposure.
  • Consolidate build, test, and deployment processes.
  • Establish cross-functional product teams as the standard mode of delivery for ITV projects.

This marks a significant departure from traditional project-based delivery at ITV and opens the door to similar initiatives across other parts of the business.

References