The Client

Project Name
Technical Feasibility & Scoping Project
Draft 2.0

Background Objectives Project objectives A new direction for the The Client service A platform for good Platform legacy Project activities and deliverables Teams and Roles Key dates Scope of technical feasibility Legacy Proposed solution User journeys Technical architecture Next steps Immediate next steps: Alignment and planning Planning beyond the next 2-3 weeks Dependencies Appendices

3 3

4 7 8 9 19 21

26

28

Background
Objectives
Project objectives Translate an epic vision into a high-level service proposition and technical design that can be planned and estimated, designed and delivered. At the core of the vision is an unprecedented live event to raise a Project Name dollars for charity, the Red Cross, and reach a Project Name people on the day. A new direction for the The Client service Launch a new capability to position The Client as a highly desirable future entertainment partner for cause-related streaming at live events. It was initially envisaged that The Clients existing technology platform could be used to deliver the live event. A platform for good Harness the power of The Clients technology platforms for doing good, social innovations and cause related marketing. Platform legacy Create a platform legacy of re-usable components and technology capabilities that feed back into the platform roadmap, including services such as virtual ticketing, authentication and payment. A rich social database of fans and payment details & behaviour. 3

Project activities and deliverables

The project involved 4 key strands of work: 1 - Vision/Discovery An all-day workshop with VDIO, and briefings, were used to confirm and develop a shared understanding of the projects objectives, key technical challenges and scope. Within the workshop we built the experience from the bottom up from a baseline experience - by walking through the major technology components. We looked at two layers of enhanced functionality and experience on top of these (Baseline +1 & Baseline +2) We also summarized the major themes of user experience across the whole programme from the top down. Both of these diagrams are provided in Appendix 1. Activities: Workshop, sketching Deliverables: Diagrams: shared vision of how the experience works and what the priorities are

2 - Service definition Using the output of the workshop as a starting point, we then began to compile user journeys of the key interactions and touchpoints between the system and the user mapping and developing our understanding of how people would be engaged by and brought into and through the experience and service before, on the day and afterwards, across multiple platforms).

User journeys provide a user-centred, first person and customerdriven way to develop the total experience from multiple viewpoints and to develop consensus about what is to be made and artefacts that inform technical design. Within the tight timelines of this project, it made sense to work at the lower end of fidelity into more detail. With each of the five iterations of user journeys weve worked through, we started with a script that was reviewed by stakeholders/team before being worked up as thumbnails and ultimately into the finished user journeys attached as appendix 2 of this document. We've used these artefacts to develop a shared vision of the user experience (i.e. what is a desirable experience?), but also to inform our understanding of what is feasible, and what can then be estimated & planned. Within the final Keynote presentation to The Client, we also used the user journeys as an over-arching narrative around which to overlay the comms/activation story and structure our explanation of the technology platform story and components required to deliver each phase of before, during and after the live event. Activities: Workshops, sketching, developing ideas iteratively in review with partners and The Client Deliverables: Sketch user journeys (appendix 2)

3 - Technical design Working from feeding technical feasibility of initial ideas back into the service definition and then determining the composite parts required to delivered the solution at the scale required. This includes a high level design of the system architecture at different 5

phases and the required processes and hardware estimate to deliver it which feeds into cost estimation. Activities: Workshops, technical analysis, research Deliverables: Candidate system architecture, planning

4 - Cost estimation High level cost estimates of the digital components that would form the service. Includes a break-down of software design and development, supporting resources and services and an infrastructure cost for delivering the scale predicted.

Note: The original proposal envisaged that we would get more involved with partners and overall programme planning, which has not been the case at this stage. Whilst we have been able to meet with VDIO, with Hatef, and to talk GroupMe through the proposition it has not been appropriate or possible to engage with the wider stakeholder group, including AEG, The Red Cross etc. We would now see this happening at the next stage.

Team and roles

A combined team of The Client, The Agency and Support Ageny delivered the project: Name Seema Johnson Jacqui Lee-Joe Gary Bramall Deji Odulate Nathan Cooper Sam Mathews David Stevens Humphrey Taylor Stuart Davis Tim Malbon Isaac Pinnock Stuart Eccles Company The Client The Client The Client The Agency The Agency The Agency The Agency The Agency The Agency Role Project Manager Project Lead Project Sponsor Digital Production Creative Dir Digital Comms & Brand Planning Brand Planning Business Direction Production Lead

Support Ageny UX/Product Support Ageny UX/Design Support Ageny Tech/Biz

Key dates
Confirmed 16/12/11 Kick-off workshop 20/12/11 Technical feasibility delivery 03/02/12 Initial Costs w/c 06/02/12

Scope of technical feasibility

