sony pictures entertainment mediacentre rfpbusiness... · web viewin over 60 international...

Confidential

CORPORATE PROCUREMENT SERVICES

Request for ProposalSony Pictures Television Networks

EMEA MediaCentre

Date Issued: March 15th, 2013

Confidential

Table of Contents

Table of Contents1.0 Introduction and Overview......................................................................................41.1 SPE Business Overview............................................................................................41.2 Project Background.................................................................................................42.0 Instruction to Bidders..................................................................................................52.0 General Guidelines..................................................................................................52.1 RFP Process Time Line..............................................................................................62.2 Contact Information................................................................................................7

2.2.1 SPE Point of Contact..................................................................................................72.2.2 Bidder Point of Contact.............................................................................................7

2.3 Required Information..............................................................................................72.4 [Evaluation Criteria, if applicable]............................................................................72.5 Bidder Q & A and Check-In.......................................................................................82.6 Bidder Oral Presentation.........................................................................................82.7 Disclaimer...............................................................................................................82.8 Conflict of Interest...................................................................................................83.0 Previously Communicated changes to MediaCentre RFP............................................10

3.0.1 Communicated August 8th, 2012.............................................................................103.0.2 Communicated February 14th, 2013........................................................................11

4.0 Guiding Statements...................................................................................................124.0 Glossary & Definitions...........................................................................................124.1 Integration............................................................................................................134.2 MAM Requirements..............................................................................................134.3 Operations............................................................................................................144.4 Program Acquisition..............................................................................................154.5 Reporting..............................................................................................................154.6 Security.................................................................................................................164.7 Tech Specs.............................................................................................................174.8 VOD/Non-Linear....................................................................................................184.9 Workflows.............................................................................................................195.0 Content ID / Metadata...............................................................................................20

5.0.1 MediaCentre Content Organization........................................................................205.1 Metadata..............................................................................................................285.3 Content Identification............................................................................................296.0 Reference Architecture..............................................................................................306.1 Reference Architecture Definitions........................................................................32

6.1.1 Media Asset Management......................................................................................326.1.2 Utility Services.........................................................................................................346.1.3 User Interface..........................................................................................................356.1.4 Content Processing.................................................................................................356.1.5 Package Assembly Services.....................................................................................366.1.6 Delivery Management.............................................................................................366.1.7 Services Layer..........................................................................................................37

2013 Sony Pictures Entertainment Inc.All Rights Reserved 2 of 50

Confidential

6.1.8 Workflow Management..........................................................................................376.1.9 SPTN Offices............................................................................................................376.1.10 Security and Administration Services and IDM Integration................................386.1.11 Interfacing Systems.............................................................................................396.1.12 Third Parties........................................................................................................406.1.13 Master Data Management (Supporting Data Services).......................................41

7.0 Appendices................................................................................................................428.0 Appendix A................................................................................................................438.0 Appendix A-1 – Outline for Response.....................................................................448.1 Appendix A-2 - References.....................................................................................458.2 Appendix A-3 – Pricing Proposal............................................................................468.3 Appendix A-4 – Resource Loading Schedule...........................................................479.0 Appendix B – Information Security Questionnaire......................................................48

ConfidentialityThis information is considered CONFIDENTIAL and PROPRIETARY to Sony Pictures Entertainment Inc. This information is intended only for the person or entity to which it is addressed. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.


Confidential

1.0 Introduction and Overview

1.1 SPE Business Overview

In over 60 international locations, Sony Pictures Entertainment (“SPE”), based in Culver City, California, is a worldwide leader in creativity and innovation. Backed by the power of Sony, one of the world’s most recognizable and respected brands, SPE’s global operations encompass motion picture production and distribution; television networks, production and distribution; DVD acquisition and distribution; operation of studio facilities and development of new entertainment technologies. SPE is known for franchise films such as the Spider-Man and Men in Black series along with others such as, Da Vinci Code, Surf’s Up, The Social Network, 2012, Resident Evil, Superbad, Memoirs of a Geisha, Bad Boys (I and II), Jerry Maguire, and The Pursuit of Happyness. SPE also owns and distributes a library of over 3500 films and a significant number of television programs. Additionally, SPE produces a large number of network and non-network television programs throughout the world. SPE also has 8 branded television networks and maintains significant ownership of many other networks throughout the world.

1.2 Project Background

The Project was fully described in the previous RFP transmittal.


Confidential

2.0 Instruction to Bidders

2.0 General Guidelines

a) All information requested in this RFP package is required on or before [Date & Time]. Please be as thorough as possible in providing the information requested in the RFP package as this will assist us in the evaluation process.

b) We require that your company indicate via email to [Name] by [Date & Time] as to whether or not it intends to submit a proposal response to this RFP package.

c) [Any questions you have pertaining to this RFP package should be submitted via e-mail only to [Name] by [Date &Time]. SPE will host a Bidder Conference on [Date & Time] to address these questions. This Bidder Conference will also provide the opportunity for bidders to pose additional questions to the SPE team to be answered during the Bidder Conference. Further information regarding this Bidder Conference will be provided under separate cover at a future date to be determined.OR[Any questions you have pertaining to this RFP package should be submitted via e-mail only to [Name] by [Date &Time]. All questions will be answered via email and made available to all bidders who have elected to participate in the RFP process.

d) All pertinent information for preparing a bid is contained within this RFP package. Failure to review all materials fully and carefully will not protect a bidder that will be submitting a proposal from full responsibility for the services to be provided. All responses to the RFP package should be included in the proposal. A bidder’s proposal to SPE shall be assumed by SPE to be a fair and accurate representation of all costs applicable to the proposal submitted by the bidder.

e) The proposal must be valid for [TBD] from the date of submittal to SPE. No corrections or modifications will be accepted without prior written consent from [SPE Contact name] via e-mail only.

f) Exceptions to any part of this RFP package relating to your proposal must be clearly stated in a letter accompanying your proposal. Any ideas, suggestions or alternate proposals you may wish to submit that may be of mutual advantage are welcome and will be considered only upon your compliance with the RFP package.

g) The preparation of all proposals shall be at the expense of the bidder submitting the proposal.

h) Bidders shall not take advantage of any apparent errors or omissions in the RFP documents provided by SPE. In the event that any errors or omissions are discovered which can affect pricing, Bidders shall notify SPE’s primary representative immediately via email.

i) Each proposal shall: (1) show the full legal name and business address of the bidder submitting the proposal, including its street address if it differs from its mailing address, (2) be signed with the usual signature of the person, or persons, authorized to bind the bidder submitting the proposal, and (3) be dated. A proposal submitted by a partnership or joint venture shall list the full name of all partners or joint ventures. The name of each signatory shall be typed or otherwise clearly imprinted below each signature. In the event that verification is requested by SPE, satisfactory evidence of the authority of any signatory to act on behalf of the bidder submitting the proposal shall be promptly furnished.


Confidential

j) In addition to the points outlined in item “h” above, each proposal shall include all the information as requested in Appendix A [and Appendix B, if applicable]. A proposal submitted without including the information outlined in Appendix A [and Appendix B, if applicable] will not be accepted for consideration.

k) SPE reserves the right to award one or more contracts on the basis of proposals received. SPE also reserves the right to accept or reject your proposal in whole or in part. If all or any part of your proposal is accepted, a contract may be submitted to you for execution. SPE reserves the right to make a contract award without written or oral discussion with any bidder submitting a proposal. SPE reserves the right to decide not to make a contract award to any bidder submitting a proposal.

l) SPE reserves the right to modify any provisions or parts of the RFP documents at any time before expiration of the original RFP submission due date. The closing date set forth in this RFP also may be extended at any time by SPE before the original RFP Bidder submission due date.

m) SPE reserves the right to schedule a site visit both prior to, and subsequent to, the proposal submittal due date of this RFP package to assess facilities, staffing, infrastructure and any other areas deemed pertinent to this RFP process.

2.1 RFP Process Time Line

SPE has established the following estimated time line for the completion of this RFP process:

Description of Activity TimeframeRFP package is released to potential bidders for bid Final date for potential bidders to declare their intentto participate in the RFP process[Final date to submit questions or requests for clarification, if applicable][Bidder’s conference for clarification of RFP package, if applicable] Final date for receipt of proposals by SPE[Bidder Oral Presentations, if applicable][Estimated project start date, if applicable]

