Multi-channel Strategies

Multi-channel strategy at Entertainment Company

I think the following will be useful to consider in the RFP development process

1. reafirm the strategic elements that are being developed here in architectural terms so the responses are based on specific

Frameworks.

I see these as business goals of

- consolidation strategy

- cost reduction strategy

- leverage strategy

And then the media infrastructure frameworks

- Content management

- Content Streaming

- Content schedule feed

- Consolidated Feed and syndication

- Enterprise Content distribution Network

I think phase 1 is to do the Content management and consolidated feed and syndicator

Phase 2 is the feeds and distribution network and streaming.

2. ask respondents to define a migration strategy to support the move to the new "xyz" architecture.

From experience of recent bids and issues over standards this can be both an opportunity and a stumbling block.

- Notably there should be a set of tools and programme management methods to demonstrate a robust deployment roadmap

- This is an area where vendors can offer "creative" deals for cost reduction by off shore or other techniques. It would be

Worth encouraging ideas on this since the SI services landscape is a rapidly developing environment.

- Focus on specific interface standards and technology standards. From experience I have found that what is supposed to be a standard

Web service protocol is often only standard for one vendor and needs to be adapted to interoperate. This potentially

Stops integration and migration projects. Evidence should be given as to how the integration and messaging will work in principle. For

Example there are a range of integration interaction patterns - each would have a different infrastructure backbone in theory. For example

The replication and batch transfers would be handled by a specific set of networks and protocols. The publish-subscribe type services

Has reside in web services registry and called when required via a service bus. Vendors will come up with their own ideas on this but I would

Encourage evidence to be shown of how this would be done. The better ITTs I have seen have some ideas on this already and appear to

Try to create a preferred network and services approach.

• SOA type pattern integration using Request-reply and Publish-sub patterns. Typically XML for data transport and Web services methods

• Replication - usually ETL technology, FTP file transfers and use of canonical formats transformations

• Intra - integration between applications internally - tight coupling - essentially the same as replication but does not use canonical mappings as the data is internal and private to the application domain

• Service Proxy for distributed req-reply or pub-sub services to remote. There are a number of options which vendors should offer for gateway standards

• 3rd party integration - depending on the async or sync integration messaging would govern the type of solution

• COTS integration - Identify what standard web services COTS have already exposed and what integration architectures they have. In theory off the shelf

Packages could connect to the SOA and provide common services quickly.

3. state a set of Architecture governance principles that need to be supported by the solution.

This is particularly important if the approach in thye RFP is to define business requirements rather than the traditional IT solution

Sizing approach.

Here are some examples (this is by no means exhaustive but include some of the principles I see as key for moving to an architectural layered approach + service orientation.)

Design Principles

• Concurrent - how legacy systems and new platform technology will be run in parallel in cross

• Canonical data - how data formats will be transformed and consistency maintained over period

• Delivery - how different protocols will be mediated e.g. what specific technology for mediation

• Access - security - how will then be defined at specific message and database levels to protocol and role / SSO / (LDAP or equivalent)levels

• Distributed - what transport methods will be used for distributed architectures

• Domain management - how will processes be orchestrated where appropriate

• Performance - how will QoS and DQm be managed and optimised

• Intelligence - how will BI and BAM dashboard technology be developed

• Adapter technology - how will proprietary and standards based / (Open standards perhaps) connectivity be managed

• Coordination - how will extraprise collaboration be provided (not as an add-on B2B gateway but a comprehensive Multi-channel media framework)

• Configuration - how will IDE registries, repositories be managed and version/config controlled

• Logic - how will business logic and system logic be held and maintained

4. include the access layer and multi-channel aspects into the solution scope.

I know this was described as phase 2 I have seen situations where a bottom up IT approach turned on its head

By some vendors through to the the exec wanting to get business benefits from faster channel access. I don’t think this will happen

as Jason already has the "logical service consumers" (Release mgt, IT Dev, HAL etc) and "access methods"

(e.g. HTTP, FTP, caching etc) and this is part of the overall framework. My work at BSkyB was based on multi-channel programs of work with some

Focus on common "horizontal" services. The aim to control channel infrastructure and "play" in any segment via targeted services to leverage ARPU etc...

#Multichannel #CX #Digital #BSkyB