Key findings
Reviewing the technical feasibility of the initial ideas showed several key problems. 1. Live streaming to 1 Project Name people is not feasible, as the total commercially available infrastructure does not exist and far exceeds the current records of single-source live streaming (thought to be around 70m users on YouTube for the Royal Wedding). It would also be prohibitively expensive in bandwidth costs. It is also not backed up by core demographic stats of 700m broadband users (max globally) who would be able to view the stream. 2. Complex live interactive ideas around the live event were also not feasible at high peak concurrency as there would not be the time to produce and test software that could work at this scale. Existing high concurrency platforms (for example, Twitter and Facebook) have taken several years, several millions of pounds to develop and typically run on over 100,000 servers in custom $400m data centers. 3. There is not enough The Client tech resource available to do deep integration into the existing The Client client without affecting current roadmap plans. It was determined it would be able to use The Client login as an authentication option. 4. The technical design worked in conjunction with service design to create a system that could work at a lower number of approximately 100m total users with 10m peak concurrent users watching the live experience. Appendix 3 provides additional context around the scale of the ambition, and global internet penetration.

Our approach to defining & estimating highlevel functionality

At this stage, we have focused on very rapidly developing a shared and integrated vision of the programme, experience and technology platform at a very high level. We have used this to unpack and define functionality to a level at which it can sensibly be estimated but no further. To go beyond this point at this early stage would risk wasting time and re-work. As such, we have concentrated on defining big goals in low fidelity from the top down the opposite of a big design up-front approach.

The following defines the key aspects of the system at different stages that will have to delivered:

The before experience: Marketing, activation and crowd funding

8 months out: Landing page and sign-up for notifications Functionality: A simple launch site with the ability to create sub-pages to present information about the event, the cause and the artists. This phase of the site would allow for users to register their interest by signing up with their email address. Embedded social network following, liking, sharing etc.

10

Assumptions: Social networks to be embedded through simple sharing functions. Designs to be split-tested for conversion optimization. Primary concerns: Artist engagement, Roll-out speed and language translation.

4 months out: More advanced marketing site with sign-up for notifications Functionality: A multi-page site consisting of a main landing page, templated artist pages, cause related pages and event page. Possibility to link to 3rd party ticket vendor like Ticketmaster and show ticketing information within page. (how can we integrate with Ticketmaster to show how many tickets are available? How do we collect this data in our CRM database) Assumptions: At-venue tickets will be managed separately from the BSS platform, embeddable video player functionality will be delivered by VDIO or other 3rd party. Designs to be split-tested for conversion optimization. Primary concerns: Artist engagement, Roll-out speed and language translation.

11

6 weeks out: Crowd-fundraising platform, Individual fundraising and tiered access to live-streams Functionality: A fundraising platform that incorporates a donations mechanism that allows us to take transactions from credit-cards (further payment options TBC). Donation mechanism will be linked to authentication system for verifying returning users before and after the event. The donation system is going to have to handle multicountry, multi-currency and deal with any specifics in charity donation legals. Red Cross have a donation system but we will need it to be specifically branded, tied to our authentication system and CRM system so it may be easier to build a custom one. The crowd-funding will require a management interface to create projects for the overall event, artists, and causes. Each project will have multiple tiers of benefits that have different mechanisms (reward, crowd-unlock, lottery, crowd-decisions). Each project will also have content and social features. We will also need an interface and process for handling rewards for people. It will also require a lottery selection and survey/voting mechanic. The individual fund-raising will need to allow users to create fundraising pages and hook into the donation mechanism. Twibbon functionality could be provided by twibbon.com An EPG like interface will show the running orders and timezone specifics of events at the show and will extend to be using to browse the catch-up content after the concerts.

12

Subject to further definition work, we propose that mobile apps be launched during the Before phase. Initially, these should provide information and content updates, deliver messaging and drive engagement with the event and Cause, and by supporting comms/activation ideas. On the day of The Event, the apps will then present the Live experience (or a cut-down version of the Live experience) if we are able to validate a use case for it (subject to testing of the idea to be carried out in the next phase). Apps will also deliver clips during and after. More product definition is required, and will be prioritized within the next phase, feasibility scoped and re-estimated.

Assumptions: Red-cross have a donation system but we will need it to be specifically branded, tied to our authentication system and CRM system so it may be easier to build a custom one. One global payment partner will be needed across the site or a normalized integration across multiple partners. Subject to further definition work to understand the complex requirements, restrictions and vendor suitability it is possible that we could use PayPal. Twibbons and/or social badges will be delivered in partnership with a specialist provider, such as Twibbon.com. Primary concerns: Scalability of donation system; complexity of legality issues in handling charity donations on a global scale; integration of multiple third-party authentication systems into a good user experience. Quality of the mobile experience through third party apps (i.e. the way the integrated Facebook activity works on the Facebook app)

13