Late responses may be disqualified.For your proposal, SPE requires the following:

[# of hard copies] of your proposal via Federal Express (or similar service) or hand delivery to:Sony Pictures Entertainment Inc.10202 W. Washington Blvd. Culver City, CA 90232Attn: [Name & Location]

Electronic copy to [Name & Email Address]. Any additional materials or attachments detailing any other relevant information

specific to your proposal, which you deem necessary and which was not initially requested within the RFP package.


Confidential

2.2 Contact Information

To ensure consistency of communications, SPE and bidders participating in the RFP process will manage communication and contacts through the designated contact(s) below.

2.2.1 SPE Point of ContactTo ensure fairness throughout the RFP process, please submit all questions with regard to this RFP package to the designated SPE representative. Contacting other parties within, or associated with SPE may result in disqualification from the RFP process. Only information received from the designated SPE representative should be considered valid and binding. For the purpose of this RFP process, please direct all questions via e-mail only to the following individual.

[Contact Name] Telephone: [Telephone Number]Sony Pictures Entertainment Fax: [Fax Number]10202 W. Washington Blvd. Email: [email Address][Suite Number]Culver City, CA 90232

2.2.2 Bidder Point of ContactSPE encourages all bidders electing to submit a proposal to involve their senior management with decision-making authority, as well as the account management team most likely to be dedicated to SPE, in both the RFP process and any subsequent meetings/discussions. Please identify within your proposal the primary individual contact name, and a secondary/backup contact name for your company during the RFP process who is/are empowered to field any questions or further requests from SPE as they may arise. In doing so, please also provide in your proposal the following information pertaining to these individuals:NameCompanyTitleAddressTelephoneFaxE-mail address

2.3 Required Information

Bidder is to provide a comprehensive response in accordance with the information requested in the RFP package including all the appendices under Appendix A [and Appendix B, if applicable].

It is SPE’s preference that the bidder responses not include general marketing material. However, should bidder choose to include such information it must be limited to no more than five pages.


Confidential

2.4 [Evaluation Criteria, if applicable]

The submitted proposal, or proposals, deemed by SPE to be the best overall will be based upon our evaluation of all elements of each of the submitted proposals. While the following areas are not intended to be all inclusive and should not be viewed as such by those bidders submitting proposals, they do reflect some of the criteria to be used by SPE the proposal evaluation process.

Project approach and methodology Project team qualifications Pricing Credentials and prior experience References from current and previous customers Company’s financial status

2.5 Bidder Q & A and Check-In

2.6 Bidder Oral Presentation

As previously mentioned in the above RFP timeline table, SPE anticipates holding oral presentations with selected bidders during the week[s] of [Date] [and Date]. Further information regarding the final scheduling and format for these oral presentations will be provided under separate cover at a future date to be determined.

2.7 Disclaimer

This RFP process does not commit SPE to any specific course of action. All costs associated with the preparation and submission of a proposal shall be borne solely and exclusively by the bidder submitting the proposal.

2.8 Conflict of Interest

Bidder hereby represents and warrants as to itself that it has no Conflict of Interest. “Conflict of Interest” shall mean that Bidder has a relationship with an employee, officer, director or board member of SPE, its affiliates or subsidiaries that could give rise to a claim of a conflict of interest on the part of the employee, officer, director or board member of SPE, its affiliates or subsidiaries. Relationships that are considered “Related Party” include but are not limited to:

Relative by blood or marriage (for example, Bidder and SPE employee are spouses, parent/child, siblings, in-laws, etc),

Friend, Investor, Shareholder, Owner, Co-owner, Partner in business,


Confidential

Consultant, or Any financial relationship which may allow the SPE employee, officer, director or board

member to profit from Bidder’s work for SPE.The Bidder shall disclose any and all Related Party relationships with any employee, officer, director or board member of SPE, its affiliates or subsidiaries as part of its proposal. Subsequent to Bidder submitting its proposal, Bidder shall promptly inform SPE of any change in status, or new relationships, during the course of this RFP process which results in Bidder becoming a Related Party.


Confidential

3.0 Previously Communicated changes to MediaCentre RFP

3.0.1 Communicated August 8th, 2012Section C.2.1 – Business aims and objectives

Change: Primary MC equipment facilities to be hosted at an external datacenter, location tbd, in the greater London area, not at Golden Square.

Production operations will be located at Golden Square along with any required equipment to support this functionality

MC will not be supporting a Disaster Recover TV channel playout operation.

Section C.2.6 – MediaCentre - Physical environment

Change: Central Technical Area (CTA) will be remotely located at an external datacenter, location tbd, the greater London area, not at Golden Square.

Note: Support of CWM QC and other MediaCentre systems should be accessible at other datacenter location.

Remove: TV channel playout monitoring/DR playout suite: remove from specification.

Section D.1.2 – Audio-Video (AV) signal routing / processing

Change from: Sources: VTR outputs (three installed plus one for future expansion)Domestic satellite / cable IRD outputs (to be free-issued by SPTN) (two)

(including signal conversion equipment as necessary)

Change to: Sources: VTR outputs (one installed plus one for future expansion)Domestic satellite / cable IRD outputs (to be free-issued by SPTN) (one)

(including signal conversion equipment as necessary)

Section D.1.3 – AV multi-viewer mainframes

Change: No multi-viewer mainframes required Section D.1.6 – Communications / talkback

Change: No Communications / talkback system is required

Section D.3 – TV channel playout monitoring / DR playout control suite

Change: Remove TV channel playout monitoring/DR playout control suite.


Confidential

Section D.4.1.1 – VTR ingest / outgest provision

Change from: The respondent shall make provision in the CTA and install a total of three videotape transports (VTR) – 2 x Digital Betacam + 1 x HDCAM SR – to be free issued by SBTNB.

Change to: The respondent shall make provision in the CTA and install a total of two videotape transports (VTR) – 1 x Digital Betacam + 1 x HDCAM SR – to be free issued by SBTNB.

Additional information required from respondent:

• Footprint size & number of racks at the primary London based datacenter location to support MC

• Footprint size & number of racks at the Golden Square/London, Budapest and Madrid locations to support production operations

• Power consumption totals and per rack to support equipment at the primary London based datacenter location to support MC

• Power consumption totals and per rack to support equipment at the Golden Square/London, Budapest and Madrid locations for production operations

• Network design and interface detail at primary London based datacenter location for the interconnectivity to the SPTN WAN to support production operations at the Golden Square/London, Budapest and Madrid locations

3.0.2 Communicated February 14th, 2013

Section D.2 – Traffic Area

Change from: The respondent shall provide the following for this facility:Two supervisor technical desksSix traffic operator desks

Change to: All desks will be supplied by SBTNB via free issue. Please retain monitors, monitor arms, and other accessories.

Section D.4 - QC/Version edit suites

Change: Eliminate all desks & furniture (2 x super / 4 x ordinary). All desks will be supplied by SBTNB via free issue. Please retain monitors, monitor arms, and other accessories. Change: Eliminate all Apple/MacPro computers (qty 4).

Retain I/O breakout cards.


Confidential

MacPro items will be supplied by SBTNB via free issue.


Confidential

4.0 Guiding Statements

Based on extensive discussions with the Sony team in the various operational and technical groups, these statements were created to clarify and amplify the workflow diagrams and requirements previously communicated in the original RFP.

These statements supersede previous information, in case of conflict.

The statements are presented in categories for organizational purposes and should not be considered in a priority or preference order.

4.0 Glossary & Definitions

Detailed glossary entries and definitions can be found in the Content ID and Reference Architecture section for a significant number of systems, terms, and processes involved in the MediaCentre ecosystem.

Term Definition

Programme See section 5.0.1 for definition

Alpha See section 5.0.1 for definition

Kit See section 5.0.1 for definition

Component See section 5.0.1 for definition

Asset See section 5.0.1 for definition

Version See section 5.0.1 for definition

GPMS See section 6.1.11.1 for definition

MDM

A master data management tool. The MDM system will be the source of Programme and Alpha level records and descriptive metadata. Currently the MDM tool used within SPE is GPMS, but GPMS will be replaced with an alternate MDM solution.

Eagle See section 6.1.11.2 for definition

CMDB

a CMDB (Configuration Management Database) represents the authorized configuration of the significant components of the IT environment. A CMDB helps an organization understand the relationships between these components and track their configuration.

Archer

Archer is a risk and compliance management systems used by Sony Group. Archer tracks all of Sony’s Information Assets. An information asset is information that is of value to Sony Group and the structure managing the information (including Information Systems and materials for system development, operation and maintenance) as an entirety.

Media Order See section 5.0.1 for definition


Confidential

4.1 Integration

4.1.1.1 MediaCentre will have a web service-based API interface to the EAGL/DMR API. The specification is well documented can be provided if required.

4.1.1.2 The majority of high level requirements for integration with the Linear Scheduling Systems are defined in the original RFP. However, there are potentially significant impacts to the complexity of those integrations based on the content ID section.

4.1.1.3 The first phase of MediaCentre does not include the requirement to enable integration with Non-Linear Scheduling, but MediaCentre should be able to upgrade or enable capability to interface with such a system in the future.

4.1.1.4 The first phase of MediaCentre does not include the requirement to enable integration with an Ad Sales System, but MediaCentre should be able to upgrade or enable capability to interface with such a system in the future.

4.1.1.5 SPTN will provide an integration services layer to connect supporting systems with the Media Center. (To be implemented)


Confidential

4.2 MAM Requirements

4.2.1.1 The MAM will need to be flexible enough to receive a number of different file formats and convert these into the Sony house formats for use throughout the system.

4.2.1.2 The MAM will be flexible enough that new hardware devices can be integrated with minimal custom interfacing.

4.2.1.3 The MAM will integrate with with SPE’s Active Directory/Sony Identity Management system to provide authentication for all users.

4.2.1.4 The MAM will manage the delivery and packaging of video, audio, subtitles, images, PDFs and text files for delivery to client profile locations, utilizing integration to EAGL/DMR and potentially Alfresco for these materials.

4.2.1.5 The MAM will integrate with Cerify for file based QC, with results being accessible through the user interface and/or API.

4.2.1.6 The MAM will integrate with Aspera and other delivery solutions to provide a secure, traceable and accelerated delivery of assets to client end points.

4.2.1.7 The MAM user will have the ability to initiate an ingest workflow without being initiated by the agreed upstream traffic/scheduling system.

4.2.1.8 The MAM will have the ability to create content to specific file formats needed for delivery to linear playout services and to VOD services for linear operators platforms.

4.2.1.9 The MAM will have the ability to restrict delivery of content if certain key, pre-determined criteria, such as the presence of a specific language, are not met. If a piece of material is nearing a critical delivery date and it is still not fulfilled the system should have a clear way of notifying users.

4.2.1.10 The MAM will have the ability to automatically prioritise one piece of content over another through the workflow stages, based on the required delivery date. For example; this could range from moving an item ahead of lower priority items in a queue, selecting a “high priority” drop folder for delivery or if the hardware supports it, assigning more processing cores to a transcoding task or provisioning a system of QoS (Quality of Service) to ensure a "fairness" algorithm when processing large volumes of content across multiple “channels”. This should only activate when the input queue to a particular workflow step becomes full. For example it is fair and good to have one channel use all 6 analysis streams if it is the only channel with content in queue. However, if materials for two other channels show up, you can decide to evenly divide the capacity in thirds, if the due dates are all equal.

4.2.1.11 The MAM will provide detailed logging of every user action and process undertaken by the system and allow access to this data through the system’s reporting infrastructure.

4.2.1.12 The MAM will provide the ability to ingest content from multiple geographic regions, via a system of remote ingest.

4.2.1.13 Subtitles and dubbed audio will be available in the MAM for use by OTT/VOD systems.

4.2.1.14 The MAM will be able to insert a logo graphic into a VOD deliverable file.


Confidential

4.2.1.15 The MAM will have the ability to provide proxy video for streaming and will include all audio tracks and allow the user to select the audio tracks to be played when viewing the proxy. It should also include support for playing back subtitle assets stored within the MAM and allow the user to select which language to view. Support of subtitle positioning data from within the STL file is preferable when previewing subtitle files.

4.2.1.16 “QC failed” distributor files will be held in a Quarantine Area until replacement files arrive.

4.2.1.17 The MAM will have the ability to accept and display usage windows for various languages and locations.

4.2.1.18 The MAM will provide the capability for Export Clips by users with varied levels of access rights.

4.2.1.19 The MAM will provide integrated support for the export of files from the MAM to and then from Final Cut Pro X, Adobe Premiere, and Edius including the import and export of data created from QC platforms such as Textronix Cerify.

4.2.1.20 Client Profiles will used to define the requirements of each client for content delivery. Client Profiles will be created by MediaCentre Operators using the system UI provided as part of this response. Client Profiles will define key variables and requirements needed to support automated and manual workflows that include transcoding, metadata generation, file renaming, packaging (i.e. assembling A/V media, images, docs, etc.).

4.3 Operations

4.3.1.1 Issues in the Operations area will be addressed in a separate Services Agreement RFP.


Confidential

4.4 Program Acquisition

4.4.1.1 The Program/Title Records creation process in the MediaCentre will typically be triggered by the scheduling of the program by any of the Scheduling Systems (Today: Vision, BCM, and Provys). Once triggered, the Scheduling System will receive all record create & update information from GPMS/MDM directly.

4.4.1.2 MediaCentre user will be able to manually lookup and create a program record in the MediaCentre from GPMS/MDM without being triggered by the Scheduling System via a direct interface to GPMS/MDM for programme/title data.

4.4.1.3 The MediaCentre will receive any critical dates for deliverable completion or delivery from either a Linear Scheduling System (Vision, BCM, and Provys) or a Non-Linear Scheduling System (Vision, TBD…). The system should be able to support multiple critical dates for use when processing content. For example License Start doesn’t have a delivery associated with it but will drive ingest and materials preparation. TX date defines when a piece of content should be delivered to an output location.

4.4.1.4 The MediaCentre will be able to accommodate the availability of editorial restrictions data in future releases (this workflow will not be implemented in phase1).

4.4.1.5 The MediaCentre will have the automated capability to merge/replace programme/title level records if sent a replacement ID (ex: in the case of a duplicate)

4.4.1.6 The MediaCentre will have the capability to receive ongoing program/title updates from GPMS every 5 minutes.

4.4.1.7 The MediaCentre will be able to store and search across programme/title AKA’s and localized titles (important in the case of program name changes or for multi territory acquisitions).

4.4.1.8 The MediaCentre will have the ability to persist N number of foreign programme/title keys from GPMS and will be able to match inbound content utilizing foreign key cross reference (focus on EIDR ID).

4.4.1.9 ContentID Track overlapo MediaCentre will be able to receive Alpha records from GPMSo MediaCentre will be able to register Alpha records in GPMS

4.5 Reporting

4.5.1.1 MediaCentre will allow users to create custom reports without requiring sysadmin or superuser rights.

4.5.1.2 MediaCentre will make reporting data available to other systems to allow external analysis and reporting if desired.

4.5.1.3 MediaCentre will provide a reasonable number of standard operational reports out of the box, such as queue reporting, throughput, workflow status, estimated delivery times, and audit reports.

Example reports:


Confidential

Pending Inventory Reporto Allows schedulers to see all inventory items (components) that need to

be fulfilled for scheduled programmes. Can possibly be sorted or filtered based on schedule date, order due date, etc.

Available Inventory Reporto Allows schedulers to see all inventory (components) that are available

for Scheduling of VOD ordering. Ingest Report

o Shows all assets queued up for Ingest within the MAM and the state of the ingest process.

Open Order Reporto List of all open orders pending in the MAM and the state of each order

(i.e. in transcode, pending metadata, etc). Completed Order Report

o All orders completed and delivered within the MAM within given date range

Processing Exception Reporto All workflow steps within the MAM that need remediation (I.e. Failure

in transcode, error in delivery, etc) Work step Queue Report

o Shows all queued items based on particular service, maybe based on order? (i.e. pending transcode items, pending QC items, etc)

Metadata Reports o Open Metadata fields for a Programme, Version, or Alpha need to be

populated for delivery

4.6 Security

4.6.1.1 Newly written custom code developed for the Media Centre will at a minimum adhere to the good practice guidelines set forward by the Open Web Application Security Project (OWASP) standards.

4.6.1.2 The systems comprising Media Centre will all require security vulnerability testing to identify weaknesses in application code, interface design, and network access. The testing will take place during each build phase, before launch (upon completion of the whole system), and on an on-going basis within SPE’s Governance Risk and Compliance framework. All testing must be carried out by SPE Information Security or a 3rd party approved by the SPE Information Security team. It is the responsibility of the SPE project team to notify SPE Information Security at least 1 month in advance of when security testing required and to ensure relevant access for the security test team.


Confidential

4.6.1.3 A comprehensive security patching and updating procedure in line with Sony GISS will be defined for the systems comprising MediaCentre. This must be in place prior to the launch of Media Centre.

4.6.1.4 MediaCentre will meet appropriate requirements for each subsystem in line with Sony GISS and GISP standards.

4.6.1.5 Each group within the project will provide a deliverable, identifying security threats and scenarios which could affect the confidentiality, integrity and availability (continuity and DR) to the Media Centre system components and workflows and work with the Security lead to address them.

4.6.1.6 All vendors will be asked to identify areas where they will be layering in security to ensure the overall system remains secure at all layers and addresses security threats relevant to Media Centre and its content. At a minimum security threats/ risks and scenarios which have an adverse affect on the confidentiality, integrity and availability (continuity and DR) of the Media Centre system components and workflows will be documented. The vendor shall also put forward proposals for reducing or mitigating the threats/ risks and scenarios for approval by the SPE Information Security team.

4.6.1.7 Specific security consideration will be given to components that are internet facing or house personal information, considerations such as secure encrypted protocols, watermarking and encryption at rest will be considered. Any additional concerns raised by the SPE Information Security team in relation to this or 1.0.1.6 will be addressed by the vendor during the phase in which the concern has been identified.

4.6.1.8 All MediaCentre systems will be registered in CMDB and ARCHER, as appropriate.

CMDB (Configuration Management Database) is the authorized configuration tracker for significant components in the Sony IT environment.

ARCHER is a risk and compliance management system used by Sony. Archer tracks issues of governance risk and compliance in relation to Sony Pictures Information Assets.

4.7 Tech Specs

4.7.1.1 MediaCentre will not apply DRM to content in the VOD process.

4.7.1.2 MediaCentre should be able to handle import, processing, and preview of subtitle/captioning properly for both 4x3 and 16x9 aspect ratio content for both SD and HD resolution/standard.

4.7.1.3 QC profiles should be able to be created and edited without interrupting QC work.

4.7.1.4 MediaCentre will have the ability to utilize any capability or codec within the transcoding subsystem as part of an import or export profile.


Confidential

4.8 VOD/Non-Linear

4.8.1.1 MediaCentre will have the capability to generate, package, and transfer traditional VOD content intended for set-top boxes.

4.8.1.2 MediaCentre will have the capability to incorporate additional metadata (title information, delivery requirements, etc.) from other systems to generate proper VOD packages.

4.8.1.3 MediaCentre will have the capability to generate mezzanine level assets for use by other Sony groups such as OTT, Crackle, DADC, Sony Pictures Television Networks, etc. and/or storage in other library systems.

4.8.1.4 While a non-linear scheduling system is an important idea that deserves further consideration, it is not part of the MediaCentre project.

4.8.1.5 MediaCentre will expose interfaces to OTT service automation to allow for querying of asset inventory data and requesting delivery of assets.

4.8.1.6 MediaCentre will standardize an asset identification method.

4.8.1.7 MediaCenter will standardize a subtitle delivery format.

4.8.1.8 Where a delivery package for a VOD platform requires a group of incrementing numbers to be assigned to the package metadata the MediaCentre will track this number and increment it for each subsequent.

4.8.1.9 MediaCentre will not be expected to generate final delivery content for OTT type uses.

4.8.1.10 MediaCentre will not be expected to handle non-linear advertising.


Confidential

4.9 Workflows

4.9.1.1 Workflow templates will need to be created and modified by superuser/ sysadmin without vendor support.

4.9.1.2 Client VOD profiles (including delivery location/file tech spec) will need to be created and modified by superuser / sysadmin without vendor support.

4.9.1.3 MediaCentre will be able to report which items have been successfully delivered to the Playout partner or Non Linear platform.

4.9.1.4 The workflow will have no reasonable limit to the number of additional assets that can be associated to a primary asset after it has been ingested in to the system.

4.9.1.5 MediaCenter will be able to prioritize processing of content on multiple criteria such as transmission date, license start, distribution partner, etc.

4.9.1.6 Content will be available to users, such as the Promo group, immediately upon ingest, even without QC.

4.9.1.7 MediaCentre User with appropriate privileges will have the ability to manually override any ‘wait’ condition in a workflow.

4.9.1.8 MediaCentre will clearly identify to users what stage an asset is in throughout individual workflows.

4.9.1.9 Mediacentre will have a workflow to address delivery media based on receipt of a request from an external interface/vendor. An example of this could be a playout centre sending a request for missing video and audio assets if a piece of content has previously been delivered but since purged from their archive.

4.9.1.10 MediaCentre will have a means to cleanly pause all jobs (allowing tasks mid process to complete - e.g. a file mid Cerify QC) and resume at a later date, to allow the system to be shut down for patching, maintenance, or emergency.


Confidential

5.0 Content ID / Metadata

5.0.1 MediaCentre Content Organization

The following section will describe the proposed structure for content organization within the Media Center. It contains definitions of the terms that will be used to describe the proposed hierarchy, the content organization structures used in interfacing broadcast systems, the proposed media center content organization, and examples of how we plan to apply the content organization to inventory for both linear and non-linear content.

I. This section describes the terms of content organization that will be adopted within Media Center. Please refer to this section when reviewing the content organization diagrams and interface requirements.


Confidential

Term Source System

Master Data

Definition Example Identification

Programme MDM Yes Synonymous to SPE's definition of “Title”. Programme is the master data describing the intellectual property, which is maintained as the highest level of organization for its content. The programme level, for purpose of the Media Center project, will be the level used to describe “Series”, “Season”, and “Episode” level records for Series content, and “Feature” for non-episodic content. Much of the content level descriptive metadata (i.e. Titles and Alternate titles, Synopsis, Cast and Crew, Ratings, Release Dates, etc) will be managed at the Programme level.

Non-Episodic: Men in Black IISeries: Married With ChildrenSeason: Season 1Episode: Episode 0101

GPMS Title ID

Alpha MDM Yes As defined by SPE, an alpha is a unique picture/audio/content cut of a programme (or title) created for business, territory, and/or platform S&P, etc. It does not refer to non -S&P localization (e.g. subtitling, dubbing).

TheatricalTV_ExtendedEdited_Airline

GPMS Alpha ID

Kit Media Center

No A kit is a means of grouping conformed components in inventory which are associated to the same alpha level record

n/a Media Center Kit ID

Component Media Center

No A Component is the building block for the creation of a Deliverable or a “Product” (e.g. video, audio, subtitle, etc). One- to- many components can be used during automated content processing in order to achieve the specific output described within a client profile. The component records, within media center, will contain metadata that uniquely describes the characteristics of the asset(s) which back it. For the purpose of the Media Center, components will be stored under the alpha level, within the grouping of a kit. There may potentially be cases where components may need to be tied to the title level, pending further analysis. A Component can be used in one or many deliverables. Components may exist in a flat or hierarchical structure, depending on the Component Type. (i.e. Audio Track Components contain Audio Channel Components)

The Media center should store components representing core media assets, promotional assets, and ancillary assets.

Component Types in the Media Center can be: Video, Audio Track, Audio Channel, Subtitle, Closed Caption, Images, Ancillary Materials, etc.

Video Component: Master TX Version - SD File IMX 30Audio Component: 5.1 EnglishSubtitle Component: Russian Subs

Media Center Component ID

Asset Media Center

No An asset, in terms of the media center, refers to the physical/digital file(s) backing a component level record. A component can contain one- to- many assets, depending on the component type and file layout (i.e. A subtitle component will contain one file, but a 5.1. audio component with a discrete file layout will contain 6 files, one for each channel). Multiple components can also refer to the same asset (i.e. A Muxed video file can be associated to a Video Component and one- to- many audio components depending on the encode of the muxed file). For purpose of the media center, not all assets may be components managed through inventory.

Uki_13_16x9_25_prores_422^HD_FINAL.mov

Media Center Asset ID

Version Scheduling No A Version, as defined and used within the SD - Anytime - Vision


Confidential

II. The following section describes the content organization currently used within the MDM and BMS Systems. Each of the systems shown below will require integration with the Media Center. Because each system has its own structure for content organization, it is a requirement of the Media Center that the interfaces are able to appropriately translate inbound and outbound data in the appropriate format needed by the interfacing systems.

a. The following diagrams represent how the MDM will organize its content. The diagrams describe a multi-leveled content hierarchy, where programme records can be single or multi-tiered and alpha level records are the children of the programme. There are three diagrams below: a 3 level series (Diagram 1), a two level series (Diagram 2), and a non-episodic (Diagram 3). As the Media Center will be receiving programme and alpha records from the MDM, it is a requirement that those records be represented in the same hierarchical structure as shown below.


Confidential

b. The following diagram (Diagram 4) is a representation of how the Scheduling

Systems, within the broadcast workflow, organize content. As seen below, the Scheduling Systems do not currently have the concept of Alpha (as seen in the Media Center Hierarchy). In addition, they have two additional concepts called “Version” and “Material”. Version does not seem to represent the same definition of Alpha, and looks more closely aligned to a deliverable out of the media center, as its requirements are very specific to the format needed by the various play out systems. Material is still a concept that is being understood as requirements are clarified. This diagram is included within this document so that the vendor clearly understands that the scheduling systems organize content in a structure that is not identical to the Media Center structure, but similar. The Media Center will need in


Confidential

its interface with the broadcast systems a method of receiving and translating data. The data may not follow the exact content hierarchy of the MediaCentre. This interface should include the ability for a scheduler or programmer to query the media center inventory, and potentially order inventory related to specific versions.

c. The following diagram (Diagram 5) is a representation of the proposed content hierarchy for the Media Center. As seen below, the programme and alpha level records, which are to be sourced from a central MDM system, will need to be carried over and represented as data within the Media Center. This means that programme and alpha level records need to be searchable and accessible directly from the Media Center. In addition, the hierarchies described above for the programme and alpha levels need to be supported.

The concept of a “component” has also been introduced below. As defined above in the glossary, the component is a shell record that contains information about the expected “asset”. Components will be associated to alpha level records within the Media Center. The media center will need the ability to store core media, promotional, and ancillary components. Component Types are still to be determined


Confidential

and finalized, but some may include video, audio, subtitle, closed caption, and image components. The aforementioned list is not comprehensive and additional types may be required.

Diagram 5 also describes a “grouping” mechanism called a “kit”. The kit is used to represent a group of “components” which are conformed. This concept will become essential in inventory management, as alphas can contain a large number of components in inventory, some not necessarily conforming to others. The “kit” concept will allow inventory to be more efficiently organized and retrieved within the Media Center.

An example of kitting would be if a specific alpha for an episode contained two versions of source video. One version is the 16 x 9 AR video and the other is the 4x3 video. The 16x9 video is accompanied by a subtitle file that was specifically conformed using the 16x9 video. In this case, we would want the 16x9 video and the subtitle file to be “kitted” together within inventory so that when ordered out of the Media Center, we know that these two inventory assets can be used together to form a final deliverable. We do not want the subtitle file to be delivered using the 4x3 video because in this case, the subtitles were specifically created using a 16x9 aspect ratio. If the 4x3 video was sent out with the subtitle files, then there can potentially be alignment issues with the subtitles, or the subtitles can be wider than the video image itself. The kitting ensures that only content that has been conformed can be grouped together.


Confidential

d. The following diagram (diagram 6) is an example of how inventory can be applied to the above media center hierarchy. This example uses broadcast inventory content, but the media center should also be able to support inventory related to non-linear content.

e. The following diagram (Diagram 7) describes the requirement for an interface from Media Center to the Scheduling Systems. As the Media Center and Scheduling Systems are so tightly coupled, there is a requirement to have an interface from the Scheduling System to Media Center, which will allow a scheduler to query existing inventory with the Media Center and potentially request or order inventory to be fulfilled within the Media Center. This interface and the relationship of inventory to scheduled versions will require further design. This relationship may potentially be linked via the concept of an order out of the Media Center. The diagram below shows a side by side comparison of media center content organization and the scheduling system organization and how they related to one another.


Confidential


Confidential

5.1 Metadata

5.1.1.1 Programme records will originate and be registered through the determined MDM system. The MDM system will hold the master record to be used downstream for any systems in the broadcast workflow, where required.

5.1.1.2 Alpha records will require registration in the MDM system, but depending on workflow, the actual creation may be initiated outside of the MDM. The MDM system will hold the master record for alphas which can be used downstream for any broadcast systems where required.

5.1.1.3 Pending further analysis on alpha creation workflows, the MDM system may require a mechanism for "syncing" alpha records with downstream systems in the broadcast workflow, as a contingency.

5.1.1.4 Media Center will provide a mechanism to send alpha registration request to the MDM System.

5.1.1.5 The MDM system will be the source of all descriptive metadata associated to the programme or alpha records.

5.1.1.6 The MDM system will master the programme, alpha, territory, language and channel records.

5.1.1.7 All scheduling and programming detail will remain within the existing broadcast systems.

5.1.1.8 The Media Center will require an interface from the MDM system for the retrieval of descriptive metadata.

5.1.1.9 Any enhanced programme metadata will be synced to the MDM for future re-use.

5.2 Content Organization

5.2.1.1 Versions records, as currently defined by the Harris Systems, may or may not be required to be stored within the MDM system or within the Media center, depending on further analysis of Playout requirements.

5.2.1.2 Versions will remain a scheduling system concept, but will be translated within the interface, as needed, to interact accordingly with the media center for media ordering.

5.2.1.3 Versions, as defined by the Harris Systems, are not synonymous to the SPE definition of Alpha. Versions, at this stage of requirements, appear to be more closely related to the concept of order or profile.

5.2.1.4 Inventory within the media center will be organized in a programme > alpha > component > asset hierarchy. With an additional requirement to “group” conformed components. Pending confirmation by the core EMEA team, the Media Center will use a similar, but not necessarily identical, definition of alpha as defined by SPE.

5.2.1.5 The media center will provide the capability to have its inventory queried by the BMS (Vision) Systems. This will give programmers and schedulers the ability to query existing inventory and/or submit orders for the purpose of linear transmission from


Confidential

Vision or BMS. This interface may include the ability to select an alpha, territory, language, and channel as criteria for inventory search or order submitting.

5.2.1.6 Promotional assets will be stored within the media center as another alpha type and can be associated to any level of the programme hierarchy.

5.2.1.7 The media center will likely store the original ingest master as alpha within inventory, yet not to be used for direct transmission.

5.2.1.8 The Media center will store ancillary and supporting materials as components within inventory. There should be a way to store these components and relate them to their respective core media components.

5.2.1.9 In its best case, the Media Center will have direct integration to a centralized Rights Management System, where linear and non linear rights will be sourced. As a contingency plan, Media Center may need the ability to manually enter non-linear rights directly in the MAM. Linear -Rights will still be retrieved from Vision/BMS, but may not necessarily be entered in Vision/BMS itself, pending Rights Management solution.

5.2.1.10 When creating a new alpha edit, the media center will track the lineage of the alpha and asset used as the source.

5.2.1.11 The Media Center will have the ability to support a potential fourth level in the content hierarchy for ‘segments’. A segment is a child of an episode. (i.e. One news program can contain three distinct segments, one for each news story within the program.)

5.2.1.12 The Media Center will have the ability to support the concept of bundles, which represents a grouping of programmes. The most common case would be a grouping of episodes.

5.3 Content Identification

5.3.1.1 Due to the heavy reliance of smart numbering in the scheduling and playout systems, the media center project will require unique content identification across all levels of the content hierarchy as well as maintenance and mapping to the existing identifiers already established in the current workflows. “ Dumb” numbers will be used for internal purposes and “smart” numbers will be passed along as necessary.


Confidential

6.0 Reference Architecture

The Reference Architecture outlines the primary functional components and interfacing applications for the Media Centre.

Reference Architecture Diagram

Third Parties

Media Centre

London – Golden Square

QC/Edit

OperatorsOperators

Distributors(Various)

Distributors(Various)

SERVICES LAYERCommon platform that provides monitoring, routing, translation/transformation, protocol mediation, and message queuing

Media Asset Management

File Mgmt Metadata Mgmt

Ingest

Storage Mgmt/HSM

Replication/DR

Search

Content Processing

Standards Conversion

Wrapping

Transcode

Technical QC Content Formatting

Checksum

Graphics

Madrid

Budapest

PromosPromos

OperatorsOperators

Audio

Package Assembly

Supporting Material Acquisition

Metadata Transformation

File Naming

Delivery

Signiant

Aspera

FTP/SFTP

AssetsAssets

WORKFLOW MANAGEMENTOrchestration of Business Process and Content Processing Workflows (i.e. Ingest, QC, Content Processing, Delivery)

Assets

Assets

AssetsMetadata

Playout

Non -Linear

Interfacing Systems

IngestAsset

IngestMetadata

IngestAsset

IngestMetadata

Assets

Assets

HARRIS VISION

(SCHEDULING)

HARRISLANDMARK

(AD SALES)

HARRISBROADCAST MASTER(SCHEDULING, AD SALES)

NETGAIN(BUSINESS

INTELLIGENCE)

GPMS(TITLE/ALPHA METADATA;

RIGHTS)

EAGL(SUPPORTING MATERIALS;

ARCHIVE)

Metadata

Metadata

Master Data Management

DistributorProfiles

DistributorProfiles

ScheduleData

ScheduleData

Inventory MetadataInventory Metadata

PackageMetadataPackage

MetadataProgramme

/AlphaProgramme

/AlphaClient Master

ProfilesClient Master

Profiles

SAP &FINANCIALS

MANAGEMENT

Post HousesPost HousesAssets

FARMERS WIFE(FACILITY MANAGEMENT)

Future

CINESHARE (HISTORICAL DROP-POINT

FOR DISTRIBUTORS)

Technical Logging

LocalisationLocalisation

Security

IDM(SPE COMMON

AUTHENTICATION)

Metadata

User Interface

Vendor Portal

Operations Portal

Delivery Confirmation

Utility Services

Event Management

System Logging

Exception Management

Notification

RemoteIngest

RemoteIngest

PROVYS(SCHEDULING)

Reporting

INTERFACESIngest Inventory DeliveryOrdering/Request Search Programme Metadata

Reference Architecture Guiding Principles

A key requirement of the Media Centre architecture will be its ability to be flexible to not only meet the currently known means, but also to be able to scale in functionality to meet future needs – both short and long term. A key aspect of short term flexibility would ideally be accomplished through system configuration (as partially discussed in Section “E.3.6.2 Configurability (user)” in the original RFP) that can be accomplished by SPTN staff and not through customization requests to a vendor.

Examples of the Flexibility required include, but are not limited to the following:

Workflow creation/modification


Confidential

o Changing the “Ingest” workflow/pipeline as is default in their “off the shelf” solution to meeting our needs (i.e. drop boxes, configurable generation of proxies, etc.)

o Adding new workflows to move content after Ingest for QC/Edits, Localisation, etc.

Deliverables/Output configurationo Creating/updating technical specifications/profiles that define how the

MediaCentre processes and then deliveries content

Asset Structure and Metadata configurationo Changing the metadata structures and configurable fields associated to assetso Creating hierarchies or organization of assets that meet our needs

Report Creation and configurationo Creating new reports and updating existing reports to support day to day

operations of the MediaCentre

Bidders are requested to explain how our Operators could accomplish the above flexibility with the proposed solution as well as call out when vendor help would be necessary.

Another guiding principle is around how the MediaCentre will manage the priority of work. It is important that each of the services and tasks that are being performed in or by the MediaCentre be prioritized, as defined in RFP Addendum Section 4.9.1.5. Prioritization should be an automatic function of the Media Centre, especially as work is queued, but also have the ability to be manually overridden by operators with sufficient privileges to allow tasks to be moved up in the queue.

Additionally, queuing and prioritization will need the ability to take into account a “Quality of Service” or QoS most commonly by distribution/playout channel. For example, if the automated QC service can process 6 programmes at a time governing QoS is needed to ensure "fairness" when the "pipe" gets full. One channel can use all 6 QC analysis streams if it is the only channel in queue. However, if two other channel programming shows up, a potential QoS business rule would be to evenly divide the capacity in thirds (2 analysis streams each) to ensure one channel is not “starved”.

Reference Architecture Interfaces and Common End-points

The Media Centre should be built upon/leverage a platform that is service-oriented in design and, thus, provides open API access. Additionally, when presenting interfaces to external systems, it is desired that the Media Centre expose generic interfaces vs. specific integrations (i.e. Scheduling Interface vs. Harris Vision Interface). Below are general considerations as well as the six major interfaces expected of the Media Centre that should facilitate the specific system integrations defined in the RFP.

General Concepts


Confidential

o General Service Interfaces as well as access to a detailed API that exposes all of the system functionality

o API access to service queue visibility for processing (messages, services)

Ordering/Request (bi-directional)o Create, update, cancel based on call from external system (e.g. Scheduling

System(s))o Defines programmes to be delivered to a client (such as playout, VOD, OTT, etc.)

by a specified due dateo Asynchronous interface with a callback mechanism to update status.

Searcho Ability to search data within the Media Center across several categories of data

Asset inventory Programme metadata Order/request data

Programme Metadatao Create, update, deactivate programme metadatao Including content hierarchy (i.e. Programme-Episode) as well as descriptive data

(i.e. synopsis, talent) in various languages

Ingesto To remotely trigger ingest of assets + metadata

Inventory (bi-directional)o Create placeholders/shells to represent expected arrival of assets to meet

scheduling needso Update asset metadata or status (i.e. Available, Deactive)o Asynchronous interface for status callback to Scheduling system(s)

Deliveryo Status for/from the tools on status (percentage progress, success/failure)

6.1 Reference Architecture Definitions

6.1.1 Media Asset ManagementProvides the foundational services for the management of files and metadata about the assets within the Media Centre (including Programme/Alpha metadata interfaced into the Media Centre). It is likely that in a Phase 2 these Services will be distributed for disaster recovery/business continuity or performance reasons, perhaps across geographies, so this should be factored into the proposed architecture.


Confidential

6.1.1.1 File ManagementAlso can be referred to as the “Vault Services,” the File Management service(s) provide the digital file analog to the management of physical assets. It coordinates the formal storage and movement of files around major storage pools in the Media Centre. The File Management Services will need live visibility into Hierarchical Storage Management (HSM) storage tiers/locations (i.e. what storage media it is on and where it is?) for operational support requirements.Priority queuing will be required for this service to manage load and to contribute to stability and meeting performance requirements.

6.1.1.2 Metadata ManagementThe repository where metadata is stored and updated within the Media Centre for use in digital file inventory management/processing and business/title metadata for packaging

6.1.1.3 IngestServices facilitating the process of getting components and their metadata verified and QC’d before entering the Media Centre. In that process these Services will often be orchestrated with Content Processing Services (e.g. automated technical QC, checksum calculations) and provide additional validation logic.

6.1.1.4 Technical LoggingToolsets that allow the playback of master files and, preferably, their frame-accurate proxies for the purpose of capturing segment metadata (e.g. time code in and out points for areas such as bars/tones, commercial blacks, logos, program). Ideally, these tools would be paired with a content identification system that would be able to pre-process the video and provide suggestions for the operator to confirm/complete.

6.1.1.5 Replication Services (for Distributed Computing and Disaster Recovery)Out of scope currently for Phase 1 (mainly for use in distributed operations and disaster recovery/business continuity), the hardware and software stack proposed must support replication capabilities and be aware of distributed facilities. In this case, “Replication” should be capable to support full or partial based on policies (i.e. replicate only international content).

6.1.1.6 Storage ManagementThis is the software module that facilitates the management and efficient utilization of the multi-tier storage environment used by the MediaCentre. Storage types will include landing zones for transferred content, WIP for content processing and packaging, bulk storage, etc. Additionally, this module facilitates the archiving and retrieval of content to/from tape or disk.

6.1.1.7 Search (Internal/External)Facilitate the queries against primarily structured internal Media Centre data/metadata (from the UI or from other Media Centre services) as well as linking for searches of external systems. This should include all component inventory as well as programme metadata.


Confidential

6.1.2 Utility ServicesMost of these functions/services deal with logging, event and exception management, and notification during workflow execution. These should produce data that is auditable for events across the system and accessible via search.

6.1.2.1 System LoggingSystem Logging helps in monitoring and diagnosis of complex distributed systems. Centralized logging and auditing of services, errors, service orchestration status, and integration with logging from other applications (via integrated messaging) will be an important element of Media Centre. The solution should capable of managing, archiving, reviewing, and auditing of all the logs produced by the system.

6.1.2.2 Event ManagementEvent Management centralizes all alerts from various event sources, filter those events based on priority, correlates the alerts with other alerts, de-duplicates and consolidates the repeat events, and provides event enrichment by leveraging other disparate data sources. The solution should be able handle both external & internal events.

6.1.2.3 Exception ManagementThe exception management architecture of the solution should have the capability to:

Detect exception Wrap one exception inside another Log and report error information Generate events that can be monitored externally to assist system

operation

6.1.2.4 NotificationNotifications provide a mechanism for distributing information about events within or external to the system. Notifications provide a means for communicating between objects. An effective notifications system decouples the message sender from the message receiver as well as the method of notification. With notifications, a broadcast paradigm is implemented in which objects post notifications to a notification center, which then sends messages to objects which have registered their interest in the type of event, or the originating object.The most common form of notification external to this system will be to send email messages to operators (such as to request action on workflows) or delivery end points (to notify them that a file has been delivered/staged).

6.1.2.5 ReportingThe reporting services represent the functionality to support the generation and execution of reports necessary for the operation of Media Centre. The data include, but should not be limited to, information on workflows, assets,


Confidential

utilization, service queues, users and groups. Reporting data stores should be considered so as not to adversely impact performance of the production Media Centre.

6.1.3 User InterfaceThe user interface lists the known user interfaces that are needed to support the functionality referenced in the white papers. The user interfaces listed here represent “portals.” The portal term is used as it is preferable that there be a single UI with different views, features based on user authorization.

6.1.3.1 Operations PortalThe Admin portal provides operational administrators visibility into all operational data within the Media Centre. This can include, but is not limited to, Inventory, Technical Specs, Workflows, Operational KPIs.

6.1.3.2 Vendor PortalThe client/vendor portal provides an interface for clients and/or vendors to interact with the Media Centre. This portal should provide visibility into Workflows and Tasks as well as provide file transfer capabilities to enable vendors to provide or download assets that are required to fulfill Workflows. Vendors can be either internal or external contributors of content.

6.1.4 Content ProcessingCollection of services generally characterized by the integration of third party software for the purpose of transforming or otherwise manipulating Components to meet a desired Technical Specification. It is likely that in Phase 2, or sooner, these Services will be distributed in groups for disaster recovery or performance reasons, perhaps across geographies, so this should be factored into the proposed architecture.

6.1.4.1 TranscodeConversion of file format (codec and or wrapper) as well as other file properties (such as bit rate, frame structure, frame size, etc.) from a given set of inputs to outputs.

6.1.4.2 Standards ConversionGenerally includes: Pull down or rate adjustment to convert from HD into SD cadence, color space, etc.Changing frame rates, resolution, etc. within HD such as from 1080i to 720pWithin SD, PAL to NTSC and vice versa

6.1.4.3 WrappingWrapping of Product and or Packages for further processing in common formats such as MXF, ZIP/TAR/Stuff-It, directory structures.

6.1.4.4 ChecksumCRC, MD5.


Confidential

6.1.4.5 Technical QCAnalyze files intended for ingest or delivery for integrity and other issues (e.g. bit rate, codec, colorspace, aspect ratio, format compliance).

6.1.4.6 Content FormattingAddition/replacement/removal of cards/logos, bars/tones, slates, commercial black (at defined locations), and addition/subtraction of “textless” material to a set location in the programme.

6.1.5 Package Assembly ServicesPackage Assembly Services provide the functionality to combine product and supporting materials according to client specifications and prepare for delivery.

6.1.5.1 Metadata Transform Services that transform partner supplied metadata to client or partner specific formats.

6.1.5.2 Supporting Material AcquisitionServices enable Media Centre to identify and stage package elements required for delivery such as images, trailers, scripts, etc.

6.1.5.3 File NamingSpecific file naming conventions are required by clients. These services must allow for dynamic naming of package elements and packages based on business rules defined in the client profile.

6.1.6 Delivery ManagementDelivery management is needed in order to ensure that requests result in a delivery. They consist of 3rd party products which can be leveraged for managed file transfers as well as custom notifications and confirmation components that will need to be built. Examples of known delivery methods that Media Centre will be required to support include:

6.1.6.1 AsperaIntegration of Aspera as a service. However, the install and management if Aspera is not in scope for the Media Centre project. A separate project will be charged with the install and configuration.

6.1.6.2 SigniantIntegration of Signiant as a service. However, the install and management if Signiant is not in scope for the Media Centre project. A separate project will be charged with the install and configuration.

6.1.6.3 FTP/SFTPDirectly supported via Media Centre.

6.1.6.4 Delivery ConfirmationEnsures that what was delivered matches what was sent as well as creating the necessary messages/status updates for the staging and completion of delivery.


Confidential

6.1.7 Services LayerMost of these functions/services deal with performance, security, monitoring, protocol mediation, and delivery of business services. Most of these functions/services are typically managed at the Service Bus level.

6.1.7.1 Monitoring, VisibilityThe capability to manage and monitor the SOA application infrastructure and the messages traveling to/from services (i.e. for faults, errors, delivery failures).

6.1.7.2 RoutingThe solution should be able to route incoming messages based on information in the message or based on the end-point it is sent to. The routing can be 1:1 or 1:many.

6.1.7.3 Translation/Transformation The solution should be able to translate or transform incoming messages before sending to a receiving service. This can include simple formatting as well as data mapping. This is commonly performed to standardize incoming from external systems into a canonical format.

6.1.7.4 Protocol MediationBuilt-in mediation capabilities will make it straightforward for the Media Centre to reconcile the incompatible protocols, data/schema formats and interaction patterns of disparate connected resources. Intermediary services such as these allow integration architecture to eliminate dependencies between service consumers and service producers, making it easier to create a loosely-coupled system that can be changed without disruption.

6.1.7.5 Message Queuing/Guaranteed DeliveryThe solution must be able to queue messages it receives in order to both buffer them for a downstream service (often to mitigate performance issues) as well as ensure delivery should the target service be non-responsive (i.e. service down, service busy, etc.).

6.1.8 Workflow ManagementThe Workflow Management layer manages the execution/orchestration and monitoring of workflows which can contain automated and manual activities. The Media Centre will execute business process and content processing workflows as outlined in the RFP.

6.1.9 SPTN Offices

6.1.9.1 London – Golden SquareDistributors will generally interact with the Media Center for the delivery of a file(s) for ingestion into the Media Centre.

6.1.9.2 Remote IngestAbility for the Media Centre to perform the Ingest of components from assets stored in a remote location (i.e. London, Madrid, Budapest offices) with the ability to move the assets to the Media Centre data centre.

Assets should be processed per the designed workflow, as well as copied or moved, either by workflow policy or operator action, to the central Media


Confidential

Centre storage. The remote ingest module should include the capability to perform the full ingest workflow as defined in Section E.2.1 in the original RFP, which includes checksum creation/validation, automated technical QC, transcode to SPTV House Format (Section J.3 of original RFP).

This functionality is intended to facilitate remote office workflows and prevent the need for assets to unnecessarily move to the Media Centre and then back out to a remote office where work needs to be performed. As such, the solution should allocate the necessary hardware and software locally for N+1 redundancy in the local offices to support remote Ingest.

6.1.9.2.1 QC/Edit Tools IntegrationAs defined in the original RFP document.

6.1.9.2.2 Audio Tools IntegrationAs defined in the original RFP document.

6.1.9.2.3 Graphics Tools IntegrationAs defined in the original RFP document.

6.1.9.2.4 Promos Tools IntegrationAs defined in the original RFP document.

6.1.9.2.5 Localization Tools IntegrationAs defined in the original RFP document.

6.1.9.3 Madrid, Budapest OfficesThe offices in Madrid and Budapest will require similar abilities to each other. This is currently a subset of the requirements for the London office, though it should be expected, and the system capable, of expanding to include all functions to this office as required.

6.1.9.3.1 Remote IngestSee Above

6.1.9.3.2 PromosSee Above

6.1.9.3.3 LocalizationSee Above

6.1.10 Security and Administration Services and IDM Integration

The principal objectives of the security architecture are as follows:


Confidential

6.1.10.1 Complies with the rules set forth in Sony Corporations’ Global Information Security Standards (GISS) and Global Information Security Policies (GISP) for protecting our information assets; Security compliance should extend to industry standards such as ISO27001 in future releases

6.1.10.2 The security architecture should consist of services that can be accessed by all relevant processes. It is required that the system be integrated with Sony Pictures Identity Management (IDM) architecture to facilitate Authentication (defined below). Additionally, the User Administration process needs to be able to accommodate the IDM integration which needs to be articulated in the response.

6.1.10.3 Authentication – A set of process and procedures that establish with a high degree of confidence the identity of a given individual, service or machine, through credentials (e.g. username and password, certificates).

6.1.10.4 Authorization – The process of determining, by evaluating applicable access control information, whether an individual, service or machine is allowed to have the specified types of access to a particular resource. Usually, authorization is in the context of authentication. Once a user/service is authenticated, it may be authorized to perform different types of access.

6.1.10.5 User Administration – The process of adding, updating, and deleting user accounts from applications and directories; user administration may include the subordinate processes associated with supporting regulatory compliance by auditing the system and appliance access that has been assigned to active user accounts.

6.1.10.6 Auditing – Availability of activity data/logging in the application for the use of auditing access and service/resource usage.

6.1.11 Interfacing SystemsThe following are in addition to the Interfaces as outline in Section “E.3.2 Interfaces” from the original RFP, with the following exception also noted below: Harris Landmark will not be integrated to the MediaCentre.

6.1.11.1 GPMSGPMS provides title master functionality for SPE and contains the programme, and alpha, metadata. The data from GPMS will be used for inventory organization as well as for package metadata (e.g. synopsis, talent, genre) that will be required by the Media Centre especially for VOD delivery. GPMS can provide data to the Media Centre through WebMethods managed publication(s) via web services.For the Media Centre, it is envisioned that GPMS will provide Programme metadata as well as rights information.

6.1.11.2 EAGLEntertainment Assets Global Library ('EAGL') is an in-house custom developed media asset management system used for image, video, and documents. Features include metadata assignment, workflow, security roles and groups, video and image transcodes, secure content links for download via Aspera.


Confidential

For the Media Centre, EAGL will be a source of images, documents, and other assets necessary for distribution packages such as those defined in the VOD workflows.Additionally, the Media Centre should be able to “publish” or distribute content to EAGL for Ingest and management in that system.

6.1.11.3 CineshareCineShare is an in-house custom developed media asset management system. Unlike EAGL, which is more metadata search-based, Cineshare can be likened to a managed FTP content transfer solution, integrated with security, transfer acceleration, storage and having a folder-based presentation to users.

6.1.11.4 Harris VisionProgramme Scheduling for the majority of UK managed channels (some channels are still managed in Provys, as noted below) as well as all of the channels managed in Budapest. There are two separate instances of Vision – for the UK and Budapest Channels respectively.

6.1.11.5 Harris LandmarkAd Sales system used in the UK and Budapest managed channels. This system DOES NOT require integration into the Media Centre. The necessary programming data related to Ad Sales will come to the Media Centre from Vision (Vision and Landmark are integrated).

6.1.11.6 ProvysProgramme Scheduling for a number of UK channels not managed by Harris Vision.

6.1.11.7 Harris Broadcast MasterProgramme Scheduling and Ad Sales for Madrid managed channels.

6.1.11.8 Farmer’s WifeWork Order and Facilities management toolset used in the UK offices. Integration is NOT required in the scope of this RFP, however, future integration is likely to help coordinate operations staff. As such, references to from bidders on previous experience integrating Farmer’s Wife will be taken into consideration.

6.1.11.9 Net GainBusiness Intelligence platform used by SPTN for complex data analysis. While direct integration is not required, it is expected that the system can make its data model available for export via an Extract, Transform, Load (ETL) process.

6.1.11.10 SAPFinancials system used by Sony Pictures. No integration is required.

6.1.12 Third Parties

6.1.12.1 DistributorsDistributors will generally interact with the Media Centre for the delivery of a file(s) for ingestion into the Media Centre.


Confidential

6.1.12.2 Post HousesPost Houses will generally interact with the Media Centre for the delivery of a file(s) for ingestion into the Media Centre. This could be video and audio captured from tape, dubbed/localized audio, subtitles/captions, etc.

6.1.13 Master Data Management (Supporting Data Services)Supporting data services provide the services required to manage the data that Media Centre requires from an operational perspective. The following list of data categories must be managed directly by the Media Centre. Some of these categories need not be the master data stores.

6.1.13.1 Programme/Alpha

6.1.13.2 Distributor Profiles

6.1.13.3 Schedule Data

6.1.13.4 Client Master Profiles

6.1.13.5 Inventory Metadata

6.1.13.6 Package Metadata


Confidential

7.0 Appendices

Appendices include the following sections: Appendix A Bidder InstructionsAppendix B Resource Load ScheduleAppendix C Master Services AgreementAppendix D Information Security Questionnaire


Confidential

8.0 Appendix A

Appendix A includes the following sections: Appendix A-1 Outline for ResponseAppendix A-2 ReferencesAppendix A-3 Pricing Proposal [Fixed fee or Time and Materials]Appendix A-4 Resource Loading Schedule


Confidential

8.0 Appendix A-1 – Outline for Response

The following should be included in Bidder response: a) Understanding of scope and SPE’s desired solution as applicable from information

