Sony Pictures Entertainment (“SPE”) - WikiLeaks Distribution... · CONFIDENTIAL SPE/DADC Request for Proposal 5 1.02 Strategy and Context The Sony Parties have developed a multi-phased,

CONFIDENTIAL SPE/DADC Request for Proposal

1

Sony Pictures Entertainment (“SPE”)

and

Sony DADC (“DADC”) `

Request for Proposal (“RFP”)

Distribution Backbone Project (“DBB”) for

Release 1: Build and Deploy DBB Infrastructure and Distribution Content Processing CoE

Issued by: Dennis Bond

Date Issued: June 15, 2009 Responses Due: July 17, 2009

RFP Reference Number: D06152009

Executive Sponsors: Chris Cookson, Sony Pictures Technologies

Michael Frey, Sony DADC

[This Request for Proposal is confidential and proprietary to Sony Pictures Entertainment and Sony DADC]


2

Table of Contents

1.0 Introduction ..............................................................................................4

1.01 About this Request for Proposal ....................................................4 1.02 Strategy and Context .......................................................................5 1.03 Disclosure.........................................................................................6 1.04 Background Summary.....................................................................6 1.05 Sony Pictures Entertainment (SPE)................................................7 1.06 Sony DADC.....................................................................................14

2.0 Project-Specific Planning Guidance.....................................................16 2.01 Project Management and Governance .........................................16 2.02 Responsibilities Sony Parties Plans to Retain ............................17

3.0 Scope Summary .....................................................................................17 3.01 Guiding Principles .........................................................................18

4.0 RFP Process ...........................................................................................19 4.01 Time Line ........................................................................................20 4.02 Individual Supplier Q&A Sessions - Week of June 22 ................20 4.03 Individual Supplier Q&A Sessions - Week of July 6 ...................21 4.04 Future Participant Contact ............................................................22

5.0 RFP Deliverables....................................................................................22 5.01 Response Deliverable Format.......................................................22

Appendix A – Glossary..................................................................................26 Appendix B – Process Flow Description .....................................................38 Appendix C – White Papers ..........................................................................42 Appendix C-01 Fundamentals of Digital Supply-Chain ..............................43 Appendix C-02 Partner / Client .....................................................................46 Appendix C-03 Request Management..........................................................51 Appendix C-04 Inventory Management........................................................55 Appendix C-05 Workflow Master Data .........................................................61 Appendix C-06 Manufacturing Planning ......................................................66 Appendix C-07 Task Management................................................................71 Appendix C-08 Managed Multi-Tiered Storage Environment .....................75 Appendix C-09 Search...................................................................................81


3

Appendix C-10 Ingest / Encode Management..............................................85 Appendix C-11 Package Metadata................................................................90 Appendix C-12 Package Creation / Management ........................................94 Appendix C-13 Financial Processes ..........................................................101 Appendix D – Supporting and Additional Requirements .........................107 Appendix E – Client Product Specifications..............................................118 Appendix F – Content Processing Functions............................................120 Appendix G – Master File (eMaster) Definition..........................................122 Appendix H – Functional Reference Architecture.....................................124 Appendix I – Non-Functional Estimating Guidance..................................139


4

1.0 Introduction 1.01 About this Request for Proposal In issuing this Request for Proposal package (“RFP”), Sony Pictures Entertainment (“SPE”) and Sony DADC (“DADC”), (collectively “Sony Parties”), seeks fixed fee proposals from qualified suppliers to assist in the development and integration of systems to realize its digital distribution strategy. The strategy will be initially deployed through the Sony Parties business units.

Working in a consolidated, highly collaborative fashion, the Sony Parties will build-out a means for digital distribution with the following capabilities (described further in subsequent sections):

• Enable low cost, automated, file-based distribution content processing and delivery workflows to supplant both physical media and file based workflows that SPE currently outsources to suppliers;

• Adapt to new formats and content processing enhancements as the market and technologies evolve;

• “Commercialize” the service such that DADC can market it in any manner or fashion and to any viable market segment that could make use of the services;

• Be ”content agnostic” (in terms of the type or eventual use of the digital content) to accommodate any digital content; and,

• Exploit supply chain best practices, adapted to a digital media flow.

This document and its supporting appendices provide background and context, describe the RFP process, summarize the Sony Parties’ strategy, and provide guidance about the scope of this first release of our multi-release implementation approach.

We appreciate the challenge presented with our approach as we intend to clearly articulate our expectations without materially restricting your ability to respond with creative and innovating approaches and tools to support our stated requirements as well as those that may not be specifically described. If anywhere we should fail to articulate some aspect that you believe to be pivotal, we encourage you to ask and to propose your most creative approaches and solutions.

Your proposal will be for Release 1 only; however, we want to ensure that later releases are not adversely hampered by decisions made for this release or, worse, that the grander vision cannot be economically realized. Therefore, we provide information beyond Release 1 to facilitate that planning.

This RFP is but one element of our proposal process. This document coupled with your questions and at least 2 conferences should enable you to gather the information needed to respond to our request.


5

1.02 Strategy and Context The Sony Parties have developed a multi-phased, multi-year approach to establish and operate the Distribution Backbone (DBB) and to make operational the resulting solutions and services into a full-fledged offering by DADC to a broader market. The strategy to achieve this vision includes ingesting content digitally and managing it seamlessly through delivery to a client.

Although content supply chains have become more and more digital, physical media and manual workflows still proliferate around ingest, storage, product assembly and package delivery.

Media Service Companies have been slow to leverage automated file based workflows because they have made huge capital investments in their film and tape infrastructures and want to protect revenue streams from activities that would be made redundant by the new workflows.

But the maturation of SOA technology, and decreased costs for generic storage and processing power have enabled a significant opportunity to orchestrate manual workflows and create an infrastructure that minimizes the need for physical media.

An automated, scalable, flexible and low-cost solution is an imperative to support new paradigms in entertainment distribution.

Sony Corporation is uniquely positioned to develop, operate and market the solution, which is core to its mission and competitive advantage.

Our strategy calls for building on the Release 1 infrastructure with additional processing functionality which will enable additional content and clients to be serviced. The ultimate end-state is to have all digital content and all digital-ready clients be serviced wholly through the DBB, ideally with no labor contribution.

Release 0Foundational● Establish Tech Lab● eMaster creation● SPTI / DDI Servicing PoC● Master data and Metadata

assessment● Plan Ascent/DIAMONDS

transition● Financial policies and

procedures

Release 4Priority 4● Implement digital archive

standards

Release 5Priority 5● Vendor and client self-

service● Rights and clearance

integration

Release 3Priority 3● Capabilities and workflows for

Syndication and Ancillary clients

● Integrate with Digital Networks solution

● Enable creative review interface

● Integrate with PRISM, Ventana● Automated recipe assembly

capabilities, including audio layback, subtitle, MET overlays, and automated technical QC

Release 1Foundational● SOA, storage, network

infrastructure● Disaster recovery planningPriority 1● Grow SPTI / DDI servicing● Integration with DMG repositories

and GOLD, GPMS

Release 2Priority 2● Grow SPTI / DDI servicing● Capabilities and workflows for

EST, Pay TV, and Mobile Clients● Reporting capability

Release 0Foundational● Establish Tech Lab● eMaster creation● SPTI / DDI Servicing PoC● Master data and Metadata

assessment● Plan Ascent/DIAMONDS

transition● Financial policies and

procedures

Release 4Priority 4● Implement digital archive

standards

Release 5Priority 5● Vendor and client self-

service● Rights and clearance

integration

Release 3Priority 3● Capabilities and workflows for

Syndication and Ancillary clients

● Integrate with Digital Networks solution

● Enable creative review interface

● Integrate with PRISM, Ventana● Automated recipe assembly

capabilities, including audio layback, subtitle, MET overlays, and automated technical QC

Release 1Foundational● SOA, storage, network

infrastructure● Disaster recovery planningPriority 1● Grow SPTI / DDI servicing● Integration with DMG repositories

and GOLD, GPMS

Release 2Priority 2● Grow SPTI / DDI servicing● Capabilities and workflows for

EST, Pay TV, and Mobile Clients● Reporting capability

Q4Q3Q2Q1FY 2009

Q4Q3Q2Q1FY 2009

Q4Q3Q2Q1FY 2010

Q4Q3Q2Q1FY 2010

Q4Q3Q2Q1FY 2011

Q4Q3Q2Q1FY 2011

Q4Q3Q2Q1FY 2012

Q4Q3Q2Q1FY 2012

(Note: SPE fiscal year April 1-March 31)


6

The sequence depicted above is illustrative only; many scenarios are possible and timing is subject to other factors. However, the approach provides the ability for the program to be adapted as appropriate based on changing elements in the business case or for changing priorities for any reasons.

Release 0 initiatives are not included in this RFP in terms of work being requested.

1.03 Disclosure With regard to any discussions, information or materials pertaining to both the initial Request For Information (“RFI”) package dated November 5, 2008, this Request For Proposal package dated June 15, 2009 and any updated thereto or any other discussion, information or materials related to the DBB, you are reminded that, prior to your firm’s sharing any such discussions, information or materials with any person(s) or entity(s) not currently covered directly by our Non-Disclosure Agreement (“NDA”) with your firm dated October 21, 2008 and as amended June 11, 2009, your firm must satisfy all of the following requirements: (1) obtain from each of the Sony Parties business units individually its pre-approval for such person(s) or entity(s) potentially being allowed to participate in the DBB, (2) await confirmation from each of the Sony Parties business units individually, in writing, that such person(s) or entity(s) has directly entered into an NDA with the Sony Parties regarding the DBB, and (3) affirm to the Sony Parties, in writing, that your firm has also entered into an NDA with any such person(s) or entity(s) specifically covering disclosures related to the DBB.

The Sony Parties have also advised all parties to such NDA’s that the subject matter, processes, workflows, functional requirements, roadmaps, and any software and/or hardware developed for the DBB are proprietary and subject to exclusive commercialization by the Sony Parties, or their respective assignees.

1.04 Background Summary This RFP is the culmination of years of internal discussions, investigation and several intermediate steps in the form of specific systems and processes preceding this comprehensive initiative. SPE has spent a year of planning, organizational development and has made numerous investments in R&D in preparation of issuing this RFP. The team is guided by senior leadership and has the support of the Sony Parties’ corporate headquarters in Japan. The RFP team includes members from the stakeholder business units – with team leadership by key members from the Sony Parties – as well as complementary support all working closely together.

Given trends toward more digital distribution and the emergence of new sales channels for product, this initiative is intended to ultimately produce a “content agnostic” mechanism for the entire management life-cycle of any digital content. This opens potential markets previously not associated with traditional media entertainment companies. We also believe these trends are developing rapidly and that our estimates for the potential size of the market and the timing of it reaching various


7

utilization thresholds may be conservative. Hence, we have a heightened sense of urgency regarding implementing quickly and with a flexible platform. Certain primary supplier candidates were issued and participated in an earlier RFI process. Material changes have occurred in the months since that concluded:

DADC has emerged as an ideal partner to SPE for the deployment of the Distribution Backbone building on their rich experience in the physical distribution of media content and with digital music distribution.

Further, DADC plans to commercialize the resulting processes and systems for market to third-parties including going beyond the traditional media entertainment market

1.05 Sony Pictures Entertainment (SPE) SONY PICTURES TECHNOLOGIES Pictures Technologies leads SPE’s organization for the Distribution Backbone project. The organization includes Worldwide Product Fulfillment (WPF) and Digital Media Group (DMG) which are the divisions within SPE that will be leading the DBB project effort. WPF includes Asset Management, Client Operations, Global Logistics, Digital Authoring Center – Technical Operations, and Corporate Systems and Operations.

WPF manages SPE’s library and distribution operations for all of Sony Pictures Entertainment’s post-theatrical business lines. The division provides services related to the preservation and restoration of assets, mastering and foreign language creation, content manipulation and tape and file-based delivery to worldwide clients. WPF has six offices with most employees based in Culver City.

Below summarizes Sony Pictures Technologies divisions’ current activities:

Digital Media Group

Asset Management

Client Operations

Global Logistics

Digital Authoring Center –

Technical Operations

Corporate Systems

and Operations

Develop and maintain digital media services for SPE business lines

New release and catalog mastering

Content delivery Corporate asset storage and distribution facility

DVD and Blu-Ray compression and authoring

Global Product and Title set-up and maintenance

Architect, develop and operate enterprise digital asset management and other digital media technologies

Audio track management and conform

Supplier management

Physical media asset management in cold and standard vaults

File-based delivery for theatrical marketing EPK, theatrical TV spots

GOLD (Xytech) business support

Asset Preservation

Distribution content security

Ad/Pub distribution

Content editing for television, airlines, syndication, mobile and marketing

Stock Footage and Clip Servicing

Digital Media Group


8

The Digital Media Group (DMG) researches, develops and maintains digital media services that enable SPE businesses to more effectively and securely create, manage, distribute and monetize its assets. The group’s digital asset support systems are used by WPF, SPE business lines and external suppliers. DMG provides digital asset management, digital media workflow and digital media production services covering material ranging from photos and trailers, to dubbing tracks, and screeners.

Asset Management

This group is responsible for the safekeeping and stewardship of all SPE original assets. Services also include restoring elements, transferring film to tape, digitizing library titles into HD and providing “film clip” elements. The group “hands-off” approved video and audio masters to the next group involved in the content transformation process. They provide all Distribution materials required to service DVD, VHS, PPV, Television and VOD including HD masters, down-conversions to NTSC/PAL, and home theater mixes.

Client Operations

The servicing group is responsible for element creation, delivery and retrieval of product to internal and external clients at the highest quality standard at the lowest possible cost. This group supports worldwide contractual requirements for Home Entertainment, Television, Digital, Mobile and Ancillary markets. The department also creates foreign language dubs and subtitles in over 30 languages. In addition they are responsible for the distribution of Domestic Television’s syndication product. The department coordinates the integration of barter ad spots sold by the television group into syndicated programs which are digitally distributed via satellite.

Global Logistics

This group runs a full-service inventory, distribution, shipping and receiving facility located in Inwood, NY. It is SPE’s primary vault for over 1.2 million film, tape and marketing assets. It is the main hub for international distribution of film, tape and Advertising/Publicity materials. Other services include standard and cold storage, pick/pack/ship services and managing all export/import customs requirements.

Digital Authoring Center (DAC) /Technical Operations

The DAC is a leading Blu-ray and DVD compression and authoring facility handling top titles from SPE and other studios. Technical Operations supports WPF’s digital distribution initiatives, digital asset management, supplier strategies, system support, and content security related to product manufacturing and distribution. They construct file based methodology to ingest, create and distribute digital content to SPE clients; design supplier strategy to migrate hundreds of thousands of analog elements to digital files; develop with existing SPE groups’ methods to secure cross-platform content distribution and develop anti-piracy practices.

Corporate Systems and Operations


9

This group is responsible for oversight of the processes and technology involved with the Global Product Management System (GPMS), Global Order Library Database (GOLD) and the Sony Pictures Internet Document Repository (SPIDR). GPMS oversight includes product set-up, maintenance and system enhancements. The other activities involve registration, collection and administration of ancillary revenues distributed by various worldwide Collection Societies by providing and updating title metadata, ownership rights, and releasing information. GOLD (Xytech) oversight involves management of support and training for approximately 260 users worldwide and data integrity for more than 3.5M elements tracked. SPIDR oversight includes business sponsorship of SPE’s web-based content management system. This group also manages the Stock Footage and Clips servicing business for SPE which maintains an online Stock Footage Library of over 100,000 shots.

EXISTING DIGITAL PROCESSING AND DISTRIBUTION SYSTEMS

DIAMONDS (Digital Inventory Asset Management Online Distribution System) is SPE’s primary digital media inventory system. DIAMONDS workflows are managed with SPE’s processing partner Ascent Media. In general, content is encoded at the location of the video master and ingested into DIAMONDS through one of six locations. Core production activities include transcoding, content preparation and packaging for delivery. The current process also supports a variety of production services including audio layback and conform, aspect ratio and standards conversion, security features and archiving. Some of these processes are manual activities through approved workflows. DIAMONDS supports the following services:

• Ingestion • Encoding • Library Management • Order Management • Content Versioning • Transcoding • Standards Conversion • Foreign Language Audio Layback • Digital Rights Management (DRM) • Encryption & Watermarking • Metadata Management • Electronic Fulfillment • Performance Tracking • Global File Transport • MXF Wrapping/Unwrapping

At a high-level the DIAMONDS process begins with file ingest at an approved location. Files are archived into the DIAMONDS/VIIA system at Ascent and metadata records are validated with SPE’s GOLD (Xytech) inventory management system. Within SPE, users access DIAMONDS via a partition of GOLD to view inventory and create


10

purchase orders for processing. SPE purchase orders become Ascent work orders that start the content preparation and manufacturing process. All dependencies are flagged and managed by existing communication protocols. If additional non-DIAMONDS materials are required for packaging, existing processes facilitate the ability of Ascent to receive trailers, marketing materials, title metadata and images for inclusion in the package.

Rejection and redelivery investigations and client reconciliation are jointly managed between SPE and Ascent and various processes exist to ensure a timely turn-around.

The system has increased capacity from approximately 500 titles managed and ingested in April 2005 to over 15,000 titles represented by 250,000 files, utilizing more than 1.5 PB of storage today.

CINEAPPS and SERVICES

The “CineApps” are the digital media support systems managed by the Digital Media Group. They include 'cineSHARE', 'ACORN', and 'EAGL'. The systems provide enabling technologies surrounding digital asset management, digital media workflow, and digital media production. SPE’s core business lines – Theatrical, Home Entertainment and Television as well as WPF use one or more CineApps for managing and processing content from marketing materials such as promos, trailers and press kits to full length features and episodics for screeners and viewing pilots. CineApps are also utilized by suppliers to access and deliver content required for further processing.

CineApps are actively used by over 4000 users worldwide, transferring up to 400 TB per year of digital media, and managing several million assets.

In general, CineApps users upload required content into defined folders and utilize the processing services through specific interfaces called EAGL, Cineshare, CineStor and Acorn. Users also provide approval for suppliers or clients to access content and are able to transfer content as necessary for their defined workflows.

DMG systems enable the management and processing of most SPE digital media asset types, including photos, press kits, trailers, TV spots, one sheets, key art, logos, title treatments, promos, style guide comps, mobile ringtones, etc. Key digital media automated workflows enabled via CineApps include the management, processing in support of the following business processes and workflows: digital screeners distribution, review and approval of DVD packaging materials, ISO dailies transfers. DMG back-end systems manage and publish digital media assets to a variety of SPE marketing and web portals, including: SPT B2B, SP Inflight, GPMS, HEConnect.

DMG systems are architected following SOA constructs. The core architecture is composed of:

• Business services o DAM integrated services (search, ingest, export, metadata…)


11

o Digital media services (delivery [streaming / progressive download], large file transfer / Aspera, transcoding, watermarking…)

• Workflow orchestration

• Presentation layer applications and services

• Storage management

GPMS

GPMS, Global Product Master System, is SPE’s intellectual property master data system for information on titles, title-specific metadata, rights and usage. Over 1,000 users access GPMS to obtain required data and the system is interfaced to 20 systems including GOLD and CineApps. GPMS includes approximately 200,000 products (includes episode count)

GOLD

GOLD (the Global Order & Library Database), a SPE/WPF application, performs the following core functions for 260+ users worldwide:

Inventory – 3.6+ million elements tracked at internal & external facilities worldwide, including digital assets on DIAMONDS and views into inventory systems of 3 primary suppliers

Vault Management – FTO-Inwood, Film Services and Sony Sound

Purchase Ordering – Nearly 50k POs created annually

Invoice Processing – Over 59k invoices annually processed

SPIDR

SPIDR (Sony Pictures Internet Document Repository) is a web content management solution deployed throughout SPE. The various content tools includes: document management, web content management, collaboration, and WebScan. SPIDR is integrated with various key business applications, including GPMS, to provide centralized content management services. It allows employees, customers, partners and associates to collaborate, contribute and access business content securely anywhere worldwide. SPIDR has 3700 users world-wide with over 1 million documents securely stored. Key digital documents such as agreements, music cues, open and end credits, scripts, and subtitles are housed in SPIDR. Features include check-in, check-out, version and revision history, view, edit, print, distribution, watermarking, security at user and document level, 24/7 internet access

PROCESS AREAS

The To-Be process maps (Appendix B) identify six key operational areas for the Distribution Backbone. This section summarizes existing SPE processes in each of these areas, paralleling the structure found in those future state process maps.


12

1.0Create

Request

2.0PerformMaterialsAnalysis

3.0Define

ManufacturingPlan

4.0ExecuteProduct

Manufacturing

5.0Create

Package

6.0Fulfill

Request

1.0Create

Request


3.0Define

ManufacturingPlan

4.0ExecuteProduct

Manufacturing

5.0Create

Package

6.0Fulfill

Request

Requisition

- Requests are received in multiple formats and include, but are not limited to, fulfillment for current, pending or anticipated sales or licensing of content; business processes for internal production or viewing; or pro-active processes based on established business rules designed primarily to accelerate downstream processing times.

WPF Client Operations receives requests via Line of Business (LOB) sales systems, e-mail, phone calls or via meetings and discussions. These requests are primarily driven by sales.

WPF Tech Ops pro-actively and re-actively creates digital file masters based on sales-driven requests by Client Ops or established business rules.

WPF Asset Management proactively creates tape and digital file video masters of the original alpha, any specifically created alpha and newly restored catalog masters to satisfy expected downstream sales.

WPF Editorial Services re-actively creates edited video masters to fulfill sales requests that are received either via Client Ops or directly from Line of Business (LOB).

Material Analysis

- Currently, each distribution request requires a review of the source assets required to make, transform and process for delivery. The assets are made available through established processes, i.e. master tapes are stored at preferred suppliers, or they must be identified by research conducted by one of the mastering groups.

Asset Management, Tech Ops, Client Ops, Editorial Services and several business line marketing groups are involved in the creation of source masters. These source masters are created for several content categories including new release theatrical, new television broadcast, catalog theatrical, catalog television, client-driven edits, as well as trailers, promos and other related marketing content for use in post-theatrical market sales fulfillment. Sources masters, whether physical or digital, are generally stored at preferred suppliers and accessed through existing systems or established communication processes. GOLD is the primary inventory management system and the first search location for asset requests

Manufacturing Plan


13

- Currently, the services required to complete all process steps for creating the requested product deliverable

SPE has established numerous protocols with preferred suppliers to develop, implement and monitor the acceptable processes for manufacturing content for distribution to clients. These processes may be contained in technical specifications held at the supplier or be part of common practices. While physical media processes are well-established, digital media processes are subject to frequently change based on new technologies, tests or client preference. Manufacturing plans for digital media servicing are negotiated between SPE and suppliers and reflect the accepted technologies and industry standards.

In GOLD, users have visibility to the rate card for manufacturing services and are able to select services as required for the desired output.

Manufacturing execution

- Currently, the transformation process that creates the product deliverable necessary for distribution.

Similar to manufacturing plans, manufacturing execution is primarily an external supplier process based on previously agreed hardware and software as well as process steps.

SPE works with suppliers to ensure that the manufacturing execution steps meet client, corporate and industry standards.

External suppliers control the manufacturing execution tasks from Request to required delivery date including process steps for turnaround times and resource allocations.

Package

- Currently, “package” is the aggregation of all product deliverables and related materials that must be fulfilled as part of the request.

For digital clients, package refers to the combined delivery of the content essence file, with its matching title/alpha trailer, images and metadata.

SPE delivers all content required for the package or provides access to that content through SPIDR or Cineshare.

Fulfillment

- Currently, the types of services required to ensure that the package is delivered to the client by a specified due date. This process also reconciles rejections or redelivery requests.

External suppliers fulfill the majority of delivery requirements via FTP, file transfer service providers or physical media. The suppliers provide delivery details such as transmission date/time stamps or airway bill numbers as part of a reporting service to


14

SPE. WPF maintains one courier interface to its existing ordering systems for international television product delivered by a specific courier. All other delivery information metadata is updated manually.

Rejections are received via e-mail or phone calls to WPF or the supplier and are managed through a client reconciliation process that varies based on the details of the rejection.

Redelivery is executed in a timely manner following the resolution of the initial delivery issue. The instructions are generally maintained outside of existing systems.

1.06 Sony DADC Sony Corporation is the global leader in entertainment with core offerings in consumer electronics and entertainment media. We strive to deliver the most compelling entertainment experience in the market to our customers at home and on the move with innovative technologies and champion products. To deliver this mandate, Sony Corporation has created a strategy, Sony United, facilitating inter-division cooperation. By leveraging the collective strength of all Sony Corporation divisions, Sony Corporation can deliver an unparalleled consumer experience.

DADC is a $2 billion division of Sony Corporation which is a corporate center of excellence for entertainment supply chain services. DADC manufactures and distributes CD, DVD, UMD, and Blu-Ray discs as well as digital content distribution services for SPE, Sony PlayStation, Sony Music and multiple third-party clients. Digital content distribution services are a priority growth initiative for DADC as content companies and retailers transition from physical to digital entertainment products and consumers expect their physical media to contain digital service components (e.g. BD-Live).

DADC has defined 6 key priorities to deliver the most compelling consumer entertainment experience for their clients:

• Create compelling and seamless content experiences for consumers without boundaries.

• Develop and drive future formats and technologies that enhance entertainment. • Own the retail channel for entertainment products and services. • Develop individual consumer knowledge to drive the next transaction. • Market leading performance and quality. • Lead in sustainability

The Digital Backbone (“DBB”) project is the primary engine supporting DADC digital content services expansion. It is an example of a Sony United initiative that will combine the capabilities and expertise of SPE and DADC to create the new industry standard for digital filmed entertainment fulfillment. This platform will then be leveraged in the marketplace to non Sony companies to drive scale and operational performance. Additionally, DBB will act as a catalyst for change within Sony and the objective is to


15

integrate elements of the DBB offering to other Sony Corporation entities (e.g. Music, PlayStation, Electronics etc.) where relevant.

The competitive advantage the DBB provides resides in the ability for new processes and services – conceptualized and executed by SPE and DADC – to be integrated, packaged and resold to third parties. This will require the platform to be flexible for incorporating new features, services and technologies and be readily integrated with third-party systems – as well as other Sony companies. DBB will deliver value to SPE and partners via a combination of lowering asset preparation and fulfillment costs as well as providing new functionalities both upstream and downstream from existing product fulfillment functions.

DADC has deep experience managing inventories for clients and has determined that its most relevant key performance indicators include:

KPI Measurement

On-time & Complete Delivery End-to-end TAT (turn-around times) by Requisition Type (e.g. Proactive, Reactive, Rush)

On-time channel and format / CODEC set-up

TAT of new Client integration (e.g. Client Set-Up, Client Profile Set-Up, Client On-Boarding)

End-to-End cycle-times TAT for Requisition processing, Product & Package Assembly and Delivery

On-time workability TAT for Ingestion, Component Requirement, Manufacturing Plan, Fallout Ratio

End-to-End Quality System/Service Availability, Client Rejections, Redeliveries


16

2.0 Project-Specific Planning Guidance 2.01 Project Management and Governance Our proposed governance model may be adapted around recommendations from the selected supplier. This is a complex project on several facets and our organization is crafted to address these technical, organizational and operational complexities:

• Our Executive Steering Committee is charged with major policy guidance and resolution of material issues around budget, scope and resources.

• Operating Committees synthesize the interests of SPE as the initial client of the backbone with DADC’s interests in building a marketable service for other clientele. Lesser policy issues and matters of budget, schedule and resources that can be resolved internally would be addressed by Operating Committees. The Point Executives are primary liaisons to the Project.

• The Program Management layer handles the day-to-day issues of managing the resources and activities.

• The build or “release” teams, Release Execution, will be structured as appropriate to the final scope and resources provided by our supplier, but we expect teams to be grouped by primary focus among user representation or “process” (such as change management, organizational impact, etc.), technical teams, software integration and launch (in a traditional IT project, the “conversion”) and other matters associated with bringing clients into the DBB).

SOA Task ForceSOA Task Force

BusinessAdvisory Board

BusinessAdvisory Board

Client OperatingCommittee

Client OperatingCommittee

LaunchPlanning andCoordination

LaunchPlanning andCoordination

FunctionalArchitect

FunctionalArchitect

ExecutiveSteering

Committee(Cookson)

ExecutiveSteering

Committee(Cookson)

EXECU

TIVEEXEC

UTIVE

OVER

SIGH

TO

VERSIG

HT

PRO

GR

AMPR

OG

RAM

MAN

AG

EMEN

TM

AN

AG

EMEN

TR

ELEASE

RELEASE

EXECU

TION

EXECU

TION

SPE PointExecutive

SPE PointExecutive

OPER

ATING

OPER

ATING

OVER

SIGH

TO

VERSIG

HT

DADC PointExecutive

DADC PointExecutive Market Operating

Committee

Market OperatingCommittee

ProcessProcess

ExecutiveSteering

Committee

ExecutiveSteering

Committee

Tech Labs –Backbone

Functionality

Tech Labs –Backbone

Functionality

Content Processing

Content ProcessingCapabilitiesCapabilities

Technical PMTechnical PM

ProgramManager

ProgramManagerMetadata

Advisory Board

MetadataAdvisory Board Technical Arch

Advisory Board

Technical Arch Advisory Board


17

2.02 Responsibilities Sony Parties Plans to Retain As seen in the governance structure described in 2.01, Sony Parties mean to play a substantive role in the development, creation and deployment of the DBB. In addition, Sony Parties plan to have leadership roles in certain areas. We do not anticipate our suppliers having substantial roles in these areas:

Organizational design addressing any changes in personnel needs or assignments Content ingestion Content quality testing and verification Master Format definition Any interaction with customers to prepare them for the transition to the DBB or to

introduce them to the DBB, unless agreed otherwise Diamonds content and metadata migration

Additionally, there are specific areas where the supplier should expect considerable peering and input from Sony Parties, but not necessarily to formally contribute to work effort against a workplan. These areas are:

Process design and requirements gathering Technical Architecture approach and design Application Architecture approach and design Change Management and training

Sony Parties plan to make team members available to the extent possible using a combination of full- and part-time staff depending on your projected resource plans. Some staff in key positions have been assigned full-time to the DBB initiative and others will be added as the project team is coordinated with your proposal.

Your resource plans should specifically call out roles you expect Sony to fill and the level of responsibility assigned to them. All lead positions identified in the chart under 2.01 are expected to be filled by Sony Parties, including PMO leadership.

3.0 Scope Summary The Scope of Release 1 will be to design, build and make operational functionality to enable the transition of Electronic Sell-Thru (EST), Digital Distribution Internet (DDI) and Broadcast clients currently serviced by Ascent through the DIAMONDS platform. As mentioned previously, we want to ensure that later releases are not adversely hampered by decisions made for this release or, worse, that the grander vision cannot be economically realized.

More specific scope guidance will be derived through Appendices, primarily in the Process Flows, White Papers and Additional Functional Requirements. Supporting


18

documentation regarding file specifications and other critical and technical details will be found in the other appendices.

Use Appendix A as a glossary for standard definitions and clarification of key terms and phrases.

Use Appendix B to gain an understanding of the breadth of the overall processes in play. Note that we’ve provided a comprehensive perspective for context. Generally, GREEN steps are those to be in scope for Release 1 and RED boxes are those to be addressed in later releases. We recognize that suppliers may offer up solutions that go beyond the current requests, please clearly indicating these as Amendments to your proposal. We will entertain alternatives to almost any facet of this request, though we suggest you may wish to gauge our interest in those during your conferences.

Use Appendix C White Papers to gain insight into key facets and critical elements we view as central to our strategy or which we believe require additional clarification.

Use Appendix D for additional itemized requirements; though these are not meant to be comprehensive or all-inclusive, they include key note-worthy items.

Use Appendix E for current technical Product Specifications that are the baseline for output requirements.

Use Appendix F for the specific content processing functions for automation desired.

Use Appendix G for technical specifications for master file (eMaster).

Use Appendix H to appreciate how all the various system components, layers and key integration points relate to one another.

Use Appendix I for guidance on configuring and sizing the physical plant for the DBB. We included a mix of statistics that can be used to estimate capacities, throughput and certain service levels.

3.01 Guiding Principles We believe these Guiding Principles to solution design should help you frame the context of our RFP and of your responses as considerations:

• Design the solution around commercial, business requirements • Focus on creating the best possible service • Remove non-value added process steps • Automate wherever feasible and appropriate • Make it simple, fast, reliable, repeatable, scalable and efficient


19

• Use best-of-breed thinking from SPE, SME, DADC and other DADC customers • Design in flexibility – we don’t know what new requirements will arrive

4.0 RFP Process

• Your company’s proposal to all the information requested under 5.0 RFP Deliverables is required by Friday, July 17, 2009, at 5:00p PDT. Please submit such proposal via email to Dennis Bond ([email protected]) and Trey Bradley ([email protected]).

• If your Company does not intend to submit a proposal we require that you indicate such intent via email to Dennis Bond and Trey Bradley by Friday, June 19, 2009, at 5:00p PDT.

• If your company intends to submit a proposal we require that you indicate such intent via email to Dennis Bond and Trey Bradley by Friday, June 19, 2009, at 5:00p PDT.

• Any questions you may have pertaining to this RFP package may be discussed at either of the two optional RFP individual supplier Q&A sessions we intend to hold (as described below). Questions may also be submitted via email to Dennis Bond and Trey Bradley through Monday, July 13, 2009 at 5:00p PDT. We will make every effort to respond to questions submitted via email in a timely manner. It is inappropriate, and will be viewed negatively, for suppliers to reach out directly to SPE team members other than Dennis Bond and Trey Bradley.

• All pertinent information is contained within this RFP package. Failure to examine all materials fully and carefully will not protect a supplier submitting a proposal from full responsibility for the goods and services to be provided. All responses to the RFP package should be included in the proposal.

• All costs associated with the preparation and submission of a proposal response to this RFP package shall be borne solely and exclusively by the supplier preparing and submitting the proposal response.

• Each response shall: (a) show the full legal name and business address of the supplier submitting the response, including its street address if it differs from its mailing address, (b) be signed with the usual signature of the person, or persons, authorized to bind the supplier submitting the response, (c) show the RFP number assigned by SPE, and (d) be dated. A response 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. When requested by SPE the satisfactory evidence of the authority of any signatory to act on behalf of the supplier submitting the response shall be promptly furnished.


20

• Your response must be valid for a period of one hundred-twenty (120) days from the submittal due date to SPE of July 17, 2009. No corrections or modifications to your response will be accepted after this submittal due date without prior written consent via email from Dennis Bond or Trey Bradley.

• We reserve the right to award one or more contracts on the basis of proposals received. We also reserve 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. We reserve the right to make a contract award without written or oral discussion with any supplier submitting a proposal. We reserve the right to decide not to make a contract award to any supplier submitting a proposal. This RFP package does not commit SPE and/or DADC to any particular course of action.

4.01 Time Line For the purposes of this RFP, the following key dates have been established for the completion of the RFP process:

• Monday, June 15, 2009: RFP package is released to potential suppliers for bid.

• Week of Monday, June 22, 2009: First round of optional individual supplier Q&A sessions.

• Week of July 6, 2009: Second round of optional individual supplier Q&A sessions.

• Friday, July 17, 2009 at 5:00p PDT: Final date and time for receipt of proposals from suppliers to SPE.

Late responses may not be accepted.

For your response SPE requires the following:

• Electronic copies of your proposal via email to Dennis Bond and Trey Bradley. • Complete responses to all information requested within the RFP following the

same order and format as they appear in the RFP. • Any additional relevant information specific to your proposal which you deem

necessary and which was not initially requested within the RFP package.

4.02 Individual Supplier Q&A Sessions - Week of June 22, 2009 As indicated under Section 4.02, we plan to make an individual supplier Q&A session available to you to use at your discretion for the week of June 22, 2009. We anticipate allowing two hours for this session. The intent for this session is to give you the opportunity to seek clarification on the contents of the RFP package and the RFP process in general. We suggest that, should you elect to participate in this session, you provide areas of interest or specific questions you may have by Friday, June 19, 2009 at Noon PDT via email to Dennis Bond and Trey Bradley. This will allow us to better


21

prepare for this session along with making best efforts to have the appropriate individuals in attendance from our end. We have identified the following dates and times (PDT) for these sessions:

• Tuesday, June 23, 10:00a to Noon • Tuesday, June 23, 2:00p to 4:00p • Wednesday, June 24, 10:00a to Noon • Wednesday, June 24, 2:00p to 4:00p • Thursday, June 25, 10:00a to Noon • Thursday, June 25, 2:00p to 4:00p

Please submit your preference for these dates, ranked from #1 to #3 (1=most desirable), via email to Dennis Bond and Trey Bradley by Thursday, June 18, 2009, at Noon PDT. We expect to confirm your session date and time by Friday, June 19, 2009, at Noon PDT. 4.03 Individual Supplier Q&A Sessions - Week of July 6, 2009 As indicated under Section 4.02, we plan to make an individual supplier Q&A session available to you to use at your discretion for the week of July 6, 2009. We anticipate allowing two hours for this session. The intent for this session is to give you the opportunity to seek further clarification on the contents of the RFP package. In addition, this session will also give you the opportunity to seek guidance on the direction you are taking in your proposal in areas such as your proposed tools, approaches, etc. If you choose to schedule this session, we would encourage you to bring the key members of the project team to be included in your proposal to this session. In addition, should you elect to participate in this session, we suggest that you provide areas for discussion or specific questions you may have by Wednesday, July 1, 2009 at Noon PDT via email to Dennis Bond and Trey Bradley. This will allow us to better prepare for this session along with making best efforts to have the appropriate individuals in attendance from our end. We have identified the following dates and times (PDT) for these sessions:

• Tuesday, July 7, 10:00a to Noon • Tuesday, July 7, 2:00p to 4:00p • Wednesday, July 8, 10:00a to Noon • Wednesday, July 8, 2:00p to 4:00p

Please submit your preference for these dates, ranked from #1 (most) to #4 (least), via email to Dennis Bond and Trey Bradley by Tuesday, June 30, 2009, at Noon PDT. We expect to confirm your session date and time by Wednesday, July 1, 2009, at Noon PDT.


22

4.04 Future Participant Contact Please identify within your response one individual to be the central point of contact for your firm during the RFP process who is empowered to field any questions or further requests from SPE as they may arise. In so doing, please provide this individual’s title, mailing address, telephone number (mobile preferred), fax number and email address. 5.0 RFP Deliverables 5.01 Response Deliverable Format The following outline provides guidance on structuring your RFP response. These deliverables should be based upon the scope provided throughout and should not be samples of prior client work you have performed.

1. An executive overview of your proposal in terms of addressing the major initiative objectives of: automation; commercialization; flexibility, supporting diverse content and supporting progressive supply-chain optimization and including or referencing these areas:

• Background information leading toward the need for the project

• Project objectives

• Project scope of work o Approach/Methodology o Staffing o Tasks (project workplan/timeline) o Supplier roles/responsibilities o SPE roles/responsibilities o Assumptions o Change Management o Training o Functional considerations/references/documents (as applicable) o Technical considerations/references/documents (as applicable) o Test/Acceptance/Performance criteria (as applicable) o SLA’s (as applicable) o Other (as applicable to specific project requirements)

• Project deliverables o Products/Services o Reviews o Data o Other: may include your approach and rationale for implementing

functionality ahead of our business case deadline • Project change order process

• Project fee estimate (fixed fee) as well as a fee schedule (including T&E) and rate card for estimating change orders


23

The remainder of your response may contain detailed sections that address the following areas:

2. Provide a description of your system design that meets the requirements described above and the following design criteria:

a. Centralize storage of content and works in progress – storage must be scalable, flexible, and low life cycle cost

b. Centralize inventory management for SPE and future partners c. Accommodate current workflows and future process improvements d. Facilitate automated digital workflows e. Support a multi-tenant model allowing the system to be leveraged for

other entertainment partners of varying scale f. Facilitate extensions to support additional supply chains in the

entertainment industry (e.g. music labels, game publishers, etc…) g. Facilitate integration with SPE’s other systems h. The mix, as applicable, of open versus proprietary architecture including

hardware, software, or system solutions i. Maintain security of content including assuring data integrity and

prevention of theft while guaranteeing the compartmentalization of sensitive information and content between multiple tenants and partners

j. Ensure sustainability through the use of technologies and processes that are energy efficient, minimize waste, and optimize reuse of materials

k. Facilitate disaster recovery and business continuity in the face of significant events that may impact operations in the local area

l. Facilitate DADC’s use of the system as the operator (including training on operational functions and processes)

m. Facilitate training of SPE and DADC staff on partner centric functions n. Facilitate training of DADC’s staff for future integrations and

customizations required for other partners o. Facilitate DADC’s maintenance of the system (including any initial training

required for maintenance such as preventive maintenance, bug fixes, performance tuning)

p. Facilitate SPE and DADC’s upgrade of the system including enhancement and major additions

Your description should include design characteristics and should include but not be limited to the answers for the following questions:

Describe your MAM/DAM solution. How your solution supports being media format independent?


24

What are the capabilities of your application layer for manipulation of audio and video assets?

Describe your storage approach. What are the file size limitations or thresholds (at what point is a

threshold met that requires an incremental upgrade)? What makes your systems advantageous or unique for supporting

multiple partners and a global, multi-site service? Approach on software development and engineering, including

methodologies, certifications and compliance (e.g. CMMI) Identify components of the architecture as open or proprietary.

3. Provide any assumptions that you have made in your design. 4. Provide a high-level risk assessment of your design with mitigation strategies. 5. Provide any detail on single points of failure in your solution as well as any

specific points of inflection when scaling the solution (i.e. at # managed assets within the storage system an expensive upgrade is required). Provide a top level project plan including a schedule for the implementation of this system and its ability to support targeted clients, in whole or in phases, during SPE’s fourth quarter, January through March, 2010.

6. Describe the expertise and capabilities resident in your company that suit the role of a systems integrator for this type of an implementation.

7. Provide an overview of your company’s personnel qualifications and skill sets that you would apply to this implementation. “Representative” resumes are much less desirable than the resumes of staff who are being actually proposed.

8. Identify subcontractors and / or partners that you will use for any portions of this implementation. Describe the relationship between your companies.

9. Describe any unique qualifications or capabilities that make your company a good fit for the systems integrator role.

10. Describe any technologies and/or processes that you feel will contribute significantly to this implementation.

11. Provide a description of any encumbrances on intellectual property which need to be resolved before the Sony Parties can readily market the resulting services.

12. Propose a comprehensive set of hardware, software and equipment comprising the physical plant that would support the DBB. Some estimating guidance is found in Appendices I Non-Functional Estimating Guidance and the Reference Architecture. Additional statistics are found elsewhere. Specifically, be apprised:

a. The proposed footprint hardware, software and associated services must be tiered at least into groupings for SOA/applications/database, storage and content processing layers with the ability to have each layer be acquired in a shared or dedicated model between SPE and DADC;


25

b. The proposed footprint must have associated list prices for purchase and lease options where applicable (optional discounts available by procuring through the supplier may be optionally included);

c. The Non-Functional Estimating Guidance includes DADC’s near-term projections for additional partners;

d. Any constraints or restrictions on components that cannot be used for DADC’s offering to additional partners must be avoided and if unavoidable, require explicit notation, itemization of associated license fees and clarifications on possible methods of resolution ;

13. Provide the total effort in the form of a resource loading schedule – including one specifically noting what is expected from Sony Parties and fees as well as an estimation of expenses to implement your proposed solution. In addition, breakout effort and fees for the following areas:

a. Project Management and Organization b. Process Design and Detailed Requirements Gathering c. Application Functional and Detailed Design d. Application Build and Test (all phases of test proposed should be outlined

in the implementation approach) e. Enterprise Integration Design, Build, and Test f. Infrastructure Design, Build, Test g. Disaster Planning/Strategy for Proposed Solution h. Change Management and Training i. Operations Runbooks related to the Proposed Solution (Application and

Infrastructure including listing of errors/error codes) j. Operations Design (i.e. ITIL/ITSM given the Proposed Solution) and

Service Introduction DADC may entertain options for data center co-location and managed services as an amendment to this proposal. Finally, regarding the elements requested in this section you should be prepared to summarize how each element is addressed in your response. You may use this section as a checklist if helpful.


26

Appendix A – Glossary

The DBB Glossary of Terms is a supplemental document to the process flows, white papers and requirements. The document is intended to provide a definition for words or phrases that may be DBB specific terminology or industry terms as they are utilized within the Sony environment.

ACP See Automated Content Processing.

Alpha • Alpha is a unique picture/audio cut of a Title (See 'Title') created for business, territory, S&P, etc. Can loosely be thought of as a "version".

• The secondary level of organizational data used with a Title (See 'Title') in order to drive what end Product (See 'Product') needs to be manufactured within the DBB (See 'DBB'). (Title > Alpha > Component)

• In context of the DBB (See 'DBB'), Alpha will be used, in conjunction with Title (See 'Title'), to drive what Components (See 'Component'), Products ('Product'), and/or Packages (See 'Package') will be manufactured to fulfill a Request (See 'Request'). Upon entering a Request (See 'Request') into the DBB (See 'DBB'), an Alpha will need to be chosen.

Approve (Manufacturing) Plan

'Approve Plan' represents the key financial, operational, and scheduling approval processes that act as the trigger to start manufacturing work within the 'Define Manufacturing Plan' process (See 'Define Manufacturing Plan'). 'Approve Plan' includes processes to estimate and approve internal and external costs and timelines associated to the Manufacturing Plan (See 'Manufacturing Plan').

Assembly Configuration

Assembly Configuration defines the placement and selection of bumpers, cards, watermarks, logos, etc.

Asset Asset is meant to convey the broad scope of physical or digital elements maintained and tracked as a unit within any asset management system. Asset metadata uniquely describes the characteristics of the asset and must be permanently connected to the essence whether in a physical or digital asset management system. Whether an asset contains multiple parts, e.g. 5.1 Audio, or whether each part is maintained as an asset is subject to the specific protocol of the managing system. With regard to the more formal term, Component (See Components); an asset, once verified and matched to Component Type specification, becomes a component. All Components are assets, not all assets are components.

Audio Layback Audio Layback, in the context of the DBB (See 'DBB'), is an Automated Content Processing service (See 'Automated Content Processing') to assemble pre-conformed audio Components (See 'Component') to its intended video Components (See 'Component').


27

Automated Content Processing, or ACP

• Automated Content Processing in the DBB (See 'DBB') is the various services that are performed by the system in order to transform inputs into a finished Product (See 'Product') during the 'Product Assembly' process (See 'Product Assembly').

• Automated Content Processing services in the DBB (See 'DBB') include but are not limited to: 1. Transcode (See 'Transcode') 2. Logo Card Addition/Removal (See 'Logo Card Addition/Removal') 3. Audio Layback (See 'Audio Layback') 4. Security Features (See "Security Features') (e.g. Visible Watermarking (See 'Visible Watermarking', 'Watermarking'), Forensic Watermarking (See 'Forensic Watermarking', 'Watermarking'), Fingerprinting ('Fingerprinting'), Encryption (See 'Encryption')

• Refer to 'Content Processing Functions' documentation to see all potential ACP services.

Automated QC Automated QC , in context of the DBB (See 'DBB'), represents system-driven validations that may be based off of business rules, e.g., checksum, etc.

Billing Transaction Billing Transactions are the financial line items that result from manufacturing tasks and their associated costs that will be used to support Invoicing (See 'Invoice').

Charter of Financial Authority, aka COFA

COFA is a financial approval based on resource title; the dollar amount to be approved has a positive correlation with the level of the resource who needs to approve the Request (See 'Request'). COFA represents one of the approvals that may be needed in order for a request to proceed to manufacturing in the DBB (See 'DBB').

CineApps • CineApps includes cineSHARE+, EAGL, ACORN and cineSTOR which provide different UIs and workflows based on a common back-end infrastructure.

• Asset repositories for creative, marketing, ad-pub, sales and WIP distribution purposes. The systems also support Post Theatrical Dubbing, Conform, Authoring, Asset Restoration as well as short-form content.

• Developed and managed by DMG (See 'DMG'). • In context of the DBB (See 'DBB'), CineSHARE will be the system from

which images, added value materials, clips, chapters, and possibly trailers, will be retrieved.

Client • Clients, as they relate to the DBB (See 'DBB'), are consumers of distributed content that is owned by Partners (See 'Partner').

• Clients will be added to the DBB (See 'DBB') on an as needed basis in order to fulfill Partner (See 'Partner') requests for content distribution.

• Sample Clients include Apple, Amazon, and the SPE Mastering Group. • Client Master Data (See 'Client Master Data') contains Client contact

information.

Client Master Data Client Master Data represents the default client Metadata (See 'Metadata') that is maintained at the highest level, e.g. contact name, contact number, etc.

Client Mitigation Process

The Client Mitigation Process is a pre-existing process that is used to manage any situations whereby a request cannot be met exactly as per Specifications (See 'Specification').


28

Client On-Boarding • The 'Client On-Boarding' process is the overall process to test a Client Profile (See 'Client Profile') through the DBB (See 'DBB') manufacturing process.

• The 'Client On-Boarding' process can occur at any time so long as Client Profiles (See 'Client Profile') and their associated Specifications (See 'Specification') and Configurations (See 'Configuration') that need to be tested are ready for testing.

• Client On-Boarding can occur in advance of any requests made against that Client Profile (See 'Client Profile').

Client Profile • One or many Client Profiles will be created for each Client (See 'Client') in order to capture client requirements, e.g. Specifications (See 'Specification') and their associated Variables (See 'Variables'), that will provide manufacturing instructions to the DBB (See 'DBB').

• A Client Profile is comprised of: 1. Client Profile Data (See 'Client Profile Data') 2. Assembly Configuration (See 'Assembly Configuration') 3. Product Specification (See 'Product Specification') 4. Package Configuration (See 'Package Configuration') 5. Metadata Specification (See 'Metadata Specification') 6. Delivery Configuration (See 'Delivery Configuration') 7. Other Specification (See 'Other Specification')

• The Client Profile (See 'Client Profile') acts as the source of reconciliation throughout the entire DBB (See 'DBB') manufacturing process to ensure what is being created matches client requirements.

Client Profile Data Client Profile Data represents the profile specific client metadata, e.g. client profile contact name, client profile contact number, etc.

Client Profile Set-Up and Maintenance

• The 'Client Profile Set-Up and Maintenance' process will manage the following scenarios: 1. Set-Up a new Client Profile (See 'Client Profile') for a new Client (See 'Client'). 2. Set-Up a new Client Profile (See 'Client Profile') for an existing Client (See 'Client'). 3. Update a Client Profile (See 'Client Profile') for an existing Client (See 'Client').

• The 'Client Profile Set-Up and Maintenance' process associates all necessary Specifications (See 'Specification'), Configurations (See 'Configuration') and fills in client Variables (See 'Variable') to the Client Profile (See 'Client Profile') so that it can be used for manufacturing to fulfill a Request (See 'Request').

Client Set-Up The 'Client Set-Up' process establishes new Clients (See 'Client') with their Client Master Data (See 'Client Master Data) in the DBB (See 'DBB') so that Partners (See 'Partner') can deliver content to them.

COFA See Charter of Financial Authority. This term is commonly used in reference to approval required to commit to the expenditure of funds.

COM An Oracle based financial system which will be used to post DBB billing events for DADC North America.


29

Component • A Component is the building block for the creation of a 'Product', e.g. video, audio, subtitle, chapters, etc. A Component, therefore, will not exist for images and metadata.

• A Component is the discrete audio, video, text and/or combined Assets (See 'Asset') that are associated with a Component Type (See 'Component Type') stored as raw materials for Automated Content Processing (See 'Automated Content Processing'); Components are Title (See 'Title') and Alpha (See 'Alpha') specific.

• A Component can be used in one or more Kits (See 'Kit'), which can be used in one or more Manufacturing Plans (See 'Manufacturing Plan') (applies to both digital and physical media).

Component Repository

See MMSE

Component Requirement

• A Component Requirement is the placeholder for associating a specific Component Type (See 'Component Type') with a specific Title (See 'Title') and Alpha (See 'Alpha') combination.

• A Component Requirement may be created as a result of a Request (See 'Request') or proactive demand planning.

• Typically, any Component (See 'Component') that is either ingested into or already exists within the DBB (See 'DBB') needs to be associated to a corresponding Component Requirement in order to manage inventory.

Component Type • Component Type represents the Technical Specifications (See 'Technical Specifications') used to define the qualitative and quantitative properties of the Component (See 'Component') that is being manufactured (e.g., standard, aspect ratio, format, audio channels, codec).

• A Component Type is created in order to define the requirements of a manufacturing workflow as it relates to inventory. In addition to the specification requirements of an asset, the Component Type describes the role of the asset in all manufacturing processes. In supply chain terminology, the Component Type is a part number with implied specification detail, that is then associated to a bill of materials for purposes of manufacturing support.

Config See Configuration.

Configuration, aka Config

Configurations are the set of info that are created individually for each Client Profile (See 'Client Profile'). While Specifications (See 'Specification') represent reusable info sets that may be associated to Client Profiles (See 'Client Profile'), Configurations can be specific and unique to a Client Profile (See 'Client Profile'). In some cases, 'standard configurations' may be reused across multiple Client Profiles (See 'Client Profile').

Configuration: Assembly

See Assembly Configuration.

Configuration: Delivery

See Delivery Configuration.

Configuration: Package

See Package Configuration.

Conformed Audio Conformed Audio represents audio Components (See 'Components') that have been processed for the video Component (See 'Components') for which it is intended so that it matches the video bit rate and sequence sample rates.

Content Gathering See Retrieval.


30

Create Package 'Create Package' is the process that compiles and sequences all of the Element Types (See 'Element Type') into a Package (See 'Package') format for Delivery (See 'Delivery') to the Client (See 'Client') to fulfill a Request (See 'Request').

Create Request • 'Create Request' includes the processes to: 1. Enter a Request (See 'Request') into the DBB (See 'DBB'). 2. Associate qualitative and quantitative data to a Request (See 'Request') in order to qualify it for a Manufacturing Plan (See 'Manufacturing Plan') within the DBB (See 'DBB').

• Partners (See 'Partner') will make a Request (See 'Request') for their content to be manufactured in order to be distributed to their Clients (See 'Client') via the DBB (See 'DBB').

DADC Digital Audio Disk Corporation, aka DADC, represents the Sony division that will operate the DBB (See 'DBB') as a content manufacturing capability. The DADC will work with Partners (See 'Partner') to manufacture and distribute content to their Clients (See 'Client').

DBB See Distribution Backbone.

DDI Digital Distribution Internet.

Deal Metadata Deal Metadata contains the deal term information, such as street start date, due date, etc.

Define Manufacturing Plan

The 'Define Manufacturing Plan' is the overall process to: 1. Define the raw material(s) (Components) and the manufacturing service(s) that need to be performed to transform the raw materials into a final Product (See 'Product') 2. Associate costs and durations to those raw materials and services to create a Quote (See 'Quote') that needs to be approved prior to the start of any manufacturing work.

Delivery The 'Delivery' process falls within the 'Fulfill Request' Workflow (See 'Fulfill Request', 'Workflow') that transports the Package (See 'Package') from the DBB (See 'DBB') to a Partner (See 'Partner') specified location using various delivery methods, as per the Client Profile (See 'Client Profile').

Delivery Configuration

Delivery Configuration defines the delivery dimensions for both digital and physical packages, e.g., delivery method, whether client accepts early delivery, split package by deliverable type, etc.

Delivery Manifest Delivery Manifest identifies the individual Packages (See 'Package') that are a part of the same Request (See 'Request').

Demux Demux is the act of separating video and audio Components (See 'Component') upon Encode (See 'Encode').

DIAMONDS DIAMONDS is the current archival repository for all SPE rich media digital content. Within GOLD, a DIAMONDS partition is the application that provides a view of all digital assets contained in the DIAMONDS system.

DigiDelivery DigiDelivery is commercial software used for accelerated file transfers (http://www.digidesign.com/index.cfm?navid=38). Primarily used for distribution of files in Asia.

Distribution Backbone (DBB)

The Distribution Backbone, or DBB (See 'DBB'), represents the automated end to end digital fulfillment solution that will serve to fulfill digital manufacturing requests.


31

DMG Digital Media Group. DMG's mission is to research, develop and maintain digital media services that enable SPE businesses to more effectively and securely create, manage, distribute and monetize our assets

DST See DDI.

Element Type Element Type is a secondary categorization that defines the kind of Package Element (See 'Package Element') within a Package (See 'Package'), e.g. Trailer, Chapter Still, Packshot, Metadata, Music Video, etc.

Encode Encode represents the process used to transform physical materials into a digital format.

Encryption Encryption is a type of Security Feature (See 'Security Feature') used as an Automated Content Processing (See 'Automated Content Processing') service that involves making files unreadable to anyone who doesn’t hold the key that will decrypt the information.

Estimate The Estimate provides the estimated costs and time to fulfill the Request (See 'Request') based off of details provided by the Manufacturing Plan (See 'Manufacturing Plan'). Approval of the Estimate is required in order to execute the Manufacturing Plan (See 'Manufacturing Plan') by the DBB (See 'DBB').

Execute Product Manufacturing

'Execute Product Manufacturing' is the overall process to transform Raw Materials (See 'Raw Material') into a finished Product(s) (See 'Product') that has been created to fulfill a Request (See 'Request').

External External refers to any touch point that is required to interact with the DBB (See 'DBB'). External can refer to systems, e.g. GPMS (See 'GPMS'), or processes, e.g. Supplier encode, that reside outside of the DBB (See 'DBB').

Fingerprinting Fingerprinting is a content security technique provided as an Automated Content Processing (See 'Automated Content Processing') service that is focused on content identification. It enables content owners to accurately identify their content in the marketplace. A unique digital fingerprint is extracted from the source media and stored in a database so that it can be compared to suspected derivations.

Forensic Watermarking

Forensic watermarking is a technique provided as an Automated Content Processing (See 'Automated Content Processing') service which embeds a unique identifier in a file so that it can be accurately identified. This is commonly used to enable traceability in the event that a piece of content ever goes somewhere it wasn't supposed to go.

Fulfill Request 'Fulfill Request' is the process to manage the Delivery (See 'Delivery') and acceptance of a Package (See 'Package').

GOLD The GOLD application manages content and location information for all SPE physical assets, provides visibility into key Supplier Inventories including DIAMONDS and provides ordering and financial interfacing capabilities for mastering and fulfillment activities.


32

GPMS Global Product Management System, or GPMS, is SPE's product and rights master and is at the core of our intellectual property management systems. It contains title, product information and distribution rights for all SPE products and is fully integrated with the major corporate and distribution systems. GPMS provides the necessary product/rights information for SPE to successfully exploit our products. In context of the DBB (See 'DBB'), GPMS will provide Title (See 'Title') and Alpha (See 'Alpha') data for ingested components.

GPMS Metadata Manufacturing/XML Creation

'GPMS Metadata/XML Generation' includes retrieving and aggregating Metadata (See 'Metadata') as per a metadata schema driven by a Metadata Specification (See 'Metadata Specification') in the Client Profile (See 'Client Profile'). XML has been used to represent any type of metadata file. Metadata (See 'Metadata') may exist both inside and outside of the DBB (See 'DBB'), and therefore, may require some sort of data mapping in order for external data to meet standard naming conventions within the DBB (See 'DBB').

Supporting Media Manufacturing/Retrieval

'Supporting Media Manufacturing/Retrieval' is the process to obtain all other Package Elements (See 'Package Element') outside of Products (See 'Product') and Technical Metadata (See 'Technical Metadata') (e.g. trailers, images, marketing materials) either existing or manufactured so that they can be aggregated with the Package ('See Package').

Image Metadata Image Metadata is the descriptive information that accompanies an image.

Ingest 'Ingest' is a process within the 'Execute Product Manufacturing' Workflow (See 'Workflow') to bring Components (See 'Components') inside of the DBB (See 'DBB') to complete the manufacturing of a Product (See 'Product') to meet demand that is either current, i.e. the result of a Request (See 'Request'), or in the future, i.e. Mastering New Release titles. Typically, any file being ingested should have a Component Requirement (See 'Component Requirement') and a Request (See 'Request') tied to it.

Invoice An Invoice will be created by the DBB as a mechanism to track Billing Transactions (See 'Billing Transaction') for purposes of charging the Partner (See 'Partner') with the appropriate service costs.

ITSM ITSM is an application that is used to support the business activity of selling and distributing SPE's titles in the international markets of SPT distribution. The application provides sales availability information of our titles to SPT's international sales and distribution organization. The system also captures the deal (sales orders and sales related information). Primary users are the international territories of SPT. The saleforce uses the ITSMS module of ITSM to communicate fulfillment requests to WPF. This module also supports WPF Reverse Distribution processes.

ITSMS ITSMS is a WPF module of ITSM used to further describe fulfillment requests related to international TV sales orders.

Kit Kit is a grouping of Components (See 'Components'), e.g. audio and video, that can work together (conformed and synched).

Line of Business, aka LOB

A line of business is a divisional unit from which a Request (See 'Request') can originate (See 'Originator').

Line Order Management

'Line Order Management' is the process used to manage any changes to a Request (See 'Request') and/or Manufacturing Plan (See 'Manufacturing Plan') at the line item or overall Request (See 'Request') and/or Manufacturing Plan (See 'Manufacturing Plan') level.


33

LOB See Line of Business.

Logo Card Addition Logo Card Addition is one of the Automated Content Processing services (See 'Automated Content Processing') whereby logos are added to the video Component (See 'Component').

Managed Multi-Tiered Storage Environment, aka MMSE

The Managed Multi-Tiered Storage Environment, or MMSE, represents the overarching file management structure that will be used by the DBB (See 'DBB') to store files across online, nearline, and offline storage. Purge/Retention policies will be applied to all storage tiers to manage inventory. This will serve as the file equivalent of a vault.

Manual QC Manual QC represents checks performed by humans.

Manufacturing Plan (includes Materials Analysis)

• The Manufacturing Plan represents: 1. The list of raw materials needed and their associated costs 2. The breakdown and sequencing of services to transform raw materials to final Products (See 'Product') and their associated costs and durations

• The Manufacturing Plan is used as an input to the Quote (See 'Quote') that will be used to approve/reject the Request (See 'Request').

Master A Master represents the original source of a Title (See 'Title') and Alpha (See 'Alpha') from which derivatives can be created. Masters are typically created by the Mastering group.

Materials Analysis For R1, ‘Materials Analysis (Product(s) Only)’ represents automated or manual searches conducted within or outside of the DBB (See 'DBB') for Components (See 'Component').

Metadata Metadata is the information that describes other data.

Metadata File Metadata File is the overall term for the XML file that gets generated with all of the metadata information. Being used interchangeably with XML.

Metadata Specification

The Metadata Specification defines the information required to generate a Metadata File (See 'Metadata File'), e.g. metadata file format (e.g. XML, Excel, CSV…).

Mezzanine files Mezzanine files refer to the master video and audio files that can be used to create derivative products.

MMSE See Managed Multi-Tiered Storage Environment.

Mobixell Mobixell is a third party software package used to transcode into mobile device specific formats (http://www.mobixell.com/).

Negative Component A Negative Component is a Component (See 'Component') that SPE either cannot or will not create, potentially due to cost prohibitive reasons.

Originator Originator represents the group, e.g. Line of Business (see 'Line of Business'), that provides client information to the Requestor (see 'Requestor'). The information sent will serve as an input for the Requestor to submit the Request (See 'Request').

Other Metadata Other Metadata refers to descriptive information that accompanies any other Materials (See 'Material') or Components (See 'Component'), e.g. chapter metadata, sub title metadata, etc.


34

Other Specification Other Specifications represent additional required Specifications (See 'Specifications') that may be identified during design/implementation.

Package A Package is the compilation of one or more Products (See 'Product') and any associated ancillary Materials (See 'Material'), e.g. Images, Trailers, etc., that results in the fulfillment of a Request (See 'Request').

Package Assembly Package Assembly ensures that all required Package Elements (See 'Package Elements') have been gathered, performs any processing required to conform the Package Elements (See 'Package Elements') to their respective Specifications (See 'Specification') (i.e. watermarking, DRM, etc.) and organizes the Package Elements (See 'Package Elements') according to the Package Configurations (See 'Package Configuration').

Package Configuration

A Package Configuration defines what is required to generate a Package (See 'Package'), e.g. packaging contents directory path, output package directory path and package type definition (e.g. MXF, ZIP ), and how it will be ordered within the Package (See 'Package') .

Package Element The Package Element defines a discrete piece of content required to be part of a Package (See 'Package'). Each Package Element will have its own Specification (See 'Specification') based on its type of content or Element Type (See 'Element Type'), i.e. a Metadata Package Element would have a Metadata Specification, a Packshot would have an Image Specification.

Package Maintenance

Package Maintenance represents the processes that control the Package (See 'Package') after it is created.

Partner • Partner refers to a Sony DADC customer and a content owner who distributes content via the DBB (See 'DBB').

• Partners rely on the DBB (See 'DBB') for digital content distribution to their respective Clients (See 'Client').

• A Partner may be one of the following: Movie Studio, Broadcaster, Cable Network, Music Company, Game Company.

• In the future, Partners may extend beyond the entertainment industry to any business that is relevant to or has needs for content distribution (e.g. B2B transactions).

Pathfire Pathfire is a third party system used to transfer files to US based TV stations (http://www.pathfire.com/).

PO See Purchase Order.

PRISM PRISM is an application used to manage scheduling and configuration of Blu-ray DVD, and other Home Entertainment releases. Aka Pathfinder 2.

Proactive DBB Ingestion

The 'Proactive DBB Ingestion' process illustrates how Components (See 'Components') are ingested into the DBB (See 'DBB') for demand planning, i.e. New Release title supply.

Product A Product is the core video and audio Components (See 'Component') that are created and distributed via the DBB (See 'DBB') as a result of a Request (See 'Request').

Product Assembly The 'Product Assembly' process includes the Automated Content Processing (See 'Automated Content Processing') services that transform all Components (See 'Component') into a finished Product (See 'Product') based off of Specification (See 'Specification') and Variable (See 'Variable') information provided in the Client Profile (See 'Client Profile').

Product Deliverable Product Deliverable is the final Product (See 'Product') and associated ancillary Materials (See 'Material') that will be delivered to the Client (See 'Client').


35

Product Specification A Product Specification defines the file-specific transcoding info, e.g. bit-rate, frame rate, file format, etc., needed to manufacture and distribute a Product (See 'Product').

Purchase Order, aka PO

A Purchase Order, aka PO, is the breakdown of line by line Billing Transactions (See 'Billing Transaction') that represent the prices of services rendered by a supplier to be paid by the Partner (See 'Partner').

QC Encode The 'QC Encode' process represents the quality control processes executed to ensure Encoding (See 'Encode') occurs as needed to fulfill a Request (See 'Request').

QC Ingest The 'QC Ingest' process represents the quality control processes executed to ensure what is Ingested (See 'Ingest') is what was meant to be Ingested (See 'Ingest').

Rate Card The Rate Card contains pricing information that the DBB (See 'DBB') will use to help calculate how much to charge for services performed based off various information, such as Partner (See 'Partner'), deal type, etc.

Raw Material Quarantine

The Raw Material Quarantine is the staging location where all incoming Components (See 'Component') reside and are reconciled against their Component Requirement (See 'Component Requirement') prior to being Ingested (See 'Ingest') into the DBB (See 'DBB') for inventory integrity purposes.

Raw Materials Raw Materials refer to the source Assets (See 'Asset') that will be used to create a finished Product (See 'Product').

Redelivery The 'Redelivery' process manages the client’s compensation for a Rejection (See 'Rejection') in the form of a Redelivery of either the Package (See 'Package'), or part of the Package (See 'Package'), that has been Rejected (See 'Rejection').

Rejection The 'Rejection' process manages Rejections of any part of the Package (See 'Package') that has been delivered to the Client (See 'Client').

Request A Request is issued by a Requestor (See 'Requestor) on behalf of a Partner (See 'Partner') for any DDB (See 'DBB') output and will contain information needed to support estimating and content processing, such as Title (See 'Title'), Alpha (See 'Alpha'), Request Type (See 'Request Type'), Client (See 'Client'), Client Profile (See 'Client Profile'), and Due Date related information. Request input data can be received from an Originator (See 'Originator') in various formats, including xls, Ventana, ITSMS, 3rd party systems, etc.

Request Type Request Type is an organization capability that will use business rules to drive how Requests (See 'Request') are treated throughout the DBB (See 'DBB').

Requestor A Requestor is the person who inputs the Request (See 'Request') information provided by the Originator (See 'Originator') into the DBB (See 'DBB') for manufacturing fulfillment.

Retrieval Retrieval is the act of obtaining Components and/or Materials from their respective locations for processing.

Security Features • Security Features is an overarching term that encompasses various ways to protect the digital content in the form of a Product (See 'Product') and/or Package (See 'Package') that is being delivered to the Client (See 'Client'), e.g. Watermarking, Fingerprinting, etc.

• Depending on the Security Feature type, security can be applied at various levels, such as at the Product (See 'Product'), Package (See 'Package'), and/or delivery method level.

• Classified as one of the Automated Content Processing (See 'Automated


36

Content Processing') services.

Sony Sound Robot Sony Sound Robot is an archival HSM system used by Sony Sound to store dubbed languages and conformed audio.

SPE Sony Pictures Entertainment

Spec See Specification.

Specification, aka Spec

• Specifications contain the DBB (See 'DBB') manufacturing instructions that dictate what unique criteria should be used in order for the manufacturing process to result in a specific outcome.

• Specifications exist on their own and are associated to a Client Profile (See 'Client Profile') for any Title Type (See 'Title Type') once a Client (See 'Client') has identified which Specifications they want to use. Examples of Specifications include: Product Specification (See 'Product Specification'), Metadata Specification (See 'Package Specification'), etc.

Specification: Image See Image Specification.

Specification: Metadata

See Metadata Specification.

Specification: Other See Other Specification.

Specification: Product See Product Specification.

SPIDR • SPIDR (Sony Pictures Internet Document Repository) is a web content management solution deployed throughout SPE. The various content tools includes: document management, web content management, collaboration, and WebScan. SPIDR is integrated with various key business applications to provide centralized content management services. It allows employees, customers, partners and associate to collaborate, contribute and access business content securely anywhere worldwide.

• The SPIDR Program is sponsored by GPI's Records & Information Management team. The SPIDR-Stellent content management system is developed and maintained by Enterprise Technology Services.

SPIRIT SPIRIT is used to managed Domestic theatrical bookings and non-theatrical and ancillary sales such as airlines, hotels, and prisons. Primary users are Sony Pictures Releasing and Non-Theatrical and Ancillary Services.

SPT Sony Pictures TV.

States States is the general term being used to refer to statuses.

Task A Task is any single activity (encode, ingest, transcode, watermark, QC) needed to form a complete Workflow (See 'Workflow').

Technical (Product) Metadata

Technical Metadata represents the data values that are captured, e.g. file size, bit-rate, codec, etc., during DBB (See 'DBB') manufacturing and added to a Package (See 'Package') as a Package Element (See 'Package Element').


37

Title Within the context of the DBB, at a high level, a Title is the master data describing the intellectual property, which is maintained within the DBB (See 'DBB') as the highest level of organization for its content that allows it be searched on, retrieved, manufactured against in order to fulfill a Request (See 'Request').

Title Type Title Type is an organization capability that is meant to differentiate among Features vs. Episodics vs. Trailers. Each Title Type will have its own set of Specifications (See 'Specification') within the Client Profile (See 'Client Profile').

Trailer Metadata Trailer Metadata is the descriptive information that accompanies a trailer.

Transcode Transcode represents the process used to transform a master format into a product derivative. Transcode is classified as one of the Automated Content Processing (See 'Automated Content Processing') services.

Variable A Variable is the input value used in conjunctions with a Specification (See 'Specification') that may be unique to a Client Profile (See 'Client Profile'), i.e. aspect ratio preferences.

Ventana Ventana is an application used to capture domestic TV sales and availability-related information. Primary user is Sony Pictures Television.

Visible Watermarking Visible Watermarking uses a method to overlay a visible image that can be read / seen when the digital file is played. Visible Watermarks can be cropped out of the video or image. Visible Watermarking is classified as one of the Automated Content Processing (See 'Automated Content Processing') services.

Watermarking Watermarking can take several forms, e.g. Visible Watermarking (See 'Visible Watermarking'), or Invisible (aka Forensic) Watermarking (See Forensic Watermarking'). Overall, however, Watermarking is a form of Security Feature (See 'Security Features') that serves to uniquely identify the content. Watermarking is classified as one of the Automated Content Processing (See 'Automated Content Processing') services.

WIP Storage Any storage area or system that is used to temporarily manage files or data for a defined period of time as set by business rules.

Workflow Workflows manage Tasks (See 'Task') needed to create a Product Deliverable (See 'Product Deliverable'). Workflows may be configured to govern complete end to end manufacturing processes, individual tasks or groups of tasks as required.

Workflow Management

The 'Workflow Management' process creates and maintains the Workflows (See 'Workflows') that serve as the manufacturing instructions to fulfill a Request (See Request').

XML See Metadata File. XML Creation XML Creation refers to the process to generate XML files within the DBB.


38

Xytech Xytech Systems Corporation, a media and entertainment based software development and integration company headquartered in Burbank Ca. Xytech has been in business for approximately 20 years and has a very robust enterprise software system called "Enterprise" that is implemented on over 200 locations worldwide. While this product focuses on all aspects of the post production industry, two large studio implementations exist. These implementations focus upon the entire studio fulfillment process including worldwide inventory management, fulfillment procurement and financial integration. The SPE GOLD system is one such implementation. Other Xytech Enterprise modules include scheduling, bidding, asset creation, job management (work order), distribution, digital fulfillment and others. The Enterprise product is currently built on a PowerBuilder platform. The new platform is built on .Net and has been referred to as Xytech .Net or MediaPulse which is the trademarked name.

Xytech: MediaPulse MediaPulse is the latest platform of the Xytech enterprise management product. MediaPulse has been in development for 3 years and possesses some but not all functionality supported by the earlier PowerBuilder product.

Xytech: Xytech.net Xytech.net is a term used in some areas to refer to the MediaPulse product. These terms are synonymous, but MediaPulse is appropriate.

Appendix B – Process Flow Description

These “To-Be” process flows reflect the overall business and operational vision for the DBB. The flows illustrate the functionality that any one file may utilize from encode and ingest to delivery, and the user’s interaction from request to tracking. Several process steps are subject to Partner or client defined business rules and may not be required for every file. The steps indicated in green are expected to be included in Release 1 automation. Red boxes with green “shadows” may represent a mix of automation and manual process. Red boxes are not in scope for Release 1.

The process flow diagrams are found in a separate document, DBB RFP Apx B Process Flows.

High Level Digital Backbone Workflow

From the highest level perspective, the Digital Backbone is considered an innovation in media content distribution. In order to achieve innovation in this space, primary focus must be given to innovations not only in technology but in information and process as well.

In order to improve speed, reliability, flexibility and scalability of distribution processes it is necessary to analyze and deconstruct the current processes. The High Level Digital Backbone Workflow highlights the scope of current processes to be addressed by the project and highlights some of the key events to be addressed and transformed.


39

1.0Create

Request


3.0Define

ManufacturingPlan

4.0ExecuteProduct

Manufacturing

5.0Create

Package

6.0Fulfill

Request

1.0Create

Request


3.0Define

ManufacturingPlan

4.0ExecuteProduct

Manufacturing

5.0Create

Package

6.0Fulfill

Request

Notification Workflow

Approval Workflow

1.0 Create Request

In current Processes requests are submitted by operations responsible for the licensing of content to operations responsible for the fulfillment of that content to licensees. These requests take many forms based upon the variation of submitting organizations and the types of licensing agreements. The fulfilling operation performs the necessary analysis to identify key information regarding the identification of the content (referred to as Title/Alpha), the client to be serviced and the terms of servicing such as due date. This process will be largely unchanged due to the numerous types and complexity of requests. This is the core work of the servicing operation, customer interface.

Upon translation this information will be entered into a Request Module within the DBB. This module will allow input, status monitoring and maintenance interfaces to be used directly by servicing operations.

2.0 Perform Materials Analysis

The next step in the fulfillment process is an analysis of inventory requirements. In order to create a manufacturing plan that will result in the creation of deliverables needed by the licensee, an analysis of inventory must be conducted for each title alpha. This analysis begins with the definition of the final deliverables required by the licensee (product) and then progresses through each level of the components used to create the product from the duplication master to discrete video, audio and text components to the original master created by production. For each client requirement this process, in various forms is undertaken either by the servicing operation or a supplier.

3.0 Manufacturing Planning

For each Title Alpha, once the status of inventory is known, a manufacturing plan can be created. This plan can involve a small number of steps such as for a duplicate and ship requirement or can and require more complex manufacturing that could involve processes such as down conversion, audio layback and subtitle application prior to the duplication and shipment. The Manufacturing Plan is determined based upon the existing inventory components and knowledge of the manufacturing workflow.


40

The DBB seeks innovation in this area through the creation of an inventory model that is both unambiguous and highly organized and through the documentation and automation of manufacturing workflows. The Customer specification can be considered the end state of the inventory and manufacturing workflow concepts. With these concepts it is envisioned that the selection of Title/Alpha and Client may allow the DBB to automatically determine a manufacturing plan. While it is intended that this process be fully automated an overarching intent is to separate the core work of the servicing operation with the process of creating the manufacturing plan. DBB operational personnel will review and augment manufacturing plans that will provide the needed output, thus providing greater value to the servicing operation.

The documentation of workflows will integrate with a rate card system to allow cost estimates to be generated. The current goal of DBB inventory visibility extends to key physical components that are required for ingest. Should a component be missing, estimates of cost and lead time would be required from outside the DBB. However, the concepts of unambiguous inventory and documented manufacturing workflows will provide the additional benefit of supply rapid “what if” analysis to sales organizations. The ability to generate a list of Titles that can be serviced rapidly within the DBB within a given budget range becomes possible.

The generation of a manufacturing plan and the associated cost estimates will facilitate order approval, the next step in the fulfillment process.

4.0 Execute Manufacturing

Once a manufacturing plan is approved, it can be released for execution. This process currently involves procurement related activities or in house manufacturing.

A key innovation of the DBB is the automated management of content processing technologies. The maturity of these technologies and their ability to be controlled by standardized data interfaces facilitates the automation of large sections of the fulfillment process. Through the creation of highly organized and unambiguous inventory and the documentation of manufacturing workflows, workflow orchestration tools can initiate and control the various content processing technologies such as file management, transcoding, packaging and delivery.

The combination of these concepts mirrors the model of other supply chain management workflows. The use of “Bills of Material” and “Bills of Operation” while new to media content processing are mature concepts in many other forms of manufacturing. The use of automated content processing technologies allows the organization of information to support a fully automated fulfillment process.

5.0 Package Creation

The packaging process presents a unique challenge as it must support the continued automation of the fulfillment process. Products must be delivered to an exacting standard with supporting media and metadata so that they can be consumed by client’s content management system. The variation of these standards requires flexibility in the management of information and supporting media.


41

Currently, this process is almost fully manual and while some steps may continue to require manual intervention, the DBB will consolidate and support the aggregation of supporting media and metadata. Through integration with corporate systems and standardization of processes, the retrieval of these package elements may be partially or fully automated.

6.0 Fulfillment

Once all package elements including the product are gathered, packaging and delivery can be completed. The DBB will support several forms of delivery needed to support the broad requirements of licensees.

Conclusions

The automation of any process requires the creation of highly organized processes. Automation by nature lacks the input of human support and relies upon predictable business rules for decision making. It is the goal of the DBB to engineer the requirements of automation into the process while at the same time providing tools for close human monitoring and control. Strategic interface points will allow for the flexibility in exception handling that is necessary to any operational environment with the intent that these interfaces be as passive as possible.

It is also understood that where possible, uniformity of processes must be a driven intent within the entire work stream. Among the many benefits are reduction of repetitive work, greater speed and accuracy in delivery and superior visibility through the entire supply chain.

With our goal of creating innovation in media fulfillment in mind, the DBB project will undertake innovation in technology, organizations, operations and information, creating a more successful supply chain for Sony Parties and our future partners.


42

Appendix C – White Papers

White Papers cover the following areas and are enclosed with the RFP: C-01. Fundamentals of Digital Supply Chain

C-02. Partner / Client

C-03. Request Maintenance

C-04. Inventory Organization

C-05. Workflow Master Data

C-06. Manufacturing Planning

C-07. Task Management

C-08. Managed Multi-Tiered Storage Environment

C-09. Search

C-10. Ingest / Encode Management

C-11. Package Metadata

C-12. Package Creation and Management

C-13. Financial Processes


43

Appendix C-01 Fundamentals of Digital Supply-Chain

The Distribution Backbone represents a drive for Sony Corporation to extend its presence as a Center of Excellence for Entertainment Supply Chain service to digital. Our focus for release 1 is to deliver immediate payback to the Sony Parties by virtue of the requirements captured in this RFP, especially as depicted in these white papers. The importance of this initiative prescribes foresight into how our digital supply chain evolves over time and leverages the knowledge and experience throughout the various Sony Corporation divisions.

Relentless pursuit of supply chain performance, flexibility & agility through leveraging our supply chain KPIs (continuous improved), supply chain guiding principles, targeting advanced technologies, lifecycle management and the effective segregation of planning & analysis activities from execution efforts. The supply chain expertise within DADC and its application across SPE, Sony Music Entertainment, Sony Computer Entertainment and many partners will be drawn to provide a perspective on how the DBB must advance after its initial release and apply leading operational practices in addition to advanced automated content processing functions

Product Lifecycle Management

In addition to the intrinsic characteristics, a product will also have a typical Lifecycle it will follow. This Lifecycle can be tracked from the product’s inception all the way through its end of life, with optional resuscitations. The lessons from the physical manufacturing of entertainment content on optical media teaches us that there will typically be a hockey stick ramp-up in demand, followed by a decay curve with varying rates of decline. Such knowledge enables enhanced capacity planning.

As a provider of digital supply chain services, Sony Parties will have a vested interest in its customers’ Product Lifecycles as a data point to feed into planning activities related to the DBB. This type of awareness is what will allow the DBB to operate at very high levels of efficiency while delivering leading service levels at reasonable cost.

The B2B and digital aspects of the DBB alters the dynamics of Product Lifecycle Management but similar principles can be applied at various levels. For example, the Managed Multi-tiered Storage Environment can benefit from knowing product release windows and preempt movement of files between tiers to minimize retrieval latencies as well as the cost of storage in an online storage tier. Furthermore, Product Families, as explained below, can affect the characteristics of a Product’s Lifecycle. Additional Lifecycle information can be derived from attributes such as whether a title is a sequel or prequel as well as general contextual events such as a shift in file format at an industry level.

Product Families


44

Analysis of product types, processing steps, format types, bit rates and delivery specs requirements can often lead to identification of patterns. Further examination of the patterns will often lead to groupings based on intrinsic characteristics of the product that is being manufactured, in both physical and virtual senses of the term. These groupings provide natural segmentation that can be used to group products into families for which different processes and execution rules can be applied.

The DBB must be flexible and support customization of orchestration workflows according to these Product Families. As with most segmentation efforts, the alignment of workflows to Product Families reduces the overall number of unique cases and exceptions. The goal is to streamline execution pipelines and make them flexible. This in turn enables focus on core processes that drive value within the supply chain.

As an example, analysis of operational data is likely to reveal commonalities between two major groupings of products: features versus episodic. Each type of product may have ideal flows that help its Workability (defined below). Similarly, acquired content may benefit from alternate processes or orchestration workflows compared to produced content.

Workability & Milestone Management

Building a digital supply chain involves the coordination of many process steps similar to traditional supply chains. The activities are planned in advance of execution with an emphasis on laying the groundwork to allow streamlined execution once the plan is put into effect. Defining Milestones within these plans allows for discrete units that can be more easily managed and tracked. Potential delays can be analyzed and tracked to root causes. Milestone Management therefore improves Workability, avoiding setbacks or exceptions during execution.

Having Workability & Milestone Management support provided by the DBB will be a core pillar in allowing Sony Parties to become a center of excellence by truly becoming a partner with its digital supply chain customers. The DBB can leverage Templates providing default process steps planned to a timeline adjusted by input parameters. Target dates are established and can be tracked against actuals and provide an opportunity for collaboration to meet unified objectives with mutual understanding of an adjustment’s effects.

The DBB will have dependencies on external touch points that may affect Workability such as obtaining Masters from the Mastering group. The Milestone of receiving the Master can be captured in a Template with parameters related to Product Families such as varying mastering lead times between theatrical and episodic titles. Breaking down the overall work into Milestones may help identify the root cause of requisitions not being completed on time. Analysis of these requisitions may show patterns

associating the delays to a particular Product Family (e.g. Masters for acquired content may often encounter delays due to the uncontrolled or unknown quality of source materials coming through via acquisitions) and help address Workability by


45

focusing efforts on the improvement of processes or systems for that particular segment that can be tracked down to a particular Product Family.

Run Strategy & Optimization

With these vital foundations in place, further optimizations can be implemented. The foundational elements provide data points that can be processed through sophisticated analytics leading to additional identification of patterns as well as people driven continuous improvement. These patterns and process improvements can then be used to define rule sets at varying levels that are fed in as Run Strategies.

Flexibility is a key tenet the DBB must adhere to and it will ultimately allow the effective use of the Run Strategies defined above. At the system level, the ability to apply rule sets that optimize the supply chain must be a core capability of the system and one that can ideally be leveraged across all supply chain systems, even outside of the DBB. This extensibility supporting enhanced supply chain practices should not be limited to the DBB but made available for integration throughout the Entertainment Supply Chain Center of Excellence.

The Sony Parties expect to pool existing knowledge to incorporate Run Strategies and Optimizations wherever possible for the initial rollout of the DBB. This knowledge will come from data points of the existing systems and processes and will be incorporated for the to-be solution. An immediate impact will be seen on how the migration Run Strategy will be defined to ensure that the titles and clients that drive the highest benefit will be imported and on-boarded into the DBB. Initially, the resulting rules may be applied in a semi-automated procedural manner, but Sony Parties’ long term goal is to truly apply the Run Strategies and Optimizations in a more systematic way with automation included wherever it is beneficial.


46

Appendix C-02 Partner / Client

1. Overview The Distribution Backbone, hence forth referred to as DBB, will require the maintenance of certain types of data in order to accomplish its vision of providing Partners with the capability of servicing their content distribution needs. Partners, Clients, Client Profiles, Specifications and Configurations are several key entities for which data will have to be stored and managed within the DBB. 2. Description The diagram below is a sample entity relationship diagram depicting how Partners and Clients are expected to relate with Client Profiles, Specifications and Configurations. The purpose of this diagram is not meant to define the final design but meant to help describe the types of relationships expected to satisfy SPE future state process maps.

Partners are content owners and customers of the DBB. Partners will sponsor users and grant them access to the DBB in order to generate requests and visibility to workflow status. Each Partner will have the ability to distribute content to one or multiple clients.

Example: Sony Pictures Entertainment will be the first DBB Partner.

Clients are companies under contract with Partners to receive content. A Client record defines information needed to define the business entity. While contact information may exist at this level, Contacts may also be associated with Client Profiles as described below.

A single client may do business with multiple partners e.g. Amazon with SPE and Paramount. A separate client record will be maintained for each Partner. However, all client records representing the same company under multiple partners must be associated to provide a view of that Client across all Partners.


47

Sample Clients include Apple and Amazon (DDI), Comcast and AXN (Broadcast). Clients will be added to the DBB on an as needed basis in order to fulfill Partner requests for content distribution.

Client Profiles will be used to define the requirements of each client for content delivery. One or more Client Profiles may be set up per client to represent multiple business models for that client, e.g. DST, DDI, VOD or as requirements vary by territory or other business / technical reasons. As stated above contact information may be associated to a Client Profile if multiple contacts exist for the client. Client Profiles will be created by DBB Administrators.

Specifications will define key variables and requirements needed to support automated and manual workflows. Specification information may be common across many clients. It is envisioned that a specification master will be maintained allowing the association of a single specification to multiple clients. Modification of a Specification must be allowed at the Client level or at the master level. Modification at the Client level may result in a new record within the specification master. Modification at the master level would allow changes to be propagated to all clients associated to that spec. Validations should be in place to ensure that duplicate specifications are not created.

While the functional requirement of the specification is to support content processing and distribution, a human readable abstraction of specification data must be available to Partner for review and communication purposes.

Variables – In conjunction with a Specification, some information may be defined as unique to each profile. This information within the specification can be defined as input variables upon association to a Client Profile. For example a delivery specification may define a means of delivery, but variables specific to a Client may include aspect ratio preferences.

Configurations – Configurations are sets of information created individually for each client profile. While Specifications represent reusable information sets that may be associated to Client Profiles, Configurations can be specific and unique to a Client Profile. In some cases, “standard configurations” may be reused across multiple client profiles.

Specification Types - The DBB is expected to store and manage multiple types of specifications in support of content transformation and delivery. The initial list of specification types that have been identified include but will not be limited to:

• Product Specification – Defines the technical metadata required to create the final distributed product, which could include Video, Audio, Images, Captions, Subtitles etc. The Specification will be leveraged and shared with DBB services like transcoding in order to produce a final product with matching technical specifications. The Specification would include bit-rate, frame rate, file format, etc.


48

• Metadata Specification – Defines the information required to generate a metadata deliverable/file. Leveraging information available within the metadata specification, the system should determine the end-state metadata file format (e.g. XML, Excel, CSV…) as well as the specific metadata fields and values to be included for a specific Title/Alpha. It’s important to note that the metadata specification will have to act as a validation to enforce an appropriate end structure of metadata. Certain fields may be required and enforce data to be provided in a certain format (YYYY-MM-DD). Other fields may be defined to accept repeating values and controlled vocabulary. The metadata specification provides mapping and transformation business rules needed to interpret the DBB enterprise canonical metadata repository (see White Paper C-11: Package Metadata). Fields defined within the spec will have to be referenced using an enterprise canonical DBB metadata ID.

• Other Specifications – Additional required Specifications may be identified during design/implementation.

Example: An 8MB specification will define codec, bit-rate and processing details.

Configuration Types – The DBB is expected to store and manage multiple types of configurations in support of content processing and delivery. The initial list of specification types that have been identified include but will not be limited to:

• Assembly Configuration –Specific to content processing, there is a separation between the specification for the Product essence and the Configuration for assembly. Assembly Configuration defines the assembly and order of appearance of content and additions such as logos, ratings, warnings commercial blacks etc. This information is separated from the Specification for a Product due to the greater variability of these configurations based upon client needs. Multiple clients may take the same file spec and bit rate, but require different Assembly Configurations. Examples of Assembly Configuration items are Logos, ratings, bugs, and overlays, warning cards insertion, bars tones and commercial blacks.

• Package Configuration – Defines the information required to generate a package. Package related information may include packaging manifest location/format, packaging contents naming convention, contents directory path, output package directory path and package wrapper type definition (e.g. MXF, ZIP, directory structure or loose files).

• Delivery Configuration – Defines the information required to deliver a package. Though the intent is digital delivery (e.g. Aspera,


49

SmartJog, FTP), the delivery Configuration should also be able to handle physical output. An example is outputting a package to hard drive and having it shipped to a physical address. In this example, the delivery Configuration method would be “hard drive”.

Example: Let’s assume we are creating an FTP Delivery Configuration. The Selection of a method such as FTP would be part of the Configuration. Additional inputs such as IP address, Username, Password and Port would be entered to fully define the delivery method. This information would be stored as set of data associated to the Client Profile.

A second configuration for Hard Drive or Aspera could be added for the Client Profile. The data required for each configuration would be specific to the delivery method chosen.

Client/Profile Status – In order to control whether the DBB may service a Client or Client Profile, statuses and associated business rules must be configurable.

Profile/Specification association – Within the Client profile, multiple specs may be assigned within each category noted above. It is envisioned that one specification of each kind will be established as a default, but that the user may override the default and select a different available specification that has been associated to the Client profile.

Example: The default delivery specification for a client profile may be FTP, but due to the large size of a particular Request, the requestor may choose Hard Drive as an alternate delivery specification.

Title Type – Multiple Product Specifications may exist as described above. During association of a Product Specification to a Client Profile there will be a Variable that will allow definition of the Title Type. This will allow a Specification to be assigned for a specific type of Product e.g.: Feature, Episodic or Trailer. Each Title selected for processing would have either a default Title Type in the case of Feature or Episodic or would allow the selection of the Title Type in the case of a Trailer only request. This Variable supports the need to process different types of titles with different Product Specifications.

3. User Interface From a user interface perspective, managing Partners, Clients and Client Profiles is expected to be handled via a user interface. These features will mostly be managed by internal DBB business analysts. Specifications however, are technical in nature and would most likely be managed by a DBB technical resource and could be managed within XML if required.

4. Services For the initial release of DBB, it is not expected that services be exposed by the DBB other than through the UI for managing Partners, Clients, Client Profiles,


50

Specifications and Configurations. The management of this data will only be handled from within the DBB.

5. Interfaced Systems For the initial release of DBB, it is not expected that Partners, Clients, Client Profiles, Specifications or Configurations leverage interfaces to external systems.

6. Multi-Tenant The concepts discussed above regarding Partner/Client relationships inherently define multi-tenant requirements for the DBB. Administrative programs must allow the creation of the hierarchical relationships described above.


51

Appendix C-03 Request Management

1. Overview

The Distribution Backbone (DBB) will require a user interface to enable entry of requests for various forms of content processing. Request Management will provide functionality needed to identify clients and their needed deliverables. This user interface will be the primary point of interaction between the business users responsible for fulfillment and the DBB. All clarifying information needed by the DBB, whether technical or business related, will be managed through this interface. All status requirements of the business unit will be addressed through this interface. To the extent feasible it is intended that this interface utilize the data structures later described to create business intelligence that allows the user to enter more general information and be guided or assisted by the system into the level of specificity needed by DBB to fulfill the requirement.

Request Management is a suite of UIs that will allow access for authorized users to UIs described here and to more granular levels of DBB workflow details as described in later white papers.

2. Description

This Diagram displays the primary inputs to the Request Maintenance module.

SUPPORTING DATA

INTERFACED SYSTEMS

CORE PROCESSES

GPMS

TITLE/ALPHA

REQUEST MAINTENANCE

CLIENT MASTER

CLIENT PROFILES

LOB INPUTS

ONBOARDINGMANUFACTURING

PLAN


52

LOB Inputs – The LOB or “Line of Business” Inputs represent the Originator, e.g. SPE Sales Divisions. These divisions license content to various customers and require fulfillment from Requestors, e.g. Worldwide Product Fulfillment (WPF). Requestors will use the DBB to create and deliver this content. At a high level the LOB will provide deal terms such as license window, air date, license type and other meaningful information. This information will be included in the Request submitted by the Requestors. In addition, the LOB will provide the primary inputs for the request, Titles and Clients. In general terms and as applicable to Partners, this is business related information that could be required to be included in Package Metadata or to support Billing Transactions.

Clients – The Originator will specify one or more clients to be processed for a given request. DBB Requestors will determine the appropriate client profiles within a request in cases where a single client has multiple profiles. As described in the White Paper C-02: Partner-Client Relationships, Client/Client Profiles represent content licensors that have contracted with the LOB for specific Titles. It is assumed prior to the creation of a request that clients have been onboarded and all appropriate Profiles and Specifications have been created. Specification information must be made available in a view only format to the Requestor in order to facilitate Profile selection.

Title/Alpha – The essential directive within a Request is to deliver one or more specified titles to one or more Clients. As described in the White Paper C-04: Inventory Organization, the Alpha represents a content level variation within the title that may be specific to a given territory or market.

Example: For the title “Over the Hedge”, a scene where one character hits another character with a golf club had to be changed for theatrical distribution in Japan. Based upon this requirement, all post theatrical distribution to any Japanese customer must use the same edited version or Alpha.

Title/Alpha Selection – It is assumed that the selection of a specific Alpha in cases where a Title has more than one will be performed by the Requestor. However, this choice can be assisted / automated based upon the business rules that rely upon the metadata present at the client profile level and at the alpha level.

Specification/Configuration Selection - Content specifications and configurations will be defined and associated with Client Profiles. There may be multiple specifications and configurations associated to a client profile based upon the Title Type to be delivered. As stated in White Paper C-02: Partner-Client Relationships, multiple specifications and configurations may be present including a default. The Requestor may select alternate approved specifications within the Request. Information will be available to assist/automate the selection of the specification.


53

Example: Multiple Product Specifications are defined for a client, one for Episodic content and one for Feature content. Within the Client Profile maintenance the business rules for selection of the appropriate spec are defined. This could be done with a “Title Type” value for purposes of this example. This same metadata would be associated to the Title selected on the request, facilitating the identification of the essence specification as required by the Title/Client combination.

Multiple Titles/Multiple Clients Request – Requests can be generated in several different ways. The following are some examples:

• One Title and one Client

• One Title and multiple Clients

• One Client and multiple Titles

• Multiple Titles and multiple Clients

The most complicated scenario is the Multi-Title/Multi-Client. To minimize the complexity of this scenario, the desire is to ensure that when multiple Titles are selected, all selected Titles will be fulfilled to each selected Client. The Requestor will not have the ability to configure which Titles will be associated with which Client. In cases where not all Titles are fulfilled for all Clients, multiple Requests will have to be made.

3. User Interface

The user interface application will allow users to create, update, cancel and obtain status for various requests. A search and summary display is assumed as well. In cases where the definition of Client/Profile and Title selection require additional assisted/automated selections, these will be handled in a wizard format, leading the user through the decision-making process to the depth necessary to complete the order. This depth should reach to the level of specific Component search and selection as well as manual specification selection. The depth of determination allowed to a user should be configurable. Certain levels of selection such as for specific source Components may be determined to be under the responsibilities of operational personnel. The UI must support Mac and Windows based users.

4. Services

For the initial release, the Request module services are assumed to be exposed within the DBB only and will not require formal APIs to allow tie in with other systems. The architecture, however, should not preclude the flow of request data directly from any Partner.

5. Interfaced Systems

The Request module will have functional relationships with the Customer Master, Title Master, Workflow Master and Task Management. It is assumed


54

that these data sets will be within the backbone and not interfaced for purposes of application architecture. The only exception would be the GPMS Title interface. Title/Alpha information will be interfaced and will be stored internal to the backbone to the extent necessary to support distribution. The Request module may require a direct query to GPMS in order to view additional title information not stored in the DBB.

6. Multi-Tenant

The DBB will have multi-tenant capabilities as described in White Paper C-02: Partner-Client Relationships. Multiple “Partners” will require access to the Request UI. Login and security privileges must be maintained independently for each Partner user group. Data must be fully segregated for all levels of information described herein.


55

Appendix C-04 Inventory Management 1. Overview

In addition to the use of automated content processing technologies, key goals of the Distribution Backbone (DBB) include the extension of business rule based automation to all aspects of fulfillment workflow. Current filmed entertainment inventory metadata models do not possess the rigorous organization required to support automation in the areas of source asset identification. Asset receipt and storage processes and the metadata typically recorded are subject to significant error rates. The resulting manual labor required to identify the correct source assets at production run time has become a significant bottleneck in current digital fulfillment. The implementation of more stringent and rigorous metadata controls can enable the automation of asset selection and greatly reduce manual intervention and overall throughput.

Two key concepts have been identified that require more structure in order to support unambiguous inventory. The concept of Version has been renamed in Sony Parties nomenclature to “Alpha”. This concept represents the variation of content that may exist within the inventory for a given title. Adding structure to this concept will allow more accurate interrogation of inventory, creating compatible “Kits” of inventory within a given title. Within an Alpha organization, Component based inventory leverages traditional manufacturing disciplines by facilitating the linking of source assets to the workflows which they support.

These concepts will support automated media content processing in the same way that a bill of materials supports the automation of traditional manufacturing.

It is conceived the scope of inventory visibility will encompass digital assets within the DBB DAM solution and will also extend to external physical and digital components within the Partner’s, in R1 SPE’s, Physical Asset Management solution. The extent to which the organizing principles described herein are implemented into physical assets must be flexible so that business needs for cost and lead time analysis may be met.

2. Description

This Diagram displays a sample hierarchy that exists between a title that has two Alphas (the Director’s Cut and the Theatrical Release) and the family of components that would be identified to service the Director’s Cut Alpha.


56

Title

AlphaTheatrical Version

AlphaDirector’s Cut

Component16x9 FF HD Video Asset

ComponentConformed 5.1 English Audio

ComponentConformed 5.1 Latin Spanish

Audio

ComponentRendered

English Closed Captions

Alpha – The alpha concept facilitates two key requirements within the DBB; identification of the client needs for a title with version based video or audio content variation and as an organizing principle of asset inventory needed to service those variations.

An Alpha typically describes differing versions of a title. These differences are typically related to where and how the Title/Alpha may be distributed. An Alpha may be created based upon Standards and Practices edits required to display the title in a particular territory, market or media. As each customer will possess market, media and territorial definition within their profile, the association of the same data to the alpha may assist in the automated identification of appropriate version for the selected client. The association of various concepts of distribution rules to each Alpha is required.

Example: The “Unrated” version of a film may be cleared for worldwide release but only for digital sell through. An edit of the same film, removing specific scenes of violence or profanity, may be the only


57

version cleared for TV distribution in one or more foreign territories. As a result, the DBB could select the Unrated version for a DST client and the edited version for a UK broadcast customer.

The Alpha will also be used as an organizing tool for asset inventory both digital and physical. Current business processes result in the creation of families of assets needed to service each Alpha. Picture elements of various aspect ratios and standards are created for each Alpha beneath a given title. Audio and text assets are then created to conform to these picture assets. Processes which support the creation, association and containment of all assets created to service a particular Alpha is required. At a minimum, ingest will require the identification of a specific alpha for all assets added to the DBB.

The Alpha concept also extends to the identification of Trailers. The identification of the Trailer to use for a specific client follows the same rules as would be applied to variable full program content.

Kits – It will be necessary to organize components that are determined to work together (conformed and synched). This will allow workflow master data to point to a Kit Type. Under the Alpha, the kit will allow specific confirmation of assets that will work together. A kit will have one video component and one or multiple audio components where any audio will work with the video within that kit. Workflow master data (supported by client specs) will handle the variability of which audio or supporting material is used from within the kit. Current DIAMONDS assets (muxed audio and video) are a single kit.

The kit type must be known to the Workflow master data and must have attributes that will allow the selection of the correct kit based upon key values such as aspect ratio and standard.

Components – Components represent the discrete audio, video, text and/or combined assets that are stored as source assets for content processing. While the Component concept can be extended to archival or protection assets, its primary role is to allow unambiguous identification of assets that are required for specific manufacturing processes. Components can, in many respects, be considered similar to a “part number” in traditional manufacturing. Component organization may extend from the DBB to provide visibility into key physical assets.

The input of an asset into the DBB has three distinct parts.

a. Component Type – A Component Type represents a specification that describes the asset in as much detail as possible. The specification will determine the acceptable range of values for metadata fields that are key to content processing. It is envisioned that all components ingested into the DBB must be accepted against


58

a Component Types in a similar manner to a material receipt in manufacturing terms.

Example: A Component Type representing the 16x9 Letterbox SD video assets will have flexible specifications that will allow each key field to be limited to values that match what is acceptable for the component. Below, a list of Aspect Ratio values that the asset would be limited to if it were to be a considered for this Component Type. Such definitions for technical data would extend to all inventory metadata values key to content processing.

b. Component Requirement – A Component Requirement (CR) is the request for a specific Component Type within a specific Title/Alpha. It is envisioned that CRs will drive the creation and ingest of assets into the DBB. CRs may be created as a result of a Request (White Paper C-02: Partner-Client Relationships) or may be create through manufacturing planning activities where a mastering group will fulfill CRs necessary to ready a Title/Alpha for distribution.

Example: The Theatrical Alpha for Spider-man 4 is in production for post theatrical distribution. The planning group identifies video asset requirements for the backbone for eight video Components. These are DBB master spec video assets varying in aspect ratio and standard, all needed to support downstream DBB production. This results in the creation of eight CRs which are fulfilled by the mastering group. When the assets are created to the component specification and delivered for ingest they will be accepted or rejected prior to ingest based upon examination against the specification requirements. Once accepted, the asset will fulfill the CR.

c. Component (fulfilled) – Once the CR is fulfilled through the acceptance and ingest of the asset the Component will become available to the DBB for processing. As will be described in White Paper C-05: Workflow Master Data, each content processing specification may identify one or more components required to create the end product. Only when fulfilled Components exist for a particular Title/Alpha may a content processing specification be executed.


59

Assets – Rich media Assets within the backbone represent the essence(s) of the Components as described above. Assets are maintained with independent metadata as is common in most MAM/PAM systems. In the DBB they will also be associated with the specific Component they were ingested against. The Asset metadata will allow the DBB to interpret content processing variables that may exist between titles.

Parentage – It is necessary that parent assets be recorded during encode and ingest. It is also necessary to record this information should new master Components be created within the DBB. This information linkage must allow users to trace the actual assets used to create any DBB asset back to the encoded physical master or ingested file.

Component Succession – In order to preserve unambiguous inventory it is important to control replacement of Components and prevent the entry of duplicates into the DBB. When a Component Requirement is created and there is an asset present in the DBB under the same Component and Title/Alpha, the system will manage succession by identifying the duplicate and indicating that resolution workflow is required.

3. User Interface

While it is envisioned that the DBB will be interfaced to a partner’s Title master for Title/Alpha generation, it is envisioned that the DBB UI will support direct creation of Titles and their associated Alpha’s. It should be noted that parameters associated to both Titles (e.g. Title Type) and Alphas (e.g. Aspect Ratio) will also need to be entered via the DBB UI.

User interfaces supporting the Alpha will require administrative configuration programs needed to create Alpha types. These types will allow common Alpha types such as theatrical or directors cut to be standardized and used across all appropriate titles. These administrative programs will allow business rule definition regarding the concepts of Territory and Market applicability described above. It is envisioned that an additional level of administrative programs may be needed to create Alpha templates for the common business rules.

The creation of Component Type specifications is closely linked to White Paper C-05: Workflow Master Data and may be contained in an integrated suite of UIs. This UI will require the ability to create a record that includes the technical requirements a media source must meet in order to support designated workflows. These records will be linked to the workflows, creating integrated inventory and content processing information.

Component Requirements must be created in a proactive manner. A user interface will be required for mastering personnel to create Component Requirements in order to support new mastering assets ingest.


60

4. Services

It is required that the DBB possess exposed services capable of interfacing with a partner’s Title master. For SPE specifically, these services must support Title, Alpha and associated business rules as described above.


For the Sony Pictures Entertainment implementation, interface to the GPMS (Global Product Master System) is required. The DBB will store Title/Alpha data that is operationally necessary. The DBB will support the interface from GPMS for R1, but must be extendible to an API that will allow Partners to interface title data into the DBB. Interface to the GOLD System (Global Ordering and Library Database) will be necessary in order to provide the DBB with Component visibility to key physical assets. In order to provide visibility to costly manufacturing scenarios, it may be necessary to extent DBB Component visibility to key assets such as high def video masters or dubbed audio languages.

6. Multi-Tenant

Each Partner will own any number of titles within the DBB. Inventory will be separated based upon the organization of Titles under each partner. Users must be sponsored by a Partner and will be provided rights to titles and their associated assets based upon that Partner.


61

Appendix C-05 Workflow Master Data 1. Overview

The Distribution Backbone (DBB) must support automated workflow wherever possible. A review of current fulfillment processes indicates that for some processes, decisions regarding source asset selection, content processing requirements and even packaging may be governed by business rules. For other processes human intervention may be required to clarify ambiguity. With the continued consolidation of Client deliverable specifications and the simplification of source inventory enabled by content processing technologies, the internalization of business rules regarding workflow processes becomes possible and increasingly desirable.

Additionally, providing exact specification details to automated content processing systems is a necessity. The errors introduced by a “make to order” model does not support many of the efficiencies envisioned in the DBB. The creation, testing and implementation of content processing workflows by engineering personnel provide a superior platform for consistent performance. The ability to call upon these workflows through the use of simplified business rules will allow an efficient separation of labor that will enhance both customer service and content processing.

Workflow Master Data provides metadata around workflows that supports manufacturing planning. This metadata identifies the workflow needed to support a Client Specification. In addition, required Kit and Component information is supported outside of the workflow data in order to allow efficient interrogation of inventory. With this supporting information the definition of a client specification and the Title/Alpha required will allow the Manufacturing Analysis Engine to determine the appropriate source inventory requirements and the workflows needed to create Products. Workflow Master Data acts in concert with Inventory Metadata Organization White Paper C-04: Inventory Organization in order to support the requirements of the, White Paper C-06: Manufacturing Planning.

While full automation is desirable, flexibility in an operational environment is also a key requirement. DBB Services and the workflows that coordinate them will be designed in a modular fashion. While workflows may coordinate the input parameters, actions and outputs of multiple services in an end to end process, they must also provide access to the basic services of the DBB. Key Tasks are operations that may have direct UI requirements that do not involve a Manufacturing Plan. These tasks, such as File Retrieval, Transcoding, Packaging and others must be executable based upon user defined parameters. This will allow the full use of DBB services by operational personnel in order to deal with interim or special workflows that cannot be fully automated.

2. Description


62

The following diagram describes the role of Workflow Master Data with DBB. In light blue are choices defined by the Requestor. Information in the green boxes is derived from DBB Inventory and Workflow master data.

Workflow Master Data

Title

AlphaTheatrical Version

AlphaDirector’s Cut

Component16x9 FF SD Video Asset

ComponentConformed 5.1 English Audio

ComponentConformed 5.1 Latin Spanish

Audio

ComponentRendered

English Closed Captions

Client Deliverable Spec.

DST_MPEG2_20MbLAS/ENG

Client Profile

Required Component

Types

Content Processing Workflows

Workflows - Entity Relationships displayed above display an approach to metadata management where the core requirement is to separate the identification of Content and Client from the definition of the manufacturing plan. As the Requestor identifies the Client profile, DBB is able to identify the client specification. With this information the DBB is able to determine the workflow to be used to create the specified Product deliverable. These processes will be created and managed by administrative personnel and will be vetted through the onboarding process.

Client Spec Based Workflows – Manufacturing Planning is based upon the identification of Client Specs and Title/Alphas. Workflow Master Data defines the workflows necessary to complete a Client Spec and defines the inventory requirements of each workflow. This data allows “what if” scenarios to be run


63

through the backbone without exercising the business rules of the workflows themselves.

A Client Spec based workflow will actually be a series of workflows that will be designed to conform to the state of inventory for a given title alpha.

Example: A workflow designed to create an 8MB Mpeg2 output will include steps encode and ingest the master video file if that file is not present within the DBB. If the file is present in the DBB, these steps will be skipped and the workflow will begin with a file retrieval step.

UI Based Workflows or Key Tasks – The workflow orchestration tool will be the key point of interaction with DBB Services. While it is desirable that client spec based workflows are the norm for distribution scenarios, all Key Tasks within the DBB must be available to operational personnel.

Example: A manufacturing plan for an 8MB Mpeg2 for a German Language client requires a conformed and synched German audio track. The current kit needed to service this spec is missing the track. Due to a rush order, the conformed, synched track is delivered directly to operational personnel who then execute a Key Task designed to allow retrieval of specific files from the DBB, selection and execution of the appropriate transcode spec, packaging and delivery to the client.

Key Tasks will be specifically designed to support common operations and will support the requirements of production that cannot be automated based upon specific business needs.

Orchestration - It is envisioned that a workflow orchestration tool would be used to create, manage and orchestrate the tasks required to execute workflows. This tool should allow for the inclusion and interrogation of business rules that might be content, client or otherwise specific and which would materially affect how the workflow is executed and/or which tasks within the workflow are necessary.

Supporting Data – Workflows will govern Tasks to be orchestrated and their dependencies. These workflows will interact with supporting data that will facilitate inventory selection and billing requirements and other inputs. This data will include but not be limited to the following.

These workflows would generally contain the following information:

1. Tasks – A Task is defined as any step within the workflow that is required to proceed from source master elements to a final client deliverable. These tasks will include Encode, Ingest, QC, Transcode, Watermarking etc. The workflow orchestration solution will allow the flexible creation/configuration of tasks needed to support both new content processing technologies and expanded automation. Tasks are the primary building block of content processing orchestration.


64

Each task can be manual or automated and will have status and priority associated to it. See White Paper C-07: Task Management for a full description.

2. Billing Transactions – Work performed must be associated with billable services within the DBB. Billing Transactions will contain information required for the interrogation of rate card information by the billing system. White Paper C-13: Financial Processes outlines how Billing Transactions will be managed by the Backbone. Workflows will be designed to accommodate the needs of financial reporting so that Billing Transactions may be created and statused as the workflow completes.

3. Kits - It will be necessary to organize components that are determined to work together (conformed and synched). This will allow workflow master data to point to a Kit Type. Under the Alpha, the kit will allow specific confirmation of assets that will work together. A kit may have one or more video components and one or more audio components where any audio will work with the video within that kit. Workflow master data (supported by client specs) will handle the variability of which audio or supporting material is used from within the kit. Current DIAMONDS assets (muxed audio and video) are a single kit. The Kit may also include closed captioning, subtitle and other content types.

4. Component Types – When necessary, the input Component Types required by a Task must be identified. This information will support the analysis of asset inventory when a Title/Alpha is specified within a Request.

This information represents the core requirement for manufacturing planning and execution (White Paper C-06: Manufacturing Planning, White Paper C-07: Task Management and White Paper C-08: Managed Multi-Tiered Storage Environment)

Workflow Variables – Workflows will allow the configuration of variables for content processing cases. For example, two video assets for different titles may share a common Component Type. However, the asset level metadata may indicate differences that would impact content processing. Variables within the Workflow Master Data would allow the selection of a different content processing Task or set or Task based upon the differences in the two source files.

The Process Flow diagrams provided cover the scope of work to be controlled by Workflow Metadata. The general categories of workflow are as follows:

1. Encode/Ingest – The entry of source assets into the DBB

2. Product Transformation – Automated and manual content processing.


65

3. Metadata Creation – The creation of Client specific metadata.

4. Retrieval of Supporting Media – Manual or automated retrieval of supporting images, chapter stills etc.

5. Packaging – The application of packaging specifications to Product, metadata and supporting media.

6. Delivery – Delivery of Packages to Clients.

3. User Interface The creation and maintenance of Workflow Master Data must have a flexible user interface that allows content processing specifications to be identified, incorporated and linked into a specific Workflow. The UI must allow the creation of records that represent workflows and must allow each workflow to be linked to appropriate Client Specifications and Component Types (See White Paper C-02: Partner-Client Relationships). Workflows and associate Master Data must be easily copied and reconfigured.

NOTE: It is not assumed in R1 that the inventory organization information is fully integrated with the tool set/services that maintain and execute workflow master data.

Key Task user interfaces will be required to provide direct access to services within the DBB. These UIs will be discussed in greater detail in White Paper C-06: Manufacturing Planning, White Paper C-07: Task Management and White Paper C-08: Managed Multi-Tiered Storage Environment.

4. Services For the initial release of DBB, it is not expected that exposed services for workflow master data will be required. The Manufacturing Planning engine will access the data, but may do so with simple database calls depending upon final architecture decisions.

5. Interfaced Systems For the initial release of DBB, it is expected that Workflow Master Data will not leverage interfaced systems.

6. Multi-Tenant Sharing of workflow master data may occur across Partner instances allowing the workflow used for a common deliverable to be leveraged by multiple partners. However, this function would be administrative in nature. Both UI and data layers must be fully segregated in Partner instances. Rate Card information, as discussed above, must support variation by Partner and possibly special deal rates as well.


66

Appendix C-06 Manufacturing Planning 1. Overview

Workflow automation must be supported by master data as described in White Paper C-04: Inventory Organization and White Paper C-05: Workflow Master Data. These white papers and their requirements describe master data that is maintained across all inventory and content processing workflows. The Distribution Backbone (DBB) will utilize this master data to create specific manufacturing plans in response to requests from the Request Maintenance Module. These manufacturing plans represent the core instruction set for the orchestration of content processing and will generate the information points required for cost and lead time estimation.

While it is desirable to create and execute manufacturing plans without user intervention, it is understood that operational manipulation of these plans will be necessary to deal with uncommon cases. This information layer and its computational capabilities must remain flexible so that high rates of operational intervention early in the life cycle of the DBB may be supported and as these rates decline, high rates of fully automated planning may also be supported.

2. Description

The following diagram describes the entities and processes needed to create a Manufacturing plan in the DBB.


67

The Manufacturing Analysis Engine utilizes Workflow Master Data and Supporting Inventory data described in White Paper C-04: Inventory Organization and White Paper C-05: Workflow Master Data along with input from the Request Module described in White Paper C-02: Partner-Client Relationships. With the Client Specification, the engine can identify the appropriate workflow required. Within the workflow all Tasks needed to create the client spec are defined. In addition, all needed Component Types for each Task are defined where applicable. With this information, the engine first performs a Materials Analysis. DBB will query DBB inventory for the needed components for the specified Title/Alpha and Client Specification. The results of this analysis will determine the Tasks that are necessary to complete the Workflow required.

As describe in White Paper C-05: Workflow Master Data, Client Spec based workflows will be must account for all possible inventory scenarios. These workflows must cover the encode and ingest of needed inventory component through to delivery. They must be modular in nature and provide flexibility to handle scenarios where needed inventory is at greater stages of readiness. The Manufacturing Planning Engine will perform a Materials Analysis in order to determine the specific workflows necessary to create the needed Product.


68

A DBB workflow may include the transcode of a higher resolution file to a lower resolution file which is then packaged and delivered. DBB Operations may create the lower resolution file and store it in the DBB file storage system as a limited use alternate resolution master. In this case a workflow will be required to interrogate inventory, determine that the lower resolution file is present and chose an alternate workflow to copy and deliver the lower resolution file rather than transcode from a higher resolution file.

Example: For Spider-man 3, the 8MB MPEG2 file has been created and is stored in the file storage system. Within the required workflow, Tasks for the encode and ingest, retrieval and transcode of the of the Video Master file into the 8MM file would not be necessary because the 8MB, a limited use alternate resolution master already exists. In this case the workflow would be truncated. For Spider-man 4, the entire workflow, from Encode forward may be required as the alternate use file does not exist.

Depending upon detailed design it may be necessary to rerun the manufacturing plan for cost and lead time purposes prior to executing the actual Workflows. The reason for this is the dynamic nature of asset inventory. Manufacturing plans may result in the expenditure of hard funds for Partners and as a result may require approval prior to execution. A single request supporting a client launch may require multiple approvals. During the approval period, conditions could change within DBB. The ingest of a needed master file could have occurred or an existing master file could be placed on QC HOLD. As a result the initial analysis could result only in an estimate of cost and lead time which would be used for COFA purposes outside of the DBB (see White Paper C-13: Financial Processes). Once approved, the Manufacturing Analysis Engine would run a second analysis, check for substantive changes and if none exist, execute the manufacturing plan.

Cost Estimate – As described in White Paper C-05: Workflow Master Data and White Paper C-13: Financial Processes, the DBB will interface with a billing system that will store rate cards. Billing Transactions will leverage Rate card data in order to facilitate pricing computation. When a Manufacturing plan is created, variables needed for pricing computation are gathered based upon the results of the Materials Analysis and pricing is defined as determined by the identified Workflows. This information will be captured for use in the Approval Workflow.

Lead Time Estimates - Lead times for each process must be estimated and a total lead time for the Workflow must be developed. The method of computation is not yet known. True capacity planning may be beyond the initial scope of DBB. However, it is considered that the analysis of recent historic data could be used to estimate lead times.

Request Module Interaction – This information will be presented to the Requestor for approval. Lead time will be compared to due date to flag any


69

potential conflicts or need for higher prioritization. Costs will be made available and will allow the user to initiate the Approval Workflow.

Manufacturing Plan Modification and Release –The Manufacturing Plan will consist of Source Component requirements, Billing Transactions, Lead Time Estimates and required Workflow. It is necessary for the manufacturing plan to be examined by business rules that might flag it for manual review and release by a DBB operational group. This could be based upon the existence of certain tasks, or may be flagged at the Request level based upon special circumstances. Business rules for operational review of Manufacturing Plans must be flexible and configurable. This step is required so that the Plan may be modified by the DBB Operational group in order to account for unique or ambiguous circumstances.

Example – A given workflow may specify a particular source Component. However, with client approval, a different, lower quality source file is to be used. These alternate source files are present in the DBB. The Request is flagged for operational review and during this process; the source assets within the plan are modified. Once the modification is complete, the Plan is released for execution.

Modification to all aspects of the Manufacturing Plan by an operational group will be required.

3. User Interface

One or more UIs are necessary to support the review, modification and release of Manufacturing Plans prior to COFA approval. UIs will also be necessary to modify Billing Transactions before or after COFA approval. See White Paper C-13: Financial Processes for a full description of Billing Transaction requirements.

4. Services

For the initial release of DBB, it is not expected that exposed services around manufacturing planning will be required. However, later releases may need to support external queries for cost and lead time estimates for purposes of sales planning or basis customer support. In this scenario, Request level data may be submitted via web service. The Manufacturing Analysis Engine may then produce the necessary information and respond to the request. See White Paper C-13: Financial Processes, for possible services between the DBB and the listed Billing System options.


The Manufacturing Analysis process may require queries into supporting systems such as SPE’s GOLD and/or CineShare applications in order to determine inventory availability.


70

6. Multi-Tenant

The specific line between shared and segregated services will be determined in detailed design. However, it is highly likely that software and data processes such as Manufacturing Planning will exist in a single instance a version level. Level loading and prioritization of Tasks between Partners will be necessary in order to maintain consistent throughput. Operational segregation may or may not be required but will be discussed in detailed design.


71

Appendix C-07 Task Management 1. Overview

The Distribution Backbone will require the ability to orchestrate Workflows as defined by Workflow Master Data. Manufacturing Plans allow the assembly, operational modification/vetting, approval and submission of Workflows for execution. Once submitted, a Task Management function will interact with the Service Layer of the DBB, submitting Tasks, obtaining responses, updating, logging and notifying as necessary.

In the initial release of the DBB it is envisioned that all Tasks associated to processing and delivery of content are included. In addition, Workflows and their respective Tasks will also manage ingest of source Components into the DBB. Lastly, it is envisioned that the DBB will have visibility into key Components of physical inventory and that workflow management will extend a communication layer to manual mastering or asset research/retrieval activities. Within this broad scope it is assumed that any task could be configured to provide manual workflow instructions to a DBB provider or supplier. Technology and cost benefit analysis will determine the extent to which any process is automated. The key requirement is that the status of Tasks and their dependencies for all Workflows from key physical asset creation to delivery confirmation be visible within the DBB.

2. Description

A manufacturing plan is generated when an order is initiated in the DBB (see White Paper C-06: Manufacturing Planning). Upon an approved submission, the manufacturing plan will submit tasks to a Queue Management function. The processing of workflow tasks and their constitution is described below in functional groupings. The technical constitution of these functions may vary depending upon detailed design and implementation issues.

Workflow Tasks – As Discussed in White Paper C-06: Manufacturing Planning, a Manufacturing Plan consists of Workflows necessary in order to fulfill an approved Request. At any time, multiple workflows may be in process, many of which requiring similar tasks to be completed by the same DBB service. In or to manage queues, control priority and provide visibility to status a Workflow Tasks must be materialized within the DBB. Workflow Tasks will be added to the appropriate queues by a workflow orchestration tool. Data will be maintained within these tasks regarding status, order of processing, begin and


72

end time and operational information needed to define the nature of the task and its parent Workflow and Request.

Priority - Request level priority may be assigned in the Request Module based upon configurable user authority and/or Partner configuration. Request level priority may be changed during the Manufacturing Plan Modification stage described in White Paper C-06: Manufacturing Planning. Priority may be modified at the Title/Alpha level allowing users to prioritize one or more line items within a Request differently than others. Workflow task level priority may also be modified within the Task Queue Management function described below. Task dependencies will be set based within the governing Workflow.

Workflow Task Configuration – Workflow Tasks will manage the execution of various services present within DBB. While Workflows Tasks may be prioritized, the analysis of the order of execution of a Task will be performed at the service level so that all Tasks queued against a given service are processed in priority order. Task configuration will support monitoring thresholds that will allow Tasks Management functions to perform analysis and report on late tasks or tasks that from their start time have exceeded a set duration. Task categories are will include but not be limited to the following:

o Manual Task Management – A DBB Task UI will allow communication of manual tasks to DBB Partner/Supplier service providers. This web enabled UI will provide work queue information about tasks to be accomplished in support of DBB workflow. For example, this portal will provide file movement capability facilitating the delivery of assets for entry into the DBB. This task type will also facilitate non-financial review and approval workflow. It is assumed that email notification will be configurable to support these processes.

o Encode/Ingest Workflow Management – All Tasks necessary to support the entry of assets into DBB including Component Request Creation, Encode, Logging and Ingest as described in White Paper C-10: Ingest/Encode Management are required. Several of these tasks may be orchestrated through Manual Task Management described above.

o External Reference File Delivery and Conformed Component Retrieval – In order to support the external creation of conformed assets, audio or video Reference Files may be delivered to a supplier with an accompanying URL to be used for delivery. This is a suggested workflow assistance that will provide structure for the creation of conformed/synched components.

o External Web Service Integration – The DBB will support web service integration with external systems for numerous purposes. The primary purpose envisioned for the initial release is the retrieval of images, chapter stills, Title level metadata and other package requirements from CineShare, GOLD and GPMS for R1 and for other third party systems in later releases.


73

o File Management – Tasks will control the retrieval and movement of files to and from the DBB Storage System and support purge of files from WIP storage based on policy and workflow requirements.

o Content Processing – Interaction with all identified forms of content processing devices.

o Packaging – Generation of Package Metadata based upon customer specification and creation of Packages for delivery.

o Delivery – Delivery of Packages to Clients by identified methods.

Financial Update –Any Workflow may be configured to provide status and/or other needed data to facilitate financial processes (see White Paper C-13: Financial Processes).

Request Status – Workflows must provide task progress to Requests as configured in workflow business rules.

The following functions may be imbedded within the workflow orchestration tool but are required to manage the throughput of tasks through the DBB.

Queue Management – The Queue Management function monitors and maintains the throughput of the various queues within DBB and determines order of execution based upon priority and dependency. This function controls the rate/flow of Tasks through interaction with the DBB Service Layer.

Task Update – The DBB Service Layer will provide status for each Task. Upon receipt of status the Task Update function will update tasks to the appropriate status and provide logging and notification functions.

Task Monitor – This function monitors all Task management functions and queues, providing error reporting, processing time analytics and generally supporting queue processing integrity.

Task Management Operational UI – As a DBB administrator, management of workflows and their task that are both manual and automated will be required. Managing priorities and order of tasks will be one of the core functionalities administrators will use to keep the content supply chain running efficiently. Modifying queue priorities and canceling initiated workflows are Release 1 features for DBB administrators.

Notification – Email notification will be configurable at the Task level. These notifications will be driven by business rules based upon operational needs or by the needs of the Request (Requestor/Client notification).

Key Tasks – As described in White Paper 04: Workflow Master Data, Key Tasks are workflows that may be executed directly by operational personnel. These workflows will require a UI to allow directly entry of input parameters. As a Manufacturing Plan will not be in place, the UI will require the direct identification of source inventory for processing within the Key Task. Some


74

examples of key tasks are file retrieval, content processing, delivery and may include any content processing activity.

3. User Interface The Task Management Operational UI will provide sophisticated methods of review and analysis for operational personnel. Tasks may be configured with tolerance levels that, once exceeded, will trigger alerts and then will be reviewable to operations. The selection and review of tasks by various criteria such as task type, Workflow, content processing farm, Client, Partner or Request will be necessary in order to quickly identify and resolve problems.

Key Task UIs will rely upon the modularity of workflows and will provide direct access to input parameters. It is envisioned that these programs may work from a similar template as inventory search, identification and retrieval are common to most Key Tasks. Additional workflow UIs may be attached to this basic UI.

4. Services A Workflow Orchestration tool may be used to interact with the service layer of the DBB, submitting tasks, managing exceptions, logging, notifying etc. This tool will require a variety of services in order to execute the tasks types above.

5. Interfaced Systems The Reference Architecture will depict all planned interfaces for R1, but there are strong possibilities that Task Management will interface with CineShare for the retrieval of images, chapter stills and other non-rich media as well as to GPMS for Title level metadata. For Processes controlling financial transactions and for inventory visibility the DBB will likely interface with SPE’s Xytech implementation, GOLD.

6. Multi-Tenant The exact delineation of shared hardware and software has not yet been determined. However it is preferred that workflow and task management UIs and services will be a single instance and version, though clustered and have the ability to be distributed. This will allow the DBB to prioritize work for multiple Partners for separate content processing equipment sets in cases where equipment sets are dedicated to one Partner or shared among multiple Partners.

Workflow business rules must allow for different behavior based upon the Partner who initiated the Request.


75

Appendix C-08 Managed Multi-Tiered Storage Environment 1. Overview

The Distribution Backbone, hence forth referred to as DBB, will require the ability to manage and store large amounts of data on digital storage. Digital Files could be video, audio, images, text or any other media type that might be packaged for distribution to a DBB client. Given the current costs of storage and expected volume / size of files, a Storage System that includes a Managed Multi-Tiered Storage Environment (MMSE) is expected to be a requirement. It must provide a central point of storage which is more economical than a fully online solution as files can be stored on varying tiers/types of storage.

2. Description

As the DBB will have a digital repository of files, services related to file management will be required. One such service is the upload / ingest service (see White Paper C-10: Ingest/Encode Management). In order to populate the DBB with files, an upload process will need to occur to move the file from an external source to the localized instance of DBB storage. All files should be moved to the Tier 1 storage upon initial ingestion until such time an approved service request has been generated to move the file to WIP storage or a policy moves the file to other tiers within the MMSE.

Another service required of the DBB is the Work-In-Progress (WIP) retrieval process. In order to support content processing services, files residing on an MMSE will first need to be copied to a WIP storage area where they will have direct access to content processing servers (e.g. transcoding, packaging). The staging of this file to the DBB WIP storage should only be executed once a Work Order has been fully approved and a content servicing manufacturing plan task has been added to the queue for processing.

It is expected that the DBB be aware of each instance of a file regardless of which tier of storage it exists on. The DBB should be aware of what files are required in its production queue in order to reduce unnecessary tape activity (i.e. if a particular source file has been requested on order #12 and the same file has been requested on order #215 the purge policies should take that second order into account)

In order to maintain capacity within WIP storage, retention and purging policies will need to be setup. These purging policies will be unique to WIP storage and could be based on several key factors including the following:

• Timed Expiration – Once a file has been serviced and no pending approved manufacturing tasks require the use of this file, a timed purging event should be activated. This timed event could for example state that after 30 days of a file being untouched, the file should be purged.


76

• Work Order Status Types – The completion of a servicing event can be identified by a couple different work order types and can trigger analysis of retention policies (i.e. most likely trigger a timed expiration). A “Cancel” work order type indicates that the work will no longer continue and hence the file is no longer needed to complete the work. Secondly, a “Complete” work order status would indicate that all activities including delivery and receipt of digital content have been completed. It should be noted that other work order types may be identified to trigger a servicing completion and these should be configurable within the application.

• Pending Approved Servicing Task – At any point in time an approved manufacturing/servicing task requiring the use of an existing file residing on WIP storage could reset the timed expiration counter. This file would then remain on WIP storage without concern of being purged until the task is prioritized and executed against.

• File Metadata – Retention policies may be driven by metadata associated to a file. In this example, trailers or other media may have a longer retention policy than long form video. The use of this could be numerous but the expiration / retention policies should be able to leverage file metadata as a criteria. It should be noted that only components will most likely be able to leverage this feature as they will have necessary metadata.

The DBB is envisioning the use of a MMSE solution to provide a cost-effective scalable solution for storing its digital content. The Media and Entertainment industry works with large files, potentially exceeding 500 gigabytes per file depending on encoding/bit rates/run time. For this reason, cost and scalability


77

are of utmost importance. The DBB will require the use of standard MMSE functionality including the ability to move files between storage tiers (e.g. nearline online, offline online) as well as setting up scheduled file maintenance rules within the MMSE solution to help with capacity planning. The storage tiers envisioned for the DBB are:

• Tier 1a – Online – Fast spinning disk

• Tier 1b – Online – Slow spinning disk

• Tier 2 – Nearline – Tape library with automatable retrieval

• Tier 3 – Offline – Out of tape library with manual retrieval

Business rules should be created to manage content globally within the DBB. Rules will be setup to schedule movement of files between storage tiers based on file/component type. Each file/component type will be setup with an expiration duration for each tier of storage as well as a high watermark of disk utilization. In future releases, this functionality is expected to be extended via user interface for modification by Partner preference.

One area within Tier 1 of the Storage System should be dedicated to Work-In-Progress (WIP) storage and managed by the DBB. This WIP storage will be used by various content processing services like Transcoding. Though the equipment used for these services occasionally first moves the content to local storage before processing the data, the hope is to improve processing time by removing the need to move these large multi-gigabyte files between data stores. This will require a very fast connection between Tier 1 Storage and the content processing servers to be successful.

The MMSE will need to integrate with infrastructure management services to provide more proactive feedback regarding MMSE health. These services will also integrate with other DBB hardware (e.g. content processing servers) to help evaluate CPU, Bandwidth and other criteria to help the DBB better orchestrate its services and alert administrators of potential issues.

The MMSE solution should allow for a number of rules in regards to content stored on tape.

1. The ability to prevent assets from being spanned across multiple tapes unless absolutely necessary to store an asset (i.e. asset exceeds size of entire blank tape in pool).

2. The ability to segregate content types on tapes (i.e. choose to only have certain types of elements grouped on tapes thereby preventing the need to have extraneous tapes filling tape slots simply to access 1 small element.


78

3. The ability to have multiple copies of tapes for DR to take place at idle times and specific maintenance windows.

3. User Interface

Depending on the design, there may be little need for an end-user interface (release 1). There is an expectation that system administrators will be able to set default rules for managing media across the DBB environment. As these are controls only available to an administrator, this functionality does not have strict user interface guidelines and we expect to mostly use out-of-box functionality. There may be certain features however that are exposed via interface to DBB Partners. These would most likely be Partner preferences that interact with MMSE rules. For release 1 these features are expected to be very minimal.

Example: Depending on Partner preferences, certain content owners may require that all content remain on online storage rather than being moved to nearline or offline storage. Additionally certain “Hot Titles” may be required to stay online for longer periods of time than standard titles. By setting these preferences, the DBB should be able to interact with the MMSE to pass values/parameters which make these decisions possible.

Most file management activities should be seamless to an end-user of the DBB and not require a user interface. The movement of a file between tiers within the MMSE and movement to WIP storage should be conducted in an automated fashion. The only information a user should be made aware of is the expected processing time required for file preparation (e.g. movement to staging environment) and file servicing (e.g. transformation). One scenario where a user interface is expected is for upload/ingest of supporting media. It should also be noted that several mechanisms will exist for upload/ingest, FTP, Web-based upload and other delivery tools (e.g. Aspera, Signiant).

4. Services

There are certain MMSE features which should be exposed to the DBB as a service. The features expected to be exposed as a service are the following:

• Moving files between storage tiers

• Setting metadata-based expiration policies (overwriting default rules)

All file management activities should be managed via services exposed to the DBB. To handle the file management requirements discussed earlier in this white paper, the following services will need to be exposed:

• File upload service – This service should move a file from a Partner specified location to Tier 1 storage for the Partner specific tenant partition. An input to this service should specify if the file name should remain the same or abide by a file naming transformation expression.


79

• File retrieval to WIP service – This service should receive as input a file pointer specifying the file to be moved and the resulting destination location of the file. The destination location will be the tenant partition of the WIP storage.

• Manual Purging service – This service should receive as input a file pointer. In the case of a Partner manually initiating the request to purge their content, this service should purge all matching content residing on the MMSE after operations confirmation.

• Retention service – The MMSE will need to manage their storage with retention policies. Whether this is MMSE functionality or an exposed service, both storage environments will need to evaluate multiple criteria prior to triggering the moving/purging of content. These criteria, described earlier in this document, should be inputs to this service and include Work Order Status Types, File Metadata, existence of a Pending Approved Servicing Task, and Timed Expiration.


MMSE should be integrated via services to the DBB. These services will be integrated into the DBB to enable calls from systems including DBB DAM or system managing DBB manufacturing plan for example.

Depending on the design of the DBB, interfaces may not need to exist to support most File Management features. Though there are a large number of dependencies on metadata as retention criteria, this data should all be available within the DBB and an external interface is not expected to be required. Upload/ingest are the only features that would require system interfaces however these interfaces would be handled via digital delivery tools (e.g. SmartJog, Signiant) and mostly setup via configuration.

6. Multi-Tenant

The MMSE and overall storage solution must support both dedicated infrastructure for a partner, as well as a shared model under which DADC serves multiple tenants from a shared storage pool. Given the sensitive nature of the digital files being managed within the DBB, a multi-tenant architecture should be designed and setup to handle all potential file movements required for content servicing. The MMSE storage should be capable of being virtually and logically partitioned to prevent cross contamination and file management activities should always be cognizant of the appropriate partition being used.


80

7. Total Cost of Ownership & Operation

MMSE will be a core enabling foundation of the DBB. The MMSE must provide a Total Cost of Ownership and Operation that does not diminish the financial benefits targeted by the DBB. It must also be in line with the 3rd party business targeted by DADC.


81

Appendix C-09 Search 1. Overview

The Distribution Backbone, hence forth referred to as DBB, will require search functionality throughout its infrastructure. Search will need to be conducted on internal DBB data (e.g. Partner, Clients) and across interfaces to external data repositories which in Release 1 will be primarily limited to GOLD. However, future applications of Search will need to accommodate other interfaces including but not limited to DAM systems and Intellectual Property Management systems. The mechanisms which satisfy these requirements are not determined and solutions could be various.

2. Description

Search with regard to the DBB can be broken into two types; End-User-Driven Search and System-Driven Search.

End-User-Driven Search is what is commonly thought of when describing search features. End-Users will conduct searches across the DBB for many different reasons. The following is a list of expected End-User-Driven search features:

• Title/Alpha Search – Used by Partners to select the appropriate Title or Title/Alpha being requested. This will required an interface to the Partner’s Title/IP management system and will require multiple input criteria including but not limited to:

o Title (full textual wildcard search)

o Title Type (e.g. Feature, Episodic) – Controlled list of values

• Specification Search – Used by DBB administrators to find appropriate specification. Specifications will contain a great deal of detail where differences between specifications may be very minimal. The ability to quickly search and filter specifications to find the exact match is very important so the appropriate specifications are used.

• Component Search – Used by Partners to research components existing in the DBB. Components will contain numerous metadata fields uniquely describing each component. The component search mechanism should provide the ability to search across all metadata fields and filter results to uniquely identify the exact component match.

• Supporting Materials Search (not in Release 1) – Used by Partners to search for supporting materials added to the DBB. These supporting


82

materials will most likely have minimal metadata in comparison to Components. The level of metadata will most likely depend on how the document repository will manage this type of media. At minimum search should include any available metadata like filename or folder directory structure.

• Client Profile Search – Used by Partners to search for the appropriate profile for request. This functionality could be achieved via textual search or browse search where a Partner could navigate Client Profiles via hierarchy (e.g. Client > Client Profile)

• Client Search – Used by Partners to select a Client for fulfillment. This should be a simple textual search on Client names or browse feature to scroll through available Clients within the DBB.

• Request Search – Used by requestors to find in progress or submitted requests.

• Manufacturing Plan Search – Used by operators or requestors when Manufacturing Plans are being defined/created as well as post submission, which will occur at the Workflow and Task level (especially by status).

System-Driven Searches are conducted by the DBB to perform its built in features. The best example of this can be explained by looking at DBB manufacturing plan functionality.

Example: To generate a request, a Partner will specify a Title/Alpha and Client Profile for delivery. Given this input, the DBB will need to conduct searches across existing components, both file and physical, and follow numerous business rules. These searches will need to be configurable by system administrators and will be executed upon manufacturing plan estimation.

The following is a list of expected DBB system searches:

• Component Search – Queries conducted by DBB to find best matching component given a number of metadata criteria. Data provided by the DBB as inputs for search could be pulled from multiple sources but are generally driven by a Request or related information. Inputs include but are not limited to:

o Title ID – This is data selected by a Partner during the Request process

o Alpha – This is data selected by a Partner during the Request process


83

o Partner ID – This should be used as a filter to specifically search Components created by a specific Partner. Note: Components are not shared between Partners.

o Additional Spec Metadata – This is data specified in the Specification associate to a Client Profile. This information would be known as the Request would require the Partner to select a Client Profile. Sample specification information could include technical metadata like bit rate and format.

3. User Interface

Irrespective of design, certain search criteria inputs will require end-user entry. Search interface should require as minimal user interaction as possible. Depending on the UI screen, several design concepts should be possible to enable an effective UI. For all search types, the use of “wild cards” or partial matching should be available (e.g. “Spid” returns results for all results for “Spiderman”).

• Basic Search – Most common search interface, where one textbox is used to provide textual input, but searches across a number of predefined fields.

• Advanced Search – Searching across the data source(s) by designating search parameters for a number of metadata fields before execution to create more defined search criteria (e.g. date ranges, multi-select).

• Facet-based Search – Search option that provides additional relevant attribute capable of filtering result sets in a dynamic fashion. The count of retrieved results should be indicted next to each “facet.”

• Search Refinement – Ability to search within a returned result set add criteria in order to refine the results.

• Suggestions – Ability for fuzzy matching or logic. Characterized by “did you mean …?” type logic. Ideally, index based “look ahead” suggestions would be available.

• Result Navigation – Ability to traverse a Search result set by defined taxonomy/groupings

Search results should be returned in a set that can be reviewed in its entirety or via a pagination strategy. Additionally, should a result set exceed a threshold to be defined, the system will prompt the user to refine their search criteria.

Additionally, the speed/responsiveness of the Search services is critical to the usability and efficiency of the DBB.

4. Services


84

To enable search across internal and external systems, search services will need to be created and exposed to the DBB for each external/internal data source. The reason for exposing these search interfaces as services is because they’ll most likely be used in multiple scenarios for different purposes throughout the DBB. By creating common services, these will be more easily leveraged. For each data source, a service should be exposed to query each type of data. Additionally, it might be requires that indexes be created that span data sources and services in order to provide the necessary response times. Services should be extensible to provide querying and data retrieval of all available metadata for a particular data type (security permitting).

Example: If a service is created to query an external Intellectual Property Management system (e.g. GPMS for SPE), the input should be intelligent enough to provide multiple criteria for input (e.g. Title Name and Title Type). The service should also provide a means of specifying the metadata fields desired for output (e.g. Title, Year).


Several systems / sub-systems are expected to be queried to enable data sharing. Some of the systems identified are the following:

• Media Asset Management – The DBB internal Media Asset Management sub-system and its constituent services will need to be queried when conducting materials analysis for manufacturing plan estimation.

• GOLD/Asset Management – The DBB system will need to interface with the external existing asset management system, GOLD, for sources to retrieve asset metadata during the Manufacturing Planning.

• Work Order – The DBB system will need to store data related to work being conducted by the DBB in order to properly assign tasks and then interface data to facilitate the invoicing of Partners for work completed. In order to minimize double entry for Partners, the DBB is looking to receive work order line items/requests via system integration where possible.

6. Multi-Tenant

There are no specific multi-tenant requirements for Search outside of the need to be able to filter search results by Partner as a passed value.


85

Appendix C-10 Ingest / Encode Management 1. Overview

The Distribution Backbone (DBB) will manage the business process workflow for the Encode (or capture) and then Ingest of components. In this orchestration, starting with the request for the creation of new components in the Manufacturing Plan through their acceptance into the DBB, metadata will be inherited, captured, and verified via manual and automated processes to support the creation of clean data and thus unambiguous inventory.

Encoding, also referred to as capture, is a largely manual process of creating master files usually from a physical tape (description of Master File Definition in Appendix G), but can also be created from a file. SPE intends to outsource this manual function and it will be conducted outside of the system at external supplier facilities. However, it is important that this be a managed process such that status can be known about a particular, or set of, encodes. Additionally, as an external supplier would then enter the required metadata and transfer the file to trigger the next phase in the process, Ingest, a managed workflow would allow for that to be tracked as coordinated as well.

The Ingest process as defined within this document starts with the receipt of an Encoded component or set of components, likely within a wrapper. It is intended that outside of a rare exception flow, components cannot be Ingested into the DBB without a waiting Component Requirement that was created via a Manufacturing Plan (a Reactive process) or from a File Mastering request (in a Proactive creation process). From the receipt of file(s) step the received file(s) pass through a number of automated and manual steps to validate the integrity of the file, perform quality checks, execute a technical logging process, and then formally ingest the file(s) into the DBB storage system and update/create the necessary metadata in a pending Component Requirement.

2. Description

The following diagram outlines the Encode and Ingest Management process that should be orchestrated by the DBB.


86

Specification based Encode and Ingest controlled via requests and managed workflow is a key concept for DBB as it pertains to maintaining a well formed inventory with the necessary metadata and relationships to facilitate automation. A Component Type specification can be created and maintained by operations as defined by a Mastering/Assets Management group as a generic template and control for requesting the creation of and then receipt of incoming assets. A Component Requirement represents a request for a specific type of Component(s) against a Title/Alpha and creates a shell record to be received against, the Component Requirement. This allows rules to be put into place that ensure uniformity of inventory metadata.

Component Requirements will be created via requests in two primary ways:

• Reactively from Manufacturing Plans that will new Components to be encoded and then Ingested for use in pending orders, and

• Proactively based upon mastering plans that will result in the creation of components for new digital releases (Features and TV content)

It is currently planned that the supplier will perform a defined amount of content QC (exact details TBD) before they initiate the transfer of the file(s) as defined in the Master Specification to the DBB via an application interface extended to the supplier that will begin the Ingest process. A service, either running at the supplier or remotely, would also provide a method for the supplier to enter the required metadata about the Component(s) as well as to allow checksums to be calculated for the file(s) to be validated after transfer to ensure movement of the file(s) do not introduce corruption or truncation.

The Ingest process starts with the start receipt of the file(s) usually after the completion of an Encode. The Ingest process automatically verifies the checksum, including unwrapping the content if necessary (pending final definition of the delivery package specification from Encode suppliers).

After completion of checksum validation, the Component metadata and the file(s) are QC’d to ensure that the defined characteristics of the asset are within the tolerances of the Component Type Spec. To the extent possible it is desired that technical characteristics are automatically extracted from the file(s) and metadata is validated based upon what is achievable in an automated Technical and Content QC. A log of results from any automated QC process should be retained and stored in the system for future reference.

Once the integrity of the Component(s) are verified, a match is performed for the received file(s) to the waiting Component Requirement based on the metadata on the Component Requirement record in the system against the metadata that should accompany the file(s) from the supplier. This will be an assisted manual process whereby the association will only require confirmation in most cases, but it is also required that asset record may be manually matched to a Component Requirement in a list should multiple options be


87

systematically identified (usually as a result of bad incoming metadata) or, if no options are identified by the system, via search.

The next process will be to generate a high fidelity, frame accurate proxy to be used in the following steps. Using the proxy, there will be some amount of additional manual examination of the file(s), such as verification of audio tracks and aspect ratio, and its metadata before the final ingestion into DBB.

The next step will be the technical logging for the Component. This is currently only contemplated for video Components (and associated audio Components if they are in the same Ingest process) and is contemplated as a manual activity. The technical logging function will involve the capturing of Component segment identification (i.e. bars/tones, commercial blacks, logos, program) along with timecode information for each segment (in and out points) and cropping coordinates as necessary. Additionally, it is preferred that this technical logging process be conducted on the frame accurate proxy versus the actual essence file as the file sizes, especially for HD, will become unwieldy. Additionally, while this is planned as a manual task, it is also desired that some amount of indexing and auto-matching/identification of segments be suggested that could reduce the manual effort to a largely verification/tuning of the technical logging data.

Fingerprinting is a process that is then performed on the file(s) to create a unique signature for the file that can later be used to uniquely identify the Title/Alpha. This may or may not actually occur after the file is actually within the storage system of the DBB as that might be more efficient as Manufacturing Plans may be queued waiting for this asset..

The final step in the Ingest process includes a file integrity validation, comparing the originally captured checksums, and then the transfer of the file from the Ingest process location into the DBB storage system for management. A final confirmation of the Component Requirement data and the incoming metadata accompanying the Component file(s) will be performed and may be validated by an operator. Additionally, within the system the Component Requirement would be updated a fulfilled status and provide that visibility throughout the system.

There are some variations to this process in the cases where audio only or closed caption (CC) components are being put through the Ingest managed process vs. when conformed video and audio components are being ingested together. As before, they are the results of requests and come out of a managed Encode process. The major difference in this flow is that to ensure that these components will conform to the video asset it is intended to be associated to it will need to be confirmed against a reference copy of the audio. This can happen on the server side via a specific proxy created for the verification of conformance for audio and/or CC. Alternately, this can be performed locally, though locally is less preferred due to the requirement of moving the reference video from the DBB to the workstation.


88

Once the audio only or CC component is Ingested into the storage system it is also required for this type of asset for it to be associated to single or multiple Kits. This process is assumed to be manual and would either be done ahead of time as part of an Inventory Control function using the Component Requirement or after Ingest when the Component Requirement is fulfilled.

Finally, there will need to be specific “Replacement” variants of these workflows to allow for the necessary business and system logic for assets that are already in the system, but are being replaced due to rejection or remastering efforts.

3. User Interface

A user interface (UI) will need to be accessible to both Encoding and Ingest operators that can be different suppliers that may or may not including internal. Thus, it is required that while being rich and interactive, the interface should be securely presented to its external users and also be intuitive as it can be assumed that external supplier training will vary. Different suppliers using this UI should not have visibility to files being acted upon by others. Additionally, a service as mentioned above, preferably with a UI, would be required to assist Encode suppliers with initial Component pre-transfer prep such as metadata entry and checksum calculation.

Also, to meet the Kit creation/update requirement noted above, a UI is needed to associated fulfilled Components and Component Requirements for audio only and CC assets to Kits.

4. Services There are a number of Services that will be required to support the Encode and Ingest workflows. At the most basic, as these processes will be managed workflows, the Workflow Orchestration services should be utilized to facilities the tasks within this process and capture business process metrics. Encode Services themselves are not directly considered part of the DBB and are expected to be third party tools leveraged by supplier to create the Component file(s) as defined in the Master File Definition. However, an Encode pre-transfer service/application is required to allow the supplier to create a checksum before moving the files into the Ingest process to ensure file integrity.

Within the Ingest process, there will need to be several services some of which will be centralized and others which may need to run locally. These Services include the File Movement Checksum, Fingerprinting, Automated Technical and Content QC, Content Processing (as necessary), Metadata Validation, and Technical Logging.

At the end of the Ingest process, the File Management, Storage Management, and Metadata Management Services are called to put the file(s) under management of the DBB within its storage system as well as its corresponding metadata.


89

The Kit association function would primarily leverage the Metadata Management Services.

5. Interfaced Systems There are no direct interfaced systems required for this functionality. However, as it is intended that the inventory in the DBB be reflected in GOLD, metadata for the incoming Components needs to be synced/updated into that system. Additionally, it would be ideal that the components/toolsets used in this process that are not directly part of the DBB be interfaced to more tightly integrate the overall system and any remote data and interactions.

6. Multi-Tenant There are no specific multi-tenant requirements other then the system must be able to support content being encoded and ingested from multiple locations and be able to identify (via metadata) to which Partner the content belongs. It should also be assumed that future Partners, other then SPE, will have different Encode and Ingest managed workflows.


90

Appendix C-11 Package Metadata 1. Overview

This document describes the processes and functionality required to assemble the various types of metadata required for delivery as part of a package.

2. Description

The diagram below is a sample entity relationship diagram depicting the relationship between a client profile, its associated metadata specification and the supporting data required to assemble the package metadata according to that specification. The purpose of this diagram is not meant to define the final design but meant to help describe the types of relationships expected to satisfy SPE future state process maps.

Specifications / Configurations Supporting Data

OtherData

Title MasterData

RequestData

TechnicalData

PackageManifest

Client Profile

Product Specification

Metadata Specification

Package Configuration

Delivery Configuration

Image Specification

Assembly Configuration


91

Client Profile – The Client Profile acts as the source of reconciliation throughout the entire DBB manufacturing process to ensure what is being created matches client requirements.

Metadata Specification – Defines the metadata requirements for a particular client profile. The metadata specification indicates what metadata is required, where each data element is located, how it is mapped to the DBB metadata canonical and what, if any, transformations are required in order to provide the metadata in the client’s preferred format.

Supporting Data – Supporting data constitutes all of the data that is required to be delivered as part of a package. This data can be found in various DBB data stores, i.e. Request, Title/Master and File Repository and must be mapped to the Metadata Specification. In the event that additional data outside of the DBB is required, it will be provided as supporting material to each request via an interface (user facing or system-to-system).

Title Master Data – A Title is the master data describing the intellectual property which is maintained within the DBB as the highest level of organization for its content that allows it be searched on, retrieved and manufactured against in order to fulfill a Request. Examples include title, synopsis, talent, genre, rating and copyright line.

Request Data – Request data contains information specific to the deal terms that were used to generate the request. Examples include sales start date, sales end date and price.

Technical Data – Defines metadata specific to the assets and/or files included in the package such and contains elements such as asset type, file name, file size and checksum.

Package Manifest – Defines the contents of the package. This could include a listing of all of the assets provided for each title.

Other Data – Various clients may have additional metadata requirements that we have not discussed such as chaptering metadata. For this reason, metadata specifications need to be completely flexible allowing the addition or removal of data to support client needs.

Metadata Canonical

The Digital Backbone will require a metadata canonical which removes variability and imposes a strict lexicon to ensure a common metadata language is spoken both at the field and value level. Partner metadata specifications will be mapped against this canonical to provide a consistent reference point which will ultimately facilitate mapping to the individual client metadata specifications. The metadata canonical must support multiple languages and other regional specific data formats (e.g. date, currency, etc…).


92

Metadata Mapping

Each source DBB metadata attribute and its associated values of the Partner metadata specification must be mapped to the metadata canonical. Similarly, each client metadata specification should be mapped to the DBB metadata canonical. This provides the efficiency of only having to map a client once as opposed to once per each partner that distributes content to it. It also adds a layer of abstraction protecting the mapping from data model changes over time.

Metadata Transformation

Each client may have specific requirements surrounding how a particular data element is provided. This could be as simple as a particular date format or more complex such as specific translation rules. For instance, a client may have their own genres to categorize content. In this case, the genre value will have to be translated from the DBB genre. These transformation rules must be easy to manage and should be implemented with limited to no technical development if possible.

Metadata Versioning

Changes to metadata must be audited and historical data must be maintained. It is important to know what metadata was sent to a client as part of a package. Often times, a client will reject a package due to “bad” metadata. It is necessary to understand exactly what was sent to ensure the same “bad” metadata isn’t resent. Conversely, it may be required to resend exactly what was originally sent even though data could have subsequently changed. Since packages are not maintained indefinitely, reconstructing the metadata that was sent should be a function of finding all metadata which was originally sent to the client. Some clients, depending on their client profile, may require most current metadata to be sent.

3. User Interface

A user interface must exist to manage the mapping of Partner specific metadata elements within the DBB to the metadata canonical. Similarly, a method must exist to map client specific package metadata elements to the canonical. Additionally, there must a user interface that allows metadata that exists only within the DBB to be added or edited.

4. Services

For the initial release of DBB, we do not expect that exposed services for package metadata will be required.


93


The DBB will maintain its own data stores for the type of data that will be included in package metadata. Nevertheless, the DBB may need to interface with additional systems to provide package metadata (e.g. GPMS).

6. Multi-Tenant Requirements

Future partners may have specific package metadata requirements that will impact Metadata Canonical, Metadata Mapping and Metadata Transformation.


94

Appendix C-12 Package Creation / Management 1. Overview

This document describes the processes and functionality required to create and maintain packages. A Package represents the compilation of one or more products created to client specification along with any additional materials required per the agreement between Partner and Client.

2. Description

The diagram below is a sample entity relationship diagram depicting how Packages are expected to relate with Client Profiles and Specifications. The entities in blue are defined in other whitepapers while those in teal will be introduced in this document. The purpose of this diagram is not meant to define the final design but meant to help describe the types of relationships expected to satisfy SPE future state process maps.


95

Client Profile – Defines a set of client-specific deliverable requirements and supports automated workflows for delivery, status tracking, billing, and product/package creation. Includes configs, specs (per title type), and profile-level metadata.

Package – Defines the compilation of one or more products plus any additional materials or content required per the agreement between Partner and Client that will ultimately be delivered as a part of the Request fulfillment.

Package Specification – Defines the content, or Package Elements, required for a package to be considered complete. Package specifications will vary based on two primary criteria: the type of product being delivered and the client to whom it is being delivered. For instance, a package specification for a feature may be different than that for a television episode. Similarly, a feature package specification for iTunes may be different than that for a broadcast client.

Package Element – Defines a discrete piece of content required to be part of a client package. Each package element will have its own specification based on its type of content or Element Type. For example, a Metadata package element would have a Metadata Specification, a Packshot would have an Image Specification.

Element Type – Defines the type of element, i.e. Trailer, Chapter Still, Packshot, Metadata, Music Video, etc.

The Package Creation process can logically be divided into three sub-processes as described below.

Content Gathering represents the activities which are responsible for identifying and/or localizing all of the required package elements within a request.

Package Assembly ensures that all required package elements have been gathered, performs any processing required to conform the package elements to client specification (i.e. transcoding, watermarking, XML transformation, DRM, etc.) and organizes the package elements according to the package specification.


96

Package Maintenance represents the processes that control the package after it is created.

Each of these sub-processes is further described below.

Content Gathering

Content Gathering represents the activities which are responsible for identifying and/or localizing all of the required package elements for the products within a request. Package Specifications are envisioned as the mechanism to inform the Content Gathering process as to what needs to be gathered. A package specification will need to contain the following information:

1. Which package elements need to be included, i.e. trailer, images, metadata, etc.

2. How many of each package element are required, i.e. 2 trailers, 4 images, 1 metadata

3. Where each of the package elements can be found and what criteria is used to find it (file system location, DAM search criteria, web service call, etc.)

4. The client naming convention of each package element

5. The organizational scheme of the package elements (i.e. loose files, zipped by product, specific directory structure, etc.)

Content Gathering begins by determining whether or not package elements are available for a given Request. DBB should surface the status of each package element within the Request UI enabling the appropriate user(s) to see what still needs to be gathered to fulfill a Request.

Where DBB actually looks to gather package elements will be a design decision. One option could be a Request based WIP area where all content required for a Request is staged. Another option would be to store all required content in a DAM. This would require a standard metadata canonical to enable DBB to locate content based on a combination of Request and Package Template attributes such as Request Title, Request Territory and Package Template Content Type (i.e. Title = Quantum of Solace, Territory = US and Content Type = Packshot). It is our intent for the process to be as automated as possible with the minimal number of content movements. Considering this,


97

the DAM solution has inherent advantages in that content can be ingested once and reused for multiple requests, whereas, a manually populated WIP area will need to be re-populated for each Request that is processed.

As specified above, file naming conventions will also need to be automatically generated in certain cases within the DBB in order to satisfy Client delivery requirements. These file naming conventions vary between Distribution Clients and are generally composed of a series of abbreviated and concatenated metadata values describing the asset. Naming conventions should be specific to a particular Client but also configurable to a Partners needs. In order to define a file naming convention, a DBB user should be able to select a series of metadata fields (e.g. Title, Aspect Ratio), fixed strings (e.g. “_” “-“), or other defined variables (e.g. current date, current time). The text resulting from the metadata inputs can be modified based on a number of different criteria specified by the DBB user. Each of these criteria can be used individually or combined in series (e.g. remove vowels then crop to max length of 10 char). The following criteria can also be applied to a specific metadata input or the entire expression:

• Crop to length – (e.g. crop the Title field to 10 char. “Transformers” would be “Transforme”)

• Remove vowels – (e.g. remove vowels from Title field. “Transformers” would become “Trnsfrmrs”)

• Lower/Upper case – (e.g. Title field upper case. “Transformers” would become “TRANSFORMERS”)

• Remove special characters – (e.g. remove colon from Title. “Stargate: Infinity” would become “Stargate Infinity”)

Given the flexibility required for this data manipulation, complex manipulations may be best handled using a Regular Expression (e.g. RegEx) processor.

Content Gathering is completed when all required package elements have been identified and/or staged. However, some level of operational control must be maintained to enable a package to be created, and hence, a request to be fulfilled, even when certain package elements are not available. This implies that an authorized operator requires the ability to begin the Package Assembly process even if the Content Gathering process has not completed. Some of these requirements may be fulfilled by business rules which indicate which package elements are truly required for delivery. At the highest level, an operator must be able to send ‘as-is’ regardless of what the package specification dictates.


98

Package Assembly

Package Assembly can begin once package elements have been gathered. Its purpose is to prepare and organize the content as described in the package specification. Each package element will have its own specification. For example, a trailer may need to be delivered in a specific format, aspect ratio and bit-rate; metadata may need to be transformed into a client specific format. DBB is expected to leverage the appropriate specifications in order to know what transformations need to be applied. In assembling the package, DBB will perform some combination of the following based on the package specification and package element specifications:

1. Determine whether and at what level (package or package element) encryption is required and apply where necessary.

2. Transform images, supporting video elements (i.e. trailer, music video, etc.) and metadata

3. Apply forensic watermarking if required

4. Apply DRM to products if required

5. Apply client specific naming conventions to package elements if required

6. Organize package elements into directory structure

7. Combine or wrap the package elements, i.e. Zip, stuffit, MXF

Package Assembly is completed when all required package elements have been processed to their appropriate specification. However, some level of operational control must be maintained to enable a package to be created, and hence, a request to be fulfilled, even when certain package elements have not been gathered and/or assembled.


99

Package Maintenance

Package Maintenance consists of the following processes which are required to manage the package post-assembly:

1. Package Staging for QC Package Staging for QC entails moving the package to a QC location and notifying the appropriate party that a package is ready for QC

2. Package Staging for Delivery Moves the assembled and, when necessary, QC’d package to a delivery staging location

3. Package Retention Enforces the purge/retention policies for packages. These policies may be client or partner specific.

4. Package Management Enables administrators to manually access or purge packages.

3. User Interface

A user interface must exist to manage all aspects of package specifications from element type creation through assembling package specifications. The creation, review and publishing of package specifications are envisioned to be part of the overall onboarding process.

Additionally, the Request and/or Admin/Partner portal should surface the status of each package element within a particular request enabling authorized users to see what stills needs to be gathered to allow Request fulfillment to proceed.

Finally, Package creation could potentially send notifications to parties responsible for providing package elements and performing package QC.

4. Services

For the initial release of DBB, it is not expected that exposed services for package creation will be required.



100

DBB will need to interface with the DAM or file system that houses the package elements required for the packages.

6. Multi-Tenant

DBB may have to interface with partner DAM systems in order to gather necessary package elements. However, another option would be to provide a Partner portal which allowed direct ingestion of package elements into DBB.


101

Appendix C-13 Financial Processes 1. Overview

The Distribution Backbone (DBB) will require interaction with the financial systems of SPE and of Partners in order to provide cost estimates, facilitate financial approval, execute billing or cost transfer processes and to facilitate reconciliation of financial transactions where necessary.

The DBB model of financial processes must support the business relationship with SPE, an intercompany model, as well as a Partner model, a more traditional customer/supplier model. The self service concepts discussed in White Paper C-03: Request Management may apply to both the intercompany and third party models as will be described. However, it is also considered necessary to include requirements for a DBB customer service layer to which Partners may provide traditional POs. This customer service layer would then interact with the DBB through the Request Module as described in the self service model.

All DBB financial models will allow for interfaces to either SPE or Partner financial systems in order to leverage upon the core functionality of these systems and to eliminate core financial requirements from the DBB proper wherever possible. The separation of the DBB as a content management and distribution platform from the requirements of GAAP or SOX governed financial systems is desirable.

Specific architecture options involving GOLD, Xytech MediaPulse and DADC’s COM system are outlined in the System Architecture options below. This includes delineation of interface and implementation aspects of DBB.

2. Description

The following diagram describes a high level financial flow between the DADC, host of the DBB, and SPE, the first Partner. This diagram presents a view of the intercompany model. The modifications of this model needed to support a Partner are discussed throughout this white paper.


102

Request & Financial Transaction Processing

SPEDADC

Request UI Requestor

Materials Analysis(incl. estimate)

Manufacturing Plan

Execute Manfacturing Plan

Execution Complete

Create GOLD PO via system interface

COFA Approval

Invoice Matching via GOLD

Billing InvoiceSubmit transaction to SAP via existing

GOLD interface

SPE/DADC reconciliation

process

Assumption: Xytech used to

store Billing Transactions

related to a manufacturing

plan for DBB to facilitate PO

creation within GOLD.

SPE/DADC Reconciliation

process

Financial Integration Concepts


103

The following sections document the functional components of the DBB financial flow. There are multiple options available to some of these components. These options are discussed at the end of the section.

Rate Card – As discussed in White Paper C-06: Manufacturing Planning and elaborated upon in White Paper C-05: Workflow Master Data and White Paper C-07: Task Management, it is assumed that the DBB will either possess the capability to support a rate card within its architecture or will interface with a system that supports a rate card. This rate card must allow for various pricing scenarios common to content processing commerce. These scenarios must include but are not limited to the following:

a. Rate Card by Partner – The rate card must be configurable to provide unique pricing by partner, whether that partner be SPE or a third party. The rate card must support copy and modification of partner pricing and the application of rate changes by overall percentages or by individual price changes. Grouping and modification of large numbers of service prices is required.

b. Project Pricing - This pricing will override a Partner’s rate card when a specific deal is negotiated.

c. Pricing Types – The following pricing types must be supported.

a. Quantity Pricing – Includes the application of discounts for greater quantity.

b. Flat Fee Pricing – Includes services for which quantity or units are not considered in the computation of the price.

c. Minimum Quantity Pricing – A flat fee is charged until a minimum quantity is reached, then quantity or standard unit pricing is used.

d. Pricing Variables – The following variables must be used in Rate Card Mapping.

a. Quantity – Number of items created, e.g. five Mpeg2 files.

b. Units – Number of units that may or may not be multiplied by the quantity, e.g. 10 deliveries of 5 Mpeg2 files. Also used for any generic unit based service.

c. Run Time – The run time of content.

d. Source and Output Type – Type of source file, e.g. HD vs. SD source, output transcode format.

e. Order Type – Service level required and transaction type for the order, e.g. rush orders, non-billable.

f. Service Type – Type of service(s) executed for the request, e.g. transcode, 3:2 pull-down, etc…

g. Bit Rate – The Bit Rate of content.


104

h. File Size – The file size of content processed.

Billing Transactions – Through mapping between DBB Tasks and the rate card, Billing Transactions will be generated by DBB. These Transactions may be generated by the Manufacturing Plan in an automated fashion or through Modification of the Manufacturing Plan as described in White Paper C-06: Manufacturing Planning, and White Paper C-05: Workflow Master Data. In any event, the billing transactions will contain the cost estimate component of the Manufacturing Plan and later, will support invoicing or cost transfer processes.

Manufacturing Plan PO Interface – Within the SPE model the Manufacturing Plan, once approved by the Requestor in the DBB, will generate Billing Transactions supported by required financial data. It will then export this information to the WPF fulfillment system, GOLD. This interface will result in the creation of a Media Purchase Order in GOLD. Supporting information such as the SPE Title/Alpha ID is required, other financial information may be included in the Request Module design (e.g. Territory, Market) and will also be provided in the interface. In order to support Partner requirements, this interface will support standardized schema and web service functionality that may be configured and redeployed to multiple partners. Manufacturing instructions and Source Assets may be included in the interface for information purposes only. The GOLD PO (or Partner PO) created by the DBB is intended as a billing vehicle only and not as an instruction to perform work. Reporting the details of the distribution process will be a requirement of the DBB and not of the Partner PO system. Referential detail will be required in both systems.

Once the Manufacturing Plan is created and interface messages sent, the plan will remain on hold until approved through the interface. COFA approval of the Manufacturing Plan costs will be executed in GOLD (or Partner PO System). Once approved, a message will be sent back to the DBB releasing the Manufacturing Plan.

R1 requirements include the interface to GOLD and extensibility to third party PO systems. The design and build of a third party PO interface is not in scope for R1.

Manufacturing Execution and Cost Transfer Interface – Once COFA approval is received through the interface, the manufacturing plan will be executed. Substantive changes to the Manufacturing Plan that may be encountered during execution may result in a subsequent iteration of the interfaced PO. A revision may be sent and approved in order to support the billing process. When work has been completed, the DBB will send a message to GOLD executing the cost transfer function. This function will mirror the current manual process in the GOLD system by which an invoice record is created, approved and posted for export to SAP. Due to the inter-company nature of the transactions and the assurance by the interface that DBB Billing Transactions are equal to GOLD PO transactions, this process may be fully automated. The automation of this process is within the scope of R1, but it is


105

assumed that the current GOLD Interface to SAP will be leveraged and a new interface to SAP is not required.

DADC Accounts Receivable – Regardless of the options selected for the Partner model, it is assumed that Billing Transactions within the DBB will be interfaced to the DADC Financial system, COM, for accounts receivable and general ledger purposes. In the SPE model these A/R transactions will be used to support reconciliation of cost transfers between SPE and DADC. In a Partner model, COM will provide standard invoicing and accounts receivable functions.

Financial Model Variables

Variables that may exist between the SPE Model and a Partner Model include but are not limited to the following:

Manufacturing Plan PO Interfacing – The interface of manufacturing estimates to Partners is an option but not a requirement of this model. As discussed briefly above, Partners may or may not directly use the Request Module. If they do not, they will deal with DADC Customer Service representatives who will interact directly with the DBB Request Module on behalf of the Partner. In this case, the need for a traditional Partner PO, prior to the execution of work may be required. This will be a more traditional customer/supplier interaction. While this process does not directly affect R1 requirements, the use case must be considered.

Billing/Cost Transfer – For a Partner the Manufacturing Execution and Cost Transfer Interface as described in the SPE model above will not be possible without a focused integration project that is not in scope for R1. It is assumed traditional invoice processing will be conducted by the DADC from the COM system. All internal interactions between Rate Card, Billing Transactions and COM A/R may remain as described.

System Architecture Options

Rate Card and Billing Transactions - Current options include the integration of a Xytech MediaPulse implementation that would stand alone within the DADC infrastructure. In this option, the rich rate card and billing functionality in the Xytech product would be leveraged to process financial transactions and to interface with GOLD on the SPE side and COM on the DADC side as described above.

A second option is that the Rate Card and Billing Transactions could also be maintained within the COM system. This would require COM to support all pricing related concepts and to interface with GOLD as described above.

The option of supporting the Rate Card in COM and the Billing Transactions in MediaPulse does not appear to be practical.If used purely for financial purposes, these systems would be considered support systems and DBB project requirements would be based upon the interfaces needed to support the


106

financial model. Integration to these systems would be in scope for R1. This specifically excludes the implementation of a MediaPulse instance as a billing system only.

A third option is that Xytech MediaPulse would be used in core DBB content processing functions such as the Request Module, Manufacturing Planning, Task Management and Inventory Management. Should MediaPulse be presented as a solution in these areas, the Rate Card and Billing Transaction functions would be in scope due to their tight integration within the MediaPulse architecture.

3. User Interface The ability to modify billing transactions at any point in the process flow is required. This interface is also covered in White Paper C-06: Manufacturing Planning regarding the modification of a plan. It is stated specifically for clarity that operational personnel must be able to review and modify billing transactions prior to the finalization of a manufacturing plan or prior to any iteration of the Manufacturing Plan PO interface or for Partners, before invoicing.

4. Services Depending upon final design, specifically regarding any use of Xytech MediaPulse, the DBB will require a service for the interface of Billing Transaction data. This service must access rate card information, apply mapping to estimated tasks and create resulting billing transactions. This service must be executable within the DBB purely for estimating purposes if necessary and not only to support distribution.

5. Interfaced Systems Depending upon the resolution of system architecture options, a DBB interface to the GOLD system will be required to support COFA Approval and Cost Transfer activities described above. Whether MediaPulse is included as part of the DBB for operational purposes affects the nature of the interface to the DADC COM system. This interface may include the full scope of Rate Card, Billing Transactions, COFA Approval and Cost Transfer, or may simply require Billing Transactions to be interfaced from MediaPulse.

6. Multi-Tenant Partner issues as they pertain to variations in the financial flow are addressed throughout the white paper. In all areas where financial data is gathered or processed that the owning Partner be defined and that this Partner designation will allow the application of variable processing described herein.


107

Appendix D – Supporting and Additional Requirements

The Requirements document is supplemental to the process flows and white papers. The document provides a summary of key specific requirements and clarifications for the DBB project. The list is not exhaustive and additional requirements may be understood or interpreted from any of the RFP documents. Unless otherwise noted, the requirements may also refer to potential requirements that may be implemented in later releases.

Partner/Client Management Partner/Client Relationship, Master, Profiles

Partner integration set up includes: physical segregation requirements, ability to set up partners of different sizes and capability levels, i.e. large clients requiring dedicated infrastructure as well as small to medium clients.

Creation of partner profile link to billing account. Need ability to support multiple partner structures. (Master company ‐ sub‐company ‐ multi‐biz units etc)

Ability to activate partner account with User Admin settings and Access Control.

Ability to suspend partner accounts. All requests/orders and related activities (e.g. content processing) associated to that partner should be automatically placed on hold. Ability to resume partners that are in suspension.

Ability to trigger initial or additional provisioning of resources within the system (e.g. asset repositories, metadata, storage, other dedicated hardware, etc…).This may be handled as a manual ad‐hoc process for the first partners.

Partners can create multiple user accounts within the DBB.

Each user needs to be sponsored by a Partner.

Multiple clients can be associated to a Partner.

A Partner will have the ability to distribute content to multiple clients via the DBB.

Client specifications will be maintained in a client profile for that client.

Client Master Client/Partner relationships will be established via a client master record.

Ability to enter client master data into the DBB, e.g. client name, contact information, etc.

Ability to manage (i.e. statuses, add/delete records) client master data within the DBB.

Ability for duplicate client master data (for all criteria) to be identified and flagged within the DBB.

Client Profiles Ability to create and manage (i.e. statuses, approvals, version history)

client profiles within the DBB. A client must exist for the client profile that is being set‐up within the

DBB.


108

Ability to associate multiple client profiles to a client per Partner. Ability to capture client profile specific client metadata (which may be the

same or different than the client master data), title types, specification, and variable information for any client profile.

Ability to change state of client profile (e.g. "In Maintenance"). Some Client Profile updates that result in a new Client Profile must go

through on‐boarding process as per business rules. Ability to prevent duplicate client profiles from being created (where all

information is exactly the same). Ability to test client profiles prior to publishing them for use. Client Profiles can be used to differentiate clients across different LOBs,

territories, etc. per Partner. One or more client profiles may be associated to a client master. Each

client may have a single client master per Partner. Therefore, client profiles do not cross multiple Partners.

Ability to copy client profile to create a new client profile. The DBB may have the ability to provide a default set of specifications and

associated workflows based off of client/client profile/title type (e.g. Feature, Episodic, Trailer)/component source metadata.

Ability to override any default set of specifications and associated workflows chosen.

Ability to maintain client profile version history within the client profile. Specification and Configuration Association

Ability to create and manage (i.e. statuses, approvals, version history) specifications and configurations within the DBB.

Specifications will exist separately from client profiles. Specifications can be associated to client profiles. Configurations will be specific to a client profile. Ability to associate multiple specifications and their associated variables

to each title type within a client profile. Ability to associate multiple title types within a client profile. A client's complete specification may include one or more of the following

for: trailers, images, metadata, products and other. Ability to auto filter to view all available specifications based off client,

client profile, title type and/or detailed specification attributes during request and/or manufacturing processes.

Ability to manually override the default specifications selections during request and/or manufacturing processes.

Specification versions need to be maintained for the ability to research and recreate specifications used in the past.

Ability to copy an existing spec to create a new spec. Administration

All Partner/Client master data, including but not limited to partner, client, client profile, specification, and variables, should be managed within the DBB.

Ability to specify the customer's security profile, e.g. support for secure transport such as SFTP, public key data, requirement for encrypting files, hard drive encryption requirement, etc.

Ability to define and enforce system policies and rules that protect the assets, including integration into DBB security, user management and access control functionality.

On‐Boarding Process


109

Workflow Ability to onboard any client as soon as specifications and variables are

approved for that client's client profile. On boarding scope includes testing the entire DBB manufacturing

process. Ability to use DBB inventory or test data for client profile testing

purposes. Request Maintenance Ability to track changes requested on an existing request Ability to track cancellations for in‐flight orders Completion of servicing and delivery of all line items within a request

should trigger a 'closed' status. System should allow manual intervention to close an order line item that has not been fulfilled for users with special permissions.

Ability to submit and manage (i.e. statuses, approvals, version history) requests within the DBB.

A client and client profile must exist from which to choose within a request.

A request must have the following data associated to it prior to being submitted to on boarding or materials analysis; data includes but is not limited to: 1) client, 2) client profile, 3) request type, 4) title, 5) alpha and 6) due date with ability override the due date for each line item.

The request module will need to have access to client master, client profile, title/alpha master data stores.

Ability to check and provide feedback for duplicate requests for the same title/alpha combination for the same client using the same client profile.

Each discrete title/alpha line item within a request will default to representing 1 package, unless otherwise noted by business rules for that client profile.

If there are multiple clients and multiple titles on the same request, then all titles go to each client.

'Request Types' may be used to influence downstream DBB behaviors, which includes the ability to override existing workflows.

In R1, the DBB request module will not be integrated with any LOB sales systems.

Ability to copy and then modify an existing request within the DBB for easy and repeatable ordering.

The request module will be able to assign priorities for the manufacturing and delivery queues, which can be modified.

UI, Templates, Data Assist Requests will be created, modified, and cancelled using a UI. Request search and summary display functions will be made available

through the UI. A UI will manage all business information needed for DBB fulfillment. Templates and Importing Ability to import title/alpha and/or client lists.

Status Monitoring The request UI will manage request statuses. Inventory Management Ability to logically partition the repository for Partners.


110

System displays the partner's appropriate inventory of content at the title/alpha against which requests will be placed.

Ability to pre‐create asset placeholders prior to asset upload (via API or Partner portal)

Ability to access the proxies created for the assets. The proxies should provide immediate access to the content of the assets, commonly in a lower resolution format. There may be a requirement for certain proxies to be frame accurate for video assets.

Inventory Metadata Organization The DBB will need to manage metadata for various components in ways

that may facilitate the automation of component selection. Title/Alpha

Title/alphas will be used as a way to track unique video and audio cuts for each title.

Partner title/alphas can also be created directly via the DBB UI. The DBB will also maintain its own store of title/alphas, as needed.

Title/Alpha Interface Ability to synchronize with GPMS to obtain SPE feature and episodic (and

possibly trailers) title/alpha data. Ability to synchronize with external DADC Partner title/alpha repositories. A UI will be used to manage alphas and their relationships to titles, as well

as associations to territory or other business information. A UI will be used to manage component type information, e.g.

specifications, that will facilitate linkage, kit creation, workflow associations, etc.

Component Types and Requirements Ability to create and manage (i.e. statuses, approvals, version history)

component types within the DBB. Ability for component requirements to be visible for ingest. Maintain a 1:1 relationship between component requirements and its

intended asset. Ability to link a component requirement with its intended asset using, at a

minimum, component type and title/alpha as the association. Ability to facilitate validation that a component requirement is fulfilled by

the correct asset (may require manual validation) Components (include succession rules)

Ability to store components (including all audio and video materials, such as cards, logos, cc files) in a component repository within the DBB.

Ability to create and manage (i.e. statuses, approvals, version history) components within the DBB.

Business rules will help drive succession capabilities within the DBB should a component be ready to be ingested into the DBB in order to replace an existing component.

Ability to flag duplicate component requirements and/or components and suggest a resolution workflow within the DBB.

Ability to associate technical and/or descriptive metadata to components. The components that are used to create a product for a given alpha will

be grouped as a kit for that title/alpha. Audio and video components can be associated to multiple relationships

of groupings ('kits').


111

The same components can exist in multiple relationships of groupings ('kits').

Assets An asset must be associated to a component.

Ability to maintain multiple revisions of an asset. Integration into MMSE to support intelligent storage of older revisions/less frequently accessed revisions of assets. Ability to revert to previous revisions of assets.

Asset Metadata Asset metadata will need to stored and maintained within the DBB. An Asset will maintain its own set of metadata that is separate from the

metadata associated with its component. PAM ‐ Physical Asset Management (extension of component visibility)

DBB inventory may eventually be extended to a PAM through interface in order to provide visibility to physical assets required by the DBB.

Ability to interface with SPE PAM system. Asset Associations

Ability to associate asset(s) to component requirement(s) (which maintain component requirement and type information) for which it is intended.

Ability to associate technical and/or descriptive metadata to components. Supporting Materials (including Images, Trailer and Other 'Materials')

Ability to upload supporting materials into the DBB from external sources prior to delivery. (Permanent storage of image in DBB not required scope for R1)

Ability to associate supporting materials metadata and their corresponding metadata at the title or alpha level.

Workflow Master Data Process Flow Master Data (see on boarding for implementation of process

flows) Ability to apply status to Specs (e.g. testing, hold, production). The combination of the Request master data, e.g. Client, Client Profile,

Title, Alpha, etc., will default the use of a specific workflow to fulfill the request associated to that client profile.

Each specification will be associated to one or multiple workflows. A UI must exist to manage (i.e. identification, linkage, etc.) workflows by

associating master workflow data, identifying tasks, etc. Workflows and any of their associated processes, tasks, etc. may be

shared across Partners so long as Partner specific information, such as titles, specifications, etc. is maintained separately.

Ability to override part of or all of a workflow. Billing Transactions (incl. Rate Card)

Multiple billing transactions can exist for one workflow. The same billing transaction could be used for multiple workflows. DBB needs to be able to access rate card information.

Tasks Ability for the DBB workflows to manage tasks and to monitor statuses,

approvals and version history of tasks within the DBB. All tasks must be associated to one or more unified workflow. Master data inputs, including component metadata, will help determine

which task to use should multiple tasks be available for the same workflow. Manufacturing Plan Ability to adjust request timelines based on external dependencies such


112

as external research. Ability to create and manage (i.e. changes, statuses, approvals, version

history) manufacturing plans within the DBB. A request must exist for each manufacturing plan to be created. There can be multiple manufacturing plans associated to a request when

there are multiple title/alphas and/or multiple specifications. Ability to analyze raw material quarantine and component repository to

determine availability to fulfill the request. The DBB will have the ability to identify and request services needed to

either transform existing materials or request creation of new materials to fulfill the request.

Ability to associate costs to each service being requested based on rate card calculations and business rules.

Ability to calculate duration to each service being requested. Ability to create, store and manage (i.e. statuses, approvals, version

history) workflow within the DBB. Ability to group request line items based on common manufacturing

requirements while taking into account business rules such as queue, due dates, priorities or operational decision (e.g. Advanced Planning & Optimization functionality)

Manufacturing Plan can be altered based off of business decisions to use different sources and/or services.

A UI is needed to be able to access and manage manufacturing plans and workflows.

Ability for the combination of the client profile and materials analysis to determine manufacturing plan workflow and associated tasks, costs and duration.

Manufacturing Analysis will need visibility to any Partner defined inventory storage locations where available component materials are being stored, i.e. component repository, raw material quarantine, and component requirement pending ingest.

Estimating Cost estimates need to be provided for manufacturing plans. Business rules and rate card computations will be used to calculate cost

estimates. Lead times and margin of errors may need to be estimated for each task

to be performed for the manufacturing plan. Cumulative lead times and margin of errors for the overall manufacturing

workflow may need to be estimated. Ability to re‐calculate the cost and lead time estimate throughout the

approval process. Task Management

Workflows Workflows will exist for various 'processing' activities within the DBB, i.e.

If a client needs a master delivered, a 'Delivery Only' workflow will be triggered vs. if a client needs a full transcode, package, and delivery, then a 'Transcode, Package, Deliver' workflow will be triggered.

A user has the ability to select a Request Type driven workflow, which can be used in conjunction with other system driven decisions.

A UI will be needed for outbound export functions (e.g. save file to disk). A UI will be needed for request status and updates.


113

Ability to perform both workflow orchestration tasks and provide required analytics tied to workflow tasks.

Priorities can be assigned at the manufacturing workflow level, which can be modified.

Ability to cancel initiated workflows. A workflow orchestration tool is needed to coordinate and manage tasks

and their interrelationships across workflows to which they belong. Workflows can be reused across Partners, however, workflow resources

need to be aware of Partner demand, Partner dedicated infrastructure and by which Partner its been used.

Ability to either suspend or cancel queued workflows when client profiles are suspended or deactivated. Must have ability to resume workflows when client profile comes out of suspension.

Task Management Ability to create and manage (i.e. statuses, approvals, version history)

tasks within and outside of the DBB. All tasks have to be associated with at least one manufacturing workflow

(whether internal or external). Notifications need to occur if the expected completion data of internal

and/or external tasks and/or workflows exceed the delivery due date. Tasks need to be queued and prioritized within a common service. Tasks will have information, e.g. statuses, priorities, etc that supports

visibility to their associated workflows. Task queue management will be conducted at the service level. Priorities can be assigned at the task level, which can be modified, within

the manufacturing plan/workflow. Operational task owners will have the ability to see tasks they are

responsible for in a user friendly way and manage their task priority and estimated completion dates by user determined metadata fields.

Task Dependencies When task parameters, such as status, priority, due date, etc., change,

then any other affected task needs to be re‐evaluated based on request, workflow, etc. needs.

Task Prioritization Business rules based on factors, such as SLA information, etc., will dictate

how tasks are sequenced and executed. MMSE (+retention and purging)

Setup of separate repositories that provides isolation of content from different partners. Each repository may have specific configuration elements. Must be able to support separation at physical & logical levels, i.e.: ‐ repositories that are separated at the logical level with shared physical infrastructure ‐ repositories with split logical and physical infrastructure (i.e. dedicated hardware) This is a key feature to ensure the possibility of having 3rd party clients (aka Partners) on the Backbone.

The MMSE solution needs to be integrated with the DBB and its technical infrastructure to be able to track status/progress of file services and health of underlying MMSE infrastructure (e.g. hard disk failures, storage availability, etc…).


114

Files will need to be able to be moved across all storage tiers based on business rules such as expiration dates, file metadata, task fulfillment, and/or other factors.

WIP Storage(+retention and purging) Files that need to be staged prior to any content processing will be held in

a WIP storage area. The WIP storage area needs to be easily accessible to the required

services. Any files that are moved from the WIP storage area will be copies of the

original file that will be maintained in the MMSE. Business rules should drive whether or not a WIP file can be used for

another request that needs that same WIP file. Business rules will drive how long WIP files should stay in WIP storage,

which may vary by Partner. File Management Ability to manage (i.e. statuses, version history) files within the DBB. Files requiring ingest need to be held within a raw material quarantine. Multi tenant security needs to be integrated into the DBB architecture. Event Logging Receipt and ingest of components into the DBB should be logged for

auditing purposes. Ingest

Only components can be ingested (via file upload) into the DBB. Components are assets associated with a component type and alpha.

Prior to ingest, assets should be received to a raw material quarantine. The ingest process should allow for manual tech logging as part of ingest

into the DBB, as required, to facilitate automated content processing. Ability to ingest file components in bulk (e.g. migration of DIAMONDS

assets). Ability to verify the accuracy of extracted technical metadata by

conducting basic automated tests (e.g. comparison of metadata duration with duration of actual asset, etc…). Errors must trigger a report and notification

Ability to create low‐res and frame accurate proxies and associate with master asset

Tech Logging Manual tech logging should be able to occur on frame‐accurate proxies of

the master after QC of the to‐be‐ingested component. Ability to log content via partner portal QC Ingest QC steps should be performed after associating new assets to

component requirements (but prior to ingest into the DBB). Ingest QC processes may include automated QC steps such as file integrity

checks (e.g., checksum, file size‐to‐duration checks, etc.), technical checks (e.g., bit rate, codec, colorspace, etc.), and hot spot checks.

Ingest QC flow should allow for manual QC steps to pass/fail content prior to formal ingest into the DBB.

Encode A UI is needed for visibility to external processes, including statuses and

ETCs and access to 3rd parties to title/alpha metadata.


115

Encoded content should be wrapped and delivered to the DBB along with Partner defined validation requirements.

Package Metadata All interfaced and manually entered metadata required for delivery will

be stored in the DBB. A UI will be available to view, enter and edit metadata (user entered and

interfaced) that is stored within the DBB. Ability to export metadata from centralized repository Ability to support regionalization of package metadata (e.g. language,

currency, date formats, etc…) Technical Metadata Technical metadata (e.g., file size, bit rate, checksum, etc.) should be

automatically captured for each product during the manufacturing process. Content Metadata During the product manufacturing process, content metadata should be

used along with other product metadata (e.g., technical metadata, image metadata, etc.) to generate the package metadata formatted to the client's metadata spec (frequently in XML format).

Content metadata will be accessed as needed via integrations to Partner title databases, if available.

Metadata Canonical The DBB should maintain a flexible metadata structure independent from

specific partner and client specs to be transformed as necessary. Metadata Mapping The DBB should support mapping metadata fields and values (from

source systems, internally maintained metadata, technical metadata, etc.) to client‐ and profile‐specific metadata specs.

Metadata Transformation The DBB will generate the package 'XML' according to client's metadata

spec. The package 'XML' will feature all required metadata as required by the metadata spec and may include content metadata, technical metadata, image metadata, etc.

Metadata Version Business Rules The DBB should support business rules for managing different metadata

versions, i.e. synopsis is changed for marketing reasons but business users need to view what has been previously delivered.

The metadata version business rules should be invoked when assembling and transforming metadata in order to meet client spec needs.

Packaging Package Creation/Management

Ability to rename package elements.

Packages will contain all components and ancillary materials as required per client profile & spec. These materials may include the audio/video file, images files, and metadata files (for instance).

Ability to associate technical and/or descriptive package metadata to packages.

Ability to apply security features (e.g. encryption, file re‐naming) to packages based on business rules.

External Materials Acquisition External materials should be "retrieved" as needed when required for

package assembly. This mechanism may make use of reference pointers or manual tasks as the situation allows/demands.


116

Metadata Acquisition Any metadata that is missing but required for the specified metadata spec

will be entered manually via a UI prior to package fulfillment. QC Assembled products may be QC'd prior to being packaged for delivery

based on client requirements. QC functionality may include automated QC (verify file size, duration, bit‐rate, stream analysis, audio container/frame validation, etc.), as well as functionality to deliver products for manual QC at selected suppliers.

Delivery Management Ability to override configured delivery method for a client per request.

Ability to support hard drive deliveries Ability to support the delivery of files that will be output to tape Provide the necessary logging for Delivery/Shipment Tracking Ability to support redeliveries for content that has not been purged based

on policy Ability to resume a file transfer as supported by protocol if it stopped for

any reason (avoid full transfer restarts) Notification of receipt or rejection to Requestor. Confirmation of network push delivery. Financial Transactions Ability to integrate into DADC's corporate finance system (COM) Ability to process $0 values or 'no‐charges' to enable test orders or re‐

work/re‐delivery required due to internal mistake Ability to send necessary transaction data to support auto‐invoice

generation by COM. Ability to send properly structured transaction data at the partner level

(e.g. support unified invoice for Master company‐sub‐company‐business unit structures).

Ability to create billing transactions based off of the manufacturing plan and its cost estimates.

The DBB needs to be able to have access to rate cards from which the DBB will be able to provide pricing calculations at Partner, project, service type and/or deal term levels, as well as a number of other pricing considerations.

DBB needs to track transactions with external suppliers to support invoicing/charge‐back to partners.

Need the ability to modify billing transactions and communicate those changes to Partners at any point in the process.

Search Simple search via commonly used fields. Advanced search with criteria for multiple fields, some of which may have

pre‐defined or structured values. The criteria may be specified in complex ways (e.g. ranges, starts/ends with, etc..). The logic used to perform the search using the multiple field is customizable by the user (e.g. AND, OR, NOT, etc..)

Ability to save search criteria for future use.


117

A search template allows the criteria structure to be saved and re‐used for future use with new search criteria values. Search templates can be defined at levels: ‐ system wide via configuration (at on‐boarding or via configuration maintenance process) ‐ partner level via configuration (at on‐boarding or via configuration maintenance process), with ACLs for visibility of templates at user or group levels ‐ group level and shared by all users within the group ‐ user level, defined by a user with the option to share within the user's group (see above)

Ability to display search results by including metadata fields in the results (e.g. title, description, dates, etc)

Ability to sort results by predefined fields within the search results. Ability to display search results with links to the component records. System driven search capabilities are needed for data that will facilitate

DBB processing, such as title, alpha, specifications and other operational needs.

Business Intelligence/Reporting

Ability to report on all workflow and inventory data Operational dashboard (e.g. KPIs)


118

Appendix E – Client Product Specifications The Digital Backbone (DBB) will be required to support a multitude of Product Specifications in Release 1 as well as evolving (likely increasing) over time. Below is a table of the current Product Specifications that will need to supported by the platform and created using the Content Processing Functions outlined in Appendix F. The details of the specifications numerated below are also attached in PDF format.

Specification ID Specification Name 1110 1110_MPEG_8100k_M1L2_224k_2ch 1160 1160_MPEG_15000k_M1L2_384k_2ch 1114 1114_MPEG_20000k_M1L2_384k_2ch 1154 1154_MPEG_15000k_M1L2_384k_2ch 1298 1298_QUICKTIME_220000k_PCM_1536k_2ch 1000 1000_MPEG_20000k_M1L2_384k_2ch 1279 1279_QUICKTIME_35000k_PCM_1536k_2ch 1108 1108_MPEG_3180k_AC3_192k_2ch 1300 1300_QUICKTIME_63000k_PCM_1536k_2ch 1256 1256_H264_2000k_AAC_128k_2ch 1011 1011_WMV_1372k_WMA92_128k_2ch 1041 1041_FLASH_700k_MP3_96k_1ch 1112 1112_MPEG_8100k_AC3_384k_6ch 1249 1249_QUICKTIME_35000k_PCM_1536k_2ch 1156 1156_MPEG_8100k_M1L2_224k_2ch 1251 1251_QUICKTIME_90000k_PCM_1536k_2ch 1097 1097_MPEG_50000k_PCM_4608k_4ch 1283 1283_MPEG_50000k_AC3_192k_2ch 1249 1249_QUICKTIME_35000k_PCM_1536k_2ch 1148 1148_MPEG_8100k_M1L2_384k_2ch 1158 1158_MPEG_8100k_M1L2_224k_2ch 1164 1164_MPEG_20000k_M1L2_224k_2ch 1168 1168_H264_5000k_AAC_192k_2ch 1253 1253_QUICKTIME_25000k_PCM_3072k_4ch 1268 1268_WMV_772k_WMA92_128k_2ch 1270 1270_WMV_872k_WMA92_128k_2ch 1003 1003_WMV_972k_WMA92_128k_2ch 1006 1006_WMV_1172k_WMA92_128k_2ch 1013 1013_WMV_636k_WMA92_96k_2ch 1100 1100_MPEG_80000k_PCM_4608k_4ch 1047 1047_MPEG_2050k_M1L2_192k_2ch 1063 1063_MPEG_3950k_AC3_192k_2ch 1087 1087_MPEG_1750k_M1L2_192k_2ch 1102 1102_QUICKTIME_n/ak_PCM_1536k_2ch


119

1104 1104_MPEG_13600k_AC3_192k_2ch 1106 1106_MPEG_13600k_AC3_384k_6ch 1118 1118_WMV_2000k_WMA92_192k_2ch 1121 1121_WMV_664k_WMA92_96k_2ch 1150 1150_MPEG_8100k_M1L2_384k_2ch 1152 1152_MPEG_2050k_M1L2_192k_2ch 1162 1162_MPEG_20000k_AC3_384k_6ch 1166 1166_H264_10000k_AAC_192k_2ch 1170 1170_WMV_800k_WMA92_64k_2ch 1259 1259_WMV_636k_WMA92_64k_2ch 1264 1264_MPEG_8000k_M1L2_384k_2ch 1266 1266_MPEG_3200k_AC3_192k_2ch 1276 1276_H264_2600k_AC3_384k_2ch 1281 1281_H264_1700k_AAC_128k_2ch 1296 1296_H264_894k_AAC_128k_2ch 1302 1302_WMV_436k_WMA92_64k_2ch 1304 1304_WMV_2308k_WMA92_192k_2ch 1309 1309_MPEG_50000k_PCM_6144k_8ch 1312 1312_MPEG_20000k_AC3_384k_6ch 1322 1322_MPEG_19000k_AC3_384k_6ch 1354 1354_MPEG_14000k_M1L2_384k_2ch 1359 1359_MPEG_14000k_M1L2_384k_2ch


120

Appendix F – Content Processing Functions The Distribution Backbone (DBB) will require a number of tools and capabilities in the processing of stored master content for delivery. The following is the identified list for automation in Release 1. The framework and integration of these sets of functionalities can be accommodated by multiple products and the response should indicate the product(s) that are intended to meet the requirements.

Content Processing Function Short Description

Transcode

Conversion 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

Overlays/Watermark & Burn-Ins

Overlays and visible watermarks & burn-ins

Forensic/Invisible Watermark

Invisible watermarks (for SD and HD video content)

Closed Caption (CC) Insertion

During processing, allow for the insertion of Closed Captions into content in SD or HD specs for distribution (primarily broadcast and VOD)

Audio Layback (pre-conformed)

Combination of separate video and audio elements, with the assumption the audio file is conformed, in the course of servicing (not necessarily as a muxing operation)

Encryption Encryption of delivery file(s)

Fingerprinting Creating a signature of the essence file such that it can be identified via scanning (Title/Alpha identification vs. forensic/anti-piracy goals)

Bug "insertion" Persistent bug insertion throughout program. Ability to expand functionality for more agile functionality like fade in/out and appearance at intervals, etc.

Logo/Card Addition Addition/replacement/removal of cards/logos to a set location in the product. Includes, but is not limited to Distribution Logos, MPAA cards, FBI/Interpol warnings


121

Additional Content formatting/manipulation -

Addition/replacement/removal of other elements within product such as bars/tones, slates, commercial black (at defined locations), and addition/subtraction of “textless” material at tail

Standards Conversion Generally includes (video & accompanying components, e.g. captions, audio, subs):

Pull down or rate adjustment to convert from HD into SD cadence, color space, etc.

Changing frame rates, etc. within HD

Within SD, PAL to NTSC and vice versa

Cropping Crop video content based on defined coordinates or aspect ratio

Inverse Telecine and De-interlacing

Create progressive source from interlaced content

File Wrapping and Unwrapping

Wrapping of Product and or Packages for further processing in common formats such as MXF/IMX/MOV, ZIP/TAR/Stuff-It, directory structures and/or XML manifest

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

Automated Content QC Analyze files intended for ingest for content related issues (e.g. stills, unintended black areas, audio drop outs)

Checksum Generation CRC, MD5

Additionally, as discussed in the Ingest White Paper, there will be a need for a toolset for technical logging to identify content segments and other data. These toolsets will need to playback, log/mark/identify segments, and then output the metadata of that process. Suggestions for tools to both perform the technical logging via operators and assist (via indexing or frame recognition) in the function should be provided.


122

Appendix G – Master File (eMaster) Definition

The Master format for digital files is expected to evolve not unlike tape formats and quality has evolved over time to support increasing standards of quality. The eMaster format for Release 1 should aspire to achieve the goal that I can service all possible downstream servicing needs that might not be directly identified in the initial release of the system, but would mitigate the need to return to the source media to recreate a new master. The primary intent, however, is to define a set of standard file formats for video and audio that will result in consistent output that meets the requirements of current client outputs and content processes planned for Release 1 (as defined in Appendix’s E and F respectively).

For historic reasons the following eMaster formats need to be supported by the DBB. It is not required, nor preferred, that the going-forward encode process that will create content to be ingested into the DBB will be of this format. However, historical encodes in this format will be ingested into the DBB ahead of launch to capture/leverage previous efforts. Additionally, post launch it may be determined that other historical encodes in this format will be ingested into the DBB for cost mitigation purposes.

• Historical SD Specification – Video: MPEG2 50 Mbps, I-frame only, CBR, YUV 4:2:2, 8bit – Audio: SMPTE 302M (Mapping of AES3 Data into an MPEG-2 Transport

Stream), 48kHz – Wrapper: MXF

• Historical HD Specification – Video: MPEG2 80 Mbps, I-frame only, CBR, YUV 4:2:2, 8bit – Audio: SMPTE 302M (Mapping of AES3 Data into an MPEG-2 Transport

Stream), 48kHz – Wrapper: MXF

In Release 1, there are a number of preferred specs that are being analyzed as SPE’s preferred eMaster format for SD and HD to meet the defined workflows and to provide an acceptable level of future workflow support. Additionally, as this platform needs to support alternate standards of third parties, below is a listing of the initial candidates the DBB team feels most likely in meeting the needs of SPE and future DBB clients. The platform must be open enough to support both the evolution of master file formats and the requirement of third-parties to use alternate formats.

• SD Specification – Option #1

• Video: MPEG2 50 Mbps, I-frame only, CBR, YUV 4:2:2, 8bit • Audio: Uncompressed PCM 24-bit, 48kHz, WAV • Wrapper: MXF

– Option #2


123

• Video: ProRes 422 (SD mode, 40 – 60 Mbps), I-frame only, VBR, YUV 4:2:2, 8bit

• Audio: Uncompressed PCM 24-bit, 48kHz, WAV • Wrapper: N/A

• HD Specification – Option #1

• Video: MPEG2 80-120 Mbps, I-frame only, CBR, YUV 4:2:2, 8bit • Audio: Uncompressed PCM 24-bit, 48kHz, WAV • Wrapper: MXF

– Option #2 • Video: ProRes 422 (HD mode, 145 – 220 Mbps), I-frame only,

VBR, YUV 4:2:2, 8bit? • Audio: Uncompressed PCM 24-bit, 48kHz, WAV • Wrapper: N/A

– Option #3 • Video: Cineform 300-350 Mbps, I-frame only, CBR or VBR, YUV

4:4:4/4:2:2 per source, 10bit • Audio: Uncompressed PCM 24-bit, 96kHz, BWAV • Wrapper: MOV

– Option #4 • Video: JPEG2K 200-250 Mbps, I-frame only, CBR or VBR, YUV

4:4:4/4:2:2 per source, 10bit • Audio: Uncompressed PCM 24-bit, 96kHz, BWAV • Wrapper: MXF

NOTE: Suppliers should feel open to suggest possible alternatives for formats (codecs, wrappers, bit-rate, etc.) as appropriate to allow for the processing describe in Appendices E and F.

Additionally, it is acceptable to capture and store a particular file format for durability. Interim mezzanine formats may be derived for use in complex processing.


124

Appendix H – Functional Reference Architecture

The Reference Architecture outlines the primary functional components and interfacing applications for the DBB. Reference Architecture Diagram

Enc

odin

gP

hysi

cal A

sset

M

anag

emen

t

Phy

sica

l Sec

urity

Con

trols

& P

roto

cols

Pow

er (r

edun

dant

pro

vide

rs, c

ondi

tione

d, o

n-si

te b

ack-

up)

Env

ironm

enta

l Con

trols

(fire

sup

ress

ion,

tem

pera

ture

, hum

idity

)

Net

wor

k C

onne

ctiv

ity

Infr

astr

uctu

re M

onito

ring

Phys

ical

Infr

astr

uctu

re (S

erve

rs, S

tora

ge, N

etw

orki

ng)

Reference Architecture Definitions

1. User Interface

The 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. It is conceivable that there could be a single UI with different views based on user authorization.

1.1. Partner Portal

The partner portal provides Partners, or users acting on their behalf, the ability to interact with the partner specific data within the DBB. This can


125

include, but is not limited to, Requests, Inventory, Client Profiles and Supporting Materials.

1.2. Admin Portal

The Admin portal provides operational administrators visibility into all operational data within the DBB. This can include, but is not limited to, Requests, Client Profiles, Tasks, Inventory, Manufacturing Plans, Operational KPIs and infrastructure alerts. In certain instances, such as infrastructure alerts, the portal may simply link to an external application as opposed to building specific UI components to surface the information.

1.3. Client/Supplier Portal

The client/supplier portal provides an interface for clients and/or suppliers to interact with the DBB. This portal should provide visibility into Requests and Tasks as well as provide file transfer capabilities to enable clients/suppliers to provide assets that are required to fulfill Requests. Suppliers can be either internal or external contributors of content.

2. Customization Services These services will allow the DBB to decouple the user interface, branding, and tenant specific customization separate from core business services as well as application code.

The customization services (also referred as metadata service in SaaS architecture) provide customers with the primary means of customizing and configuring the application to meet their needs. Typically, customers can make configuration changes in four broad areas:

• User Interface & Branding – Customers often prefer the modification of the user interface to reflect their corporate branding, and therefore multi-tenant applications typically offer features that allow customers to change things such as graphics, colors, fonts, and so on (also referred to as “skinning”).

• Extension to Data Model – For many data-driven multi-tenant applications, one size doesn't fit all Partners. An extensible data model gives future Partners the required flexibility to meet their business needs.

• Business Rules – To be of use to a wide range of potential customers, a business-critical application has to be able to accommodate differences in workflow. For example, one customer of an invoice tracking application may require each invoice to be approved by a manager; a second customer may require each invoice to be approved by two managers in sequence; a third may require two managers to approve each invoice, but allow them to work in parallel. When appropriate, Partners should be able to request that system behave in a manner, leveraging business rules, which the application's


126

workflow aligns with their business processes.

3. Core Services

3.1. Business Process Management (BPM)/Workflow Orchestration

The BPM/Workflow Orchestration layer manages the execution and monitoring of workflows which can contain automated and manual activities. The DBB will execute business process and content processing workflows such as Onboarding, Request Management, Manufacturing Plan Request/Approval and Delivery Management.

3.2. Process Services

Most of these functions/services deal with logging, event and exception management, and notification at the BPM level. These should produce data that is auditable for events across the system and accessible via search.

3.2.1. Event Logging

Event 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 DBB. The solution should be capable of managing, archiving, reviewing, and auditing of all the logs produced by the system.

3.2.2. Event Management

Enterprise Event 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.

3.2.3. Exception Management

The exception management architecture of the solution should have the capability to:

• Detect exceptions • Perform code clean up • Wrap one exception inside another • Log and report error information


127

• Generate events that can be monitored externally to assist system operation

3.2.3.1. Notification

Notifications provide a mechanism for distributing information about events within an application. 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.

Also, notification systems must be reliable because they're often used to deliver mission-critical alerts. It must be scalable so that they can support high volumes of data, without requiring excessive hardware. The solution must be manageable and fit seamlessly into the infrastructure. Most importantly, notification system must be secure.

3.3. Business Services

Most of these functions/services deal with performance, security, monitoring, protocol mediation, and delivery of business services. Most of these functions/services should be managed at the ESB and possibly BPM level.

3.3.1. Policy Enforcement & Governance

Governance deals with the processes by which a system operates. In order to have successful governance, some form of management, monitoring and administration is required for these processes. SOA governance is the discipline of creating policies that can be communicated between interested parties as well as enforced. It has aspects within the design-time and run-time areas of service development and deployment.

3.3.2. SLAs & Guaranteed Delivery

Monitoring and enforcement of SLAs both from service availability as well as service performance is very important. Some of the features desired are:

• Provide the ability to enforce SLAs between a service consumer and publisher, send performance alerts, and log service performance characteristics such as throughput, errors, invocations, response time.


128

• Allow SLAs to be defined (and statistics tracked) according to both service performance and business context: by customer, channel, region, business unit, manufacturing plant, etc.

• Include the ability to change the behavior of rules, such as routing rules, dynamically based on the operational state (e.g., automatically reroute premium customers to an alternate data center when the SLA for premium customers is getting close to its limit).

• Include the ability to apply management policies to either individual requests (e.g., alert me and audit the request if its response time exceeds 16 seconds) or to aggregates (e.g., change the routing behavior if the average response time for high-value transactions exceeds 8 seconds).

• When an operational alert is detected, takes a snapshot of the entire transaction path (even the parts of the transaction path that occur before the issue is recognized) for later analysis--with no measurable impact on the performance of the running system

3.3.3. Protocol Mediation

Built-in mediation capabilities will make it straightforward for the DBB to reconcile the incompatible protocols, data 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. The following are some of the common standards we would like to see as part of this service are HTTP/HTTPS, JMS, SOAP, REST, and Content Based Routing

3.3.4. Monitoring, Visibility and Control

The capability to manage and monitor the SOA application infrastructure as well as the processes and services deployed within it will be very important. To provide dynamic, run-time control, the solution should be configuration-driven, services should be parameterized and their mediated relationships should be declared, so they may be changed without re-compilation and re-deployment. This allows the modification of data and process flow without shutting down running services. For federated environments, it is critical that it seamlessly bridge LAN boundaries and security domains. It should allow visibility and control across the entire federated environment. To facilitate development in a real-world, distributed environment, the solution may require real-time message tracking and distributed flow control debugging. Finally, in order to allow the diagnosis and


129

management of problems in complex distributed systems, administrative features should provide logging and auditing of services, as well as the monitoring of faults, service and process status, and detailed performance statistics of the services and communication infrastructure.

3.3.5. Security, reliability and availability

The solution should provide an enterprise-level quality of service to ensure that service communication is as secure and reliable as needed to meet a particular business requirement. Highly available SOA application infrastructure isolates services from faults resulting from server and communication failures. A true highly available solution will present itself to services as not only a reliable infrastructure, but one whose integration services are continuously available, even if a component in its distributed infrastructure should fail.

The solution should ensure the secure transmission of data with the end points as well as to the connected services. Some of the widely used security standards are WS-Security, HTTP-S, SSL, X.509 certificates, and embedded RSA encryption support. The solution should also provide extensive security policies to help with authentication and authorization, as well as data protection, privacy, integrity, and validation.

3.3.6. Analytics

The solution should be able to provide management and monitoring of services and services infrastructure, adding only microseconds of latency to system operations. It should capture key aggregate and per-transaction statistics including service invocations, service orchestration tracking, performance, volume, SLA violations. Should generate statistics based on the message processing path. Should be able to create, aggregate, and calculate KPI data (key performance indicators). The solution should store captured reporting data in an external relational database and can present this through pre-defined and customizable displays. Finally, the solution should be able to generate other reports directly from the underlying data.

3.3.7. Traffic Control & Distribution

Solution should be capable of load balancing, rate/concurrency limiting, and prioritization. It should support flexible, rules-driven routing, configurable subject-, content-, and itinerary-based routing of messages to services. The solution should allow multiple intelligent routes to be invoked in parallel and the results


130

aggregated as message parts within a message. It should be able to support highly scalable request/response systems.

3.3.8. Performance and scalability

The solution should contain sophisticated traffic and fault management. It should offer extensive load-balancing support to allow pools of servers to be used to host Web services, including automatic retries when individual servers are down. Under heavy load conditions, requests from high-priority customers can be honored, while those from lower priority customers are queued. Alternatively, high-priority requests can be routed to special pools of servers designed to provide better quality of service, and additional servers/services can be brought online/accessed to deal with increased loads or outages. Requests can be rerouted to exception queues during outages for later processing, and peak loads can be buffered and smoothed to keep servers from being overwhelmed. The solution should be capable of taking advantage of caching, compression, encryption, and parsing/schema validation.

3.3.9. Fault Management

The solution should be capable debugging, fault isolation, and exception routing. The solution should be able to detect error conditions based on policy violations, whose conditions can include a combination of technical metrics (e.g., message size, elapsed time, etc.), content of a message, and context about a message (e.g., security credentials, time-of-day, etc.). Once an alert is generated, it should allow administrators to directly drill down into relevant audit and technical logs. The solution should be able to capture a snapshot of the entire transaction path, including every step along the way, every metric associated with each part of the path, and even which exact instances in any clusters that the transaction went through.

3.4. Security and Administration Services

These services will allow the DBB to keep the business services as well as user interaction secure, consistent, and auditable using encryption, signatures, content filtering, content validation, authentication, authorization, and auditing. The security architecture should consist of a variety of controls including logging, encryption, access controls, forensics, protective markings, security metadata, secure delivery mechanisms, repository security, interface security, and transactional security to preserve the confidentiality, integrity and availability of the assets stored in the Digital Backbone.


131

The security architecture should provide a rules-based framework to protect services, data at rest and data in transit from its source, across the wire, to its destination while simultaneously enforcing policies to provide content aware control, and report on incorrect and improper usage. The principal objectives of the security architecture are as follows:

• Ensure that the storage, use and exchange of information assets complies with all applicable laws and regulations relating to information security

• Safeguard confidential and proprietary information that belongs to SPE and is entrusted to SPE by its suppliers, business partners and customers

• Complies with the rules set forth in Sony Parties’ as well as Sony Corporation’s Global Information Security Standard and Policy for protecting our information assets; Security compliance should extend to industry standards such as ISO27001 in future releases

• Provides technical countermeasures, to protect information assets from risks such as unauthorized access, leakage, falsification, loss, destruction, or denial of service

• Provides the ability to audit the performance of our technical countermeasures and information security practices in order to ensure the safety of information assets and confirm compliance with applicable laws, regulations and internal rules

• Provides assurance customers, suppliers and partners who access the Digital Backbone are observing appropriate information security practices

The guiding principles for security architecture are as follows: • Security should be transparent to end-users • Security should be tailored to meet business needs and asset protection

requirements • Security should not be one size fits all • Security should not be limited to technical countermeasures but instead

be a combination of policies and technology • Each implemented technology should align with the To-Be Architecture

The security architecture should consist of services that can be accessed by all relevant processes. The common services should consist of at least the following (not including those security related Content Processing Functions outlined in Appendix F):


132

• Authentication – A set of process and procedures that establish with a high degree of confidence the identity of a given individual, service or machine

• 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 subject is authenticated, it may be authorized to perform different types of access

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

• 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.

3.5. Reporting Services

The reporting services represent the functionality to support the generation and execution of reports necessary for the operation of DBB. This could include creating reporting data stores so as not to adversely impact performance of core DBB functionality.

4. Integration Services Integration Services enable the exchange of information between disparate systems. The method of exchange can vary based on the systems being integrated and the timeliness of the data required, however, the integration services should provide functionality to assist the exchange in uniform ways.

5. Partner (SPE) Specific Interfacing Systems 5.1. GPMS

GPMS provides Title Master functionality for SPE and contains the Title, Alpha, and talent Metadata. The data from GPMS will be used for inventory organization as well as for package metadata that will be required by the DBB. The GPMS system will provide data to the DBB through a WebMethods managed publication(s). Web services are also available for this interfacing system. SPE will also expect to receive back any enhancements to Title, Alpha, or Talent metadata back to via interface GPMS. In addition to the primary data entities referenced above, GPMS will also play a role in the mapping key referential data that may be needed for SPE such as media (i.e. media market), territory and language. Technically, GPMS is a J2EE and Oracle based system.

5.2. GOLD (Xytech)


133

GOLD is SPE’s implementation of Xytech’s Enterprise product which maintains an inventory of components, both physical and digital, and provides Purchase Order creation and financial transaction interfacing to SAP. Xytech Enterprise has a two-tier client-server architecture with a Powerbuilder client and SQL Server backend. The interfaces for Xytech Enterprise, both inbound and outbound, are SOAP/HTTP based. There are four interfaces that are envisioned to/from GOLD / DBB. 5.2.1. PO Interface

The DBB will provide Order Creation/Update web service calls to the GOLD System. From the DBB Manufacturing Plan data will be organized in a Order Creation XSD that will be utilized to create Media Purchase Orders in GOLD. Updates will include cancellation and modification of the PO.

5.2.2. DBB Plan Approval Once GOLD PO Approval of a DBB-created order is achieved, a message will be sent from GOLD to the DBB to release or reject the manufacturing plan.

5.2.3. PO Closure Update Once the DBB completes a Request a message will be sent to GOLD to close the PO and interface to SAP.

5.2.4. Inventory Interface The DBB will provide Asset Create/Update data to GOLD in order to maintain a GOLD Partition that provides visibility to DBB asset data within the GOLD inventory system.

5.3. SAP SAP is the financial system of record for Sony Pictures and serves as the General Ledger (GL) that the financial transactions for the Purchase Orders fulfilled by the DBB will flow into. There is no direct interface required between DBB and SAP for the SPE partner since that functionality will be handled by an existing interface between GOLD and SAP.

5.4. cineSHARE+/EAGL These are both custom enterprise DAMs currently in use at SPE to manage many of the supporting materials such as trailers, images, chapter stills and metadata required to fulfill requests.

6. Partner (Other) Specific Interfacing Systems In future releases, DBB will need to service Partners in addition to SPE. The following examples represent external systems that DBB will need to interface with to access supporting data critical to the operation of DBB. 6.1.1. Title Master 6.1.2. Supporting Materials DAM


134

6.1.3. Inventory 6.1.4. Purchase Order 6.1.5. Financials (SAP, JD Edwards, Oracle…)

7. Encoding Creation of a file for Ingestion into the DBB to specification. Usually the file is captured from tape, but it can also include the encoding from a file (i.e. from DPX as a result of the Digital Intermediates process). This is a manual process aided by encoding workstation toolsets – in the DBB these tools are not planned to be directly integrated.

8. Physical Inventory Management Organization and tracking of physical assets/inventory and their respective metadata. Specifically to media, this often includes bar-coded assets that are stored in vaults. This is usually performed in a system and facilitated by operators. For the DBB, there will not be a physical inventory management system, though it is assumed that SPE’s system will be integrated as well as those for internal operations and future Partners.

9. Media Asset Management Provides the foundational services for the management of files and metadata about the Components within the DBB (including Title/Alpha metadata interfaced into the DBB). It is likely that in Release 2, or sooner, that these Services will be distributed for disaster recovery or performance reasons, perhaps across geographies, so this should be factored into the proposed architecture. Services:

9.1. File Management Also 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 DBB. The File Management Services will need live visibility into MMSE 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.

9.2. Metadata Management The repository where metadata is stored and updated within the DBB for use in digital file inventory management/processing and business/title metadata for packaging

9.3. Ingest Services facilitating the process of getting Components and their metadata verified and QC’d before entering the DBB. In that process


135

these Services will often be orchestrated with Content Processing Services and provide additional validation logic.

9.4. Technical Logging Toolsets 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 Component video and provide suggestions for the operator to confirm/complete.

9.5. Replication Services (for distributed computing and disaster recovery) Out of scope currently for Release 1 (mainly for use in distributed operations and disaster recovery), 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).

9.6. Storage Management This is the software layer that facilitates the management and efficient utilization of the multi-tier storage environment used by the DBB. Storage types will include landing zones for transferred content, WIP for content processing and packaging, bulk storage, etc.

9.7. Search (Internal/External) Facilitate the queries against primarily structured internal DBB data/metadata (from the UI or from other DBB services) as well as linking for searches of external systems (for Release 1, only GOLD will be searched). Future requirements include links to supporting materials DAM as well as other internal or external systems.

10. Content Processing Collection of services generally characterized by the integration of third party software for the purpose of transforming or otherwise manipulating Components to meet a desired Client Profile. These services will need to be orchestrated as defined in the Manufacturing Plan and Workflow Master Data as well as resource managed for Quality of Service (QoS), load balancing, and resiliency purposes. It is likely that in Release 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.

10.1 Services See “Appendix F – Content Processing Functions” for more details

11. Financial Services (Outside of Backbone)


136

External DADC application(s) used in the financial management of the DBB for its Partners. There is one interface defined that will carry transactional data for completed requests from the DBB to DADC’s financials system. Additionally, on a periodic basis a reconciliation report will be generated and used to “true up” against SPE’s financial systems to provide a control given the financial approach outlined in the Financial Data Flow Whitepaper. The following services are defined for completeness, but are not in scope for implementation (just interfacing).

11.1. Invoice Generation Not used in the SPE defined financial processes with DBB & DADC. However, for other third party Partners of the DADC, this will generate Invoices for services.

11.2. Billing Transaction Interface For SPE, and potentially for future Partners, the DBB will generate financial data for a request and create a PO in the Partner’s PO system. For SPE POs will be created by the DBB in the GOLD System.

11.3. Rate Card Management Provides for the maintenance for price of services charged by the DADC for DBB services.

11.4. DADC COM Integration Integration from the DBB into DADC’s existing COM system, a custom Oracle based finance system. The interface will be unidirectional from the DBB to COM and will carry transactional level detail for all requests processed by the DBB.

12. Manufacturing Services These Services are key aspects for the activities in the Digital Supply Chain around the actual execution of the Manufacturing Plans. It is composed of analytic type services that result in the plans as well as the necessary decision support data that underpins tuning the operations for increased efficiency. 12.1. Manufacturing Analysis

Performs the necessary analysis and validations of the Request to create the Manufacturing Plan and lead it through the approval process to the Manufacturing Engine.

12.2. Demand Planning/Queue Management Provides for the collection of workflow data for executed Manufacturing Plans for use in demand planning and analysis as well as tuning the business rules and priority used in Queue Management for Tasks within workflows.

12.3. Capacity Planning Provides for the collection of workflow data at the service level for use in capacity planning analysis.


137

13. Package Assembly Services Package Assembly Services provide the functionality to combine product and supporting materials according to client specifications and prepare for delivery. 13.1. Metadata Transform Services

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

13.2. Compression Services Certain Client Profiles may require packages to be compressed, ie. zip, stuff-it or tar prior to delivery.

13.3. Supporting Material Acquisition Services enable DBB to identify and stage package elements required for delivery.

13.4. File Naming Specific 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.

14. Partner Services Partner Services enable partners to manage data directly in the DBB. This interaction can occur manually or via an interface. 14.1. Request Management

These services enable Partners to create and modify Requests to the backbone for the creation of the Manufacturing Plan.

14.2. Title/Alpha Management These services enable Partners to create and modify Title/Alphas. This can be done manually or directly via an interface.

14.3. Client Master/Profile Management These services enable Partners to create and modify Client Master data and Client Profile data. This can be done manually or directly via an interface.

15. Delivery Management Delivery 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 DBB will be required to support include: 15.1.1. Aspera 15.1.2. SmartJog 15.1.3. FTP/SFTP 15.1.4. Hard Drive 15.1.5. iTunes Transporter 15.1.6. Delivery Confirmation


138

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

15.1.7. Capacity to support other distribution methods, TBD 16. Supporting Data Services

Supporting data services provide the services required to manage the data that DBB requires from an operational perspective. The following list of data categories must be managed directly by the DBB. Some of these categories need not be the master data stores, though for smaller clients they may be, but they must, at the very least, behave as operational data stores which can be populated via interfaces when necessary. 16.1.1. Title/Alpha 16.1.2. Client Master/Profiles 16.1.3. Partner Profiles 16.1.4. Supporting Materials linking data 16.1.5. Order Data 16.1.6. Inventory Metadata 16.1.7. Package Metadata

17. Infrastructure Monitoring Infrastructure Monitoring is responsible for monitoring key aspects of the infrastructure that have a direct impact on the DBB’s ability to operate. Key information such as current CPU and I/O should be visible as well as any error conditions that may arise. Ideally, this monitoring would have the ability to communicate directly to DBB in a manner that pro-active steps could be taken to continue execution when an error condition arises. For example, if a particular transcoder was down, DBB would not attempt to send transcode requests to it.


139

Appendix I – Non-Functional Estimating Guidance

This appendix provides certain statistical and projected guidance for use in estimating for hardware and system sizing and scaling requirements. SPE expects to source hardware to meet its requirements, but may be receptive to creative sourcing options as an amendment to this RFP.

Data Center R1 Tier 3 data center (per TIA‐942 & Uptime Institute standards)

Environmental controls (fire suppression, temperature, humidity)

Physical security controls & protocol Remote hands service Geographical stability Redundancy & System Availability R1 N+1 redundancy for single points of failure for systems and services

Includes: power, WAN connectivity, multi‐homing/link aggregation, storage fabric, PSU, etc…

Database and applications hot/transparent fail‐over

Redundant or load‐balanced instances of database and application servers must provide hot/transparent failover capabilities

Data center must have 99.982% availability

Per Tier 3 requirement defined under Data Center

Network must have 99.99% availability Includes both outbound network connectivity as well as internal interconnects.

General systems must have 99.9% availability

General systems include partner facing applications, client facing applications and operational applications and systems. The availability requirements cover application and database servers. Excludes scheduled maintenance time.

Online storage systems must have 99.9% availability

Excludes scheduled maintenance time.

Nearline storage systems must have 99.9% availability


ACP & Packaging systems must have 99.9% availability


Delivery systems must have 99.95% availability


Partner and client facing systems must be available 24/7

Partners will have users across the world in multiple time zones. Most access will happen during weekdays but the operational nature also requires availability during weekends. Client users are spread out across the world. Many


140

client touch points may also be automated systems which requires 24/7 availability.

Partner facing systems must support loads of up to 50 concurrent users out of 250 total active

Includes: request interface, status reports, other reports. Expected growth rate: 10% YoY

Client facing UI touch points must support loads of up to 350 concurrent users

Includes: customer support, ticketing system, status reports/delivery confirmations. Expected growth rate: 10% YoY

Client side delivery touch points (in push & pull models) must support simultaneous deliveries for up to 50 concurrent deliveries

File backup strategy Tapes must be stored at an alternate location and available for retrieval

Maintenance R1 Scheduled Maintenance Planned scheduled downtime for any apps or systems not to exceed one 6 hour window per week in predefined downtime windows.

Planned scheduled downtime covers: system patching/upgrades, preventive maintenance). Predefined downtime windows: factors in user time zone dispersion and business/operational hours.

Downtime windows must be outside of regular business hours on US‐Pacific time zone and avoid peak business hours of other major locations

Other major location: London

Disaster Recovery & Business Continuity

Future

Assessment on future impact to add in DR & BCP requirements

Assessment should cover expected high‐level impact to R1 architecture & design to add in DR & BCP requirements with proposed breakdown RPO and RTO by service or system component. Where applicable, include proposed baseline/target RPO/RTO. R1 design must not preclude the addition of DR & BCP functions for future releases.

Requisition Re‐routing See Multi‐Site Operations ‐ Requisition Re‐routing Multi‐Site Operations Future Multi‐site library and asset repository System must manage assets that reside in local

repositories local at multiple sites. The assets may be transferred by: a)predefined business rules in an automated process or b) manually triggered transfers.


141

Ingest from off‐site facility System must support the ability to ingest from an off‐site facility at which ingest information is captured and the master component asset is supplied. System must track the source of the original asset in the case of an update to an asset and facilitate the integrity of lineage via customized workflow and approval processes.

Storage of master component in off‐site facility

System must allow assets to be transferred to an off‐site facility via: a) automated and customizable business rules or b) on‐demand manual requests.

ACP and delivery processing from off‐site facility

System must allow ACP and delivery functions to be fulfilled from off‐site facilities.

Requisition Re‐routing Ability to re‐route requisitions based on rules (e.g. based on geographical proximity and optimized network traffic routing) or on‐demand requests. System must be linked to the availability of master components to route the requisition to an appropriate facility. This functionality can be used to balance load between sites or provide service continuity during outages (scheduled and unscheduled).

Service Levels R1 Requisition Types Reactive Any order triggered by the client. Due dates are

typically associated with reactive requisitions.

Proactive New releases, catalog triggered by demand planning, remasters, change of formats. These requisitions should leverage downtime to maximize utilization without affecting reactive requisitions.

Rush Support for rush requisitions. This type of requisition will be created on an ad‐hoc basis for critical/high‐priority content that did not have the lead times for appropriate scheduling.

Client Launch Support for requisitions aiming to provide client with content for the launch process which involves building up their catalog. Best effort must be provided to meet the client's launch date. This may also require alternate delivery methods driven by the quantity of files that must be delivered under specific time constraints.

Turn‐Around Times Calculation model for expected turn‐around times

Provide a best‐estimate calculation model for business driven services (e.g. requisition for client launch for X title‐alphas for client profile Y) Inputs include: sample requisition, system sizing


142

data

Volumes & Capacity 300 hours of SD Ingest per week ~25 titles, x3.5 alpha/component requirement

combos, avg 100 mins per title

400 hours of HD Ingest per week ~50 titles, x2 alpha/component requirement combos, avg 100 mins per title

4,000 files transcoded per week 1000 requisitions per month Ability to support up to 500 title‐alphas per

requisition Expected YoY growth: ~10%

5,000 packages delivered per week Guaranteed in‐bound network throughput: dedicated 1 Gbps fiber lines per master source origination points

Dedicated 1Gbps fibre lines

Guaranteed out‐bound network throughput: 700 Mbps

Burstable to over 1Gbps

Assessment of capacity breaking points

Quality System/Applications/Tool quality errors of 1% or less

Content quality rejection rate of 1% or less

Consistent quality of output based on quality of input master.

Customer Support R1 24/7 data center support Operations R1 Target utilization rate of processing power: 90%

Out‐of‐Band/Lights‐Out Management Systems must provide an access mechanism through a dedicated management channel for system monitoring and maintenance

Manual service access System must provide a means to manually access and trigger discrete services to fulfill requisitions, bypassing automated orchestration features.

Provisioning for new partner with dedicated environment

Environments cover many aspects of systems & application layers that may have specific constraints for shared vs. dedicated infrastructure (e.g database, app server, transcoding servers, etc…), including correct orchestration.


143

Provisioning for new partner with shared environment (existing capacity is sufficient)


Provisioning for new partner with dedicated for average load and shared environment for peak/overflow


Monitoring R1 Heartbeat and Availability Systems must provide internal mechanisms to

confirm that systems are running and available to provide services. Customer facing systems must provide mechanisms for 3rd party monitoring services to confirm availability (e.g. Gomez).

System Services and Host Resources Systems must provide instrumentation for host resources and services (e.g. uptime, load, throughput, capacity, etc…). Data must be captured in a format that allows aggregation at service type level and drill‐downs to specific servers/instances.

System and Application Logs Monitoring of system and applications log events Security and IDS Physical environment & security monitoring See Data Center

Documents

Sony Pictures Entertainment (“SPE”) - WikiLeaks Distribution... · CONFIDENTIAL SPE/DADC Request for Proposal 5 1.02 Strategy and Context The Sony Parties have developed a multi-phased,