The during experience: One day, 4 concerts, live stream and social
Functionality: Even at reduced scale the during experience platform will be used by millions of people simultaneously, so the challenge is in producing a high-quality experience at high concurrency. This means high availability and performance. It also reduces the kind of interactions we can do successfully by avoiding heavy personalized and many-to-many data flows. This means using Javascript to interact with social platforms such as Twitter and Facebook where possible. Multiple streams of live feeds (edited view, multi-camera angles and green-room for instance) will be delivered by VDIO through one or more CDNs (e.g. Akamai, Unicorn, Limelight). Details of streaming content such as dynamic resolution settings, player technology and authentication technology will be defined in the next stage of project definition. The live streams on a desktop will be delivered through a Flash player. The actual page and visual assets will be delivered using a CDN for scale and we will use client-side Javascript to switch views etc. Subject to further definition work, we propose that mobile apps be launched during the Before phase. Initially, these should provide information and content updates, deliver messaging and drive engagement with the event and Cause, and by supporting comms/activation ideas. On the day of The Event, the apps will then present the Live experience (or a cut-down version of the Live experience) if we are 14

able to validate a use case for it (subject to testing of the idea to be carried out in the next phase). Apps will also deliver clips during and after. More product definition is required, and will be prioritized within the next phase, feasibility scoped and re-estimated. Very simple DRM will be used to basically authenticate a user has paid to be able to access a certain stream. Subject to further definition, we would recommend that a token-based authentication system be used and passed through the player to the CDN, in order to authenticate a users access to that stream and notify them to upgrade/pay if they havent. (We need to investigate these options further with VDIO and CDNs in order to define a secure system, which well look at during Technical Feasibility Phase 2). Some player customisation on visuals and functionality will almost certainly be required. There will need to be an authentication system (Facebook, The Client and site) to allow previously authenticated/paid users to access their level of stream. Delivering an editorially created live-stream of updates and pictures will require a custom admin system and a high-scale feed accessed through JavaScript to users. To deliver on-day payments and upgrades it will need to hook into the donation system from previous phase. The issue here will be if a large number of users attempt to pay at the same time. Assumptions: The live streams on a desktop will be delivered through a Flash player (we are assuming at this stage that Microsoft would not push the use of Silverlight). The actual page and visual assets will be delivered using a CDN for scale and we will use clientside JavaScript to switch views etc. JavaScript will also be used to

15

hook into Facebook and Twitter for some functions. Editorial feed will be delivered with a highly scalable technology. Primary concerns: Concurrency and performance. Authenticating users and streams. Scalability of donation system and VDIO & CDNs previous experience. Security of DRM.

VIP app experience Functionality: The Tablet experience is an unknown quantity but will likely involve integrating The Client functionality using the The Client Developer Kit. We aim to discuss this with The Clients technology team (possibly with Hatef) at the next stage. Our assumption at this stage is that The Clients mobile/tablet team would be best-placed to undertake this work but, again, nothing has been assigned as yet. Primary concerns: Availability of The Client Mobile team and The Client SDK

The after experience: Catch-up on exclusive content and buy exclusive content from the concerts
The catch-up after experience will primarily be Video On Demand. After initial discussions with VDIO it has been assumed that they will provide the tech and player for editing and encoding short-form video content. The DRM solution for rights-holders will be provided by VDIO. 16

Any payment mechanisms here will be integrated into our donations system and CRM. Assumptions: The catch-up/VOD service will mainly be free-toaccess. VDIO will be able to provide the tech and player for editing and encoding short-form video content. The DRM solution for rightsholders will be provided by VDIO. Primary concerns: Integrating with the metadata system attached to encoded videos or designing one from scratch. Licensing content post 24hrs and VDIO previous experience.

Auction site / BSS Shop An auction site will allow bids to be taken on items from the show. We could just use eBay and use the eBay API to display information on current auctions on the main site. Assumptions: Uses a third-party auction site that handles bidding. Primary concerns: API capabilities

Cross-cutting requirements The cross-cutting requirements will be required across all the different components and phases of the project. Functionality - Multi-language support and translation system - Geo-IP detection - Data warehousing, data analysis, CRM and message delivery 17

- Analytics and split-testing infrastructure - A Cloud-based infrastructure roll-out solution with automatic provisioning, monitoring, recovery and scaling. Assumptions: Infrastructure to be dedicated to BSS platform (i.e. separate from existing The Client, Red Cross or other partner platform databases)

18

Legacy
Following this initial launch project of the BSS, Project Name , there will be number of legacy pieces within the platform that The Client will be able to use in the further development towards becoming a desirable entertainment partner.

Concept - name and identity

The Project Name will be an ownable and recognisable piece of IP following the A Day to Save the World project.

Technology
A new social entertainment platform. A new and innovative crowd and community fundraising platform. The VIP app that will showcase The Clients future ambitions and highlight functionality that can be incorporated in the The Client product road map. A new virtual ticketing solution that combines a payment solution together with authentication and access to video streams and other content.

Data
The data collected from the interactions of the users throughout the campaign will be give The Client key insights to their audience and potential customer base.

Innovation lead over competitors

The Client will be first to market with an event and platform of this size and complexity. This will lead to a wealth of

19

experience that would facilitate the future development and re-use of the platform

20

Proposed solution
User Journeys
The complete set of user journeys for Before, During and After the live experience (the whole programme) are attached in Appendix 3.

Technical Architecture
The following diagrams show the system architecture before, during and after the live event. The fourth diagram shows potentially reusable components for a future live event platform.

21