provided in the RFP package.b) Project plan and timeline including major tasks, milestones, and start and end datesc) Project approach and methodology including description of key activitiesd) Outline and definition of deliverables for all services in scopee) Project team and organization including roles, responsibilities and summary profiles of

key personnel (please delineate any subcontractors)f) SPE resource requirements including roles, responsibilities, skill sets and length of time

involvedg) Assumptionsh) Similar project experiencei) Project fee schedule [Fixed Fee or Time and Materials, T&E, Project Term]j) [Data migration/conversion strategy]k) [Change management approach including the following:]

Communication plan Risk mitigation plan Training plan

l) [Critical success factors]m) Other items as determined by Bidder


Confidential

8.1 Appendix A-2 - References

List a minimum of 3 references for whom your company has provided a similar solution as outlined in the scope of this RFP package. To be considered responsive, you are to provide the following information per the attached document:


Confidential

8.2 Appendix A-3 – Pricing Proposal

A full description of all Bidder costs to be paid by SPE must be included with the proposal. This must include all fees and expenses.


Confidential

8.3 Appendix A-4 – Resource Loading Schedule

Please complete the attached Resource Loading Schedule in details and submit as part of your response under Appendix A-4 as a separate attachment.


Confidential

9.0 Appendix B – Information Security Questionnaire

Please complete the attached Information Security Questionnaire and submit as part of your response under Appendix B-1 as a separate attachment.


sony pictures entertainment mediacentre rfpbusiness... · web viewin over 60 international...

Documents