Technology
Building a scalable OTT platform
Building a scalable OTT platform
Building a scalable OTT platform
Building a scalable OTT platform
Chris Wood
6 min read
|
18 Sept 2023
Building an OTT live streaming or on-demand content platform can be a bit of a daunting task, so I wanted to share a few pointers that I thought may help.
Typically, these kinds of projects start with a discussion where someone up top has promised a launch of a new proposition with some crazy immoveable deadline – or perhaps worse, done a deal with a platform in a box provider and agreed to get something to market that covers every inconceivable use case in the shortest possible timeframe. Sound familiar?
Despite the challenges that lie ahead, I wanted to try to talk you through a things that will hopefully guide you in the right direction. The goal? To build a scalable and reliable platform that doesn’t make vendor lock in and limited scale the first two features on your roadmap.
1. Requirements capture
Requirements fall into a few high-level categories and buckets. Product, business, technology. Typically everything nests under these verticals in some way. It’s a little easier to write up the usual consumer facing ‘functional requirements’ than it is for some of the more often unknown or often forgotten about requirements such as tax management.
The key with requirements capture is to ensure that every detail is covered. I’ll give you a working example.
A product manager will draft a requirement along the lines of “As a user I should be able to search the site”. A good technical architect will have the ability to break this down to 10-15 individual requirements across functional and non-functional that will cover areas like content search, data search, multi-language, filtering, sorting, persistence, notifications of results, null search results, analytics and BI integration, predictive search, response times for results and so on.
The message here is that the more work you do around ensuring the requirements are EXPLICIT and DETAILED, the more pain you’ll save yourself later when the solution the vendor provided doesn’t do what you thought it would do. Remove ambiguity.
2. RFI/RFP process and vendor analysis
Why do we need an RFP? There are many reasons – but primarily think of this as a mechanism to compare potential suitors and suppliers for the streaming platform you’re going to build.
The production of good of RFI and RFP documentation along with the definition of the process are both as equally important as each other. (As an aside – it’s important to know the difference between RFI and RFP!) Knowing how to correctly structure a requirements document that a vendor or provider can understand and reply to in a way that you’ll be able to understand, compare and score will help you more than you know.
A good RFP document and process will:
Reduce the time taken to run the RFP process
Allow vendors to understand your requirements and generate accurate quotations and proposals
Remove ambiguity from responses – ensuring that ‘non-compliant’, ‘compliant’, and ‘roadmap’ requirements are clear
Highlight what vendors are capable of and what they are not
Identify gaps and areas that your business, product and technology teams need that are not fulfilled by either the primary vendor or systems integrator
Allow an ‘apples for apples’ vendor comparison of responses
For good measure – we also suggest selecting a few use cases at random and asking your top 2 or 3 vendors to demonstrate how these features or functionalities work. If they’ve replied with ‘compliant’ – you’ll soon know if they’re telling the truth.
When we write RFP documentation and run processes for our clients, it’s not unusual to see upwards of 1500 functional and non-functional requirements for an OTT or streaming platform defined. If you’re short of this number – you should probably ask yourself if you’ve covered it all thoroughly and correctly.
3. Platform architecture and design
As part of this journey, we’re setting out to build a scalable video streaming platform. The platform architecture and design phase evaluates the requirements identified by the business, compares these to the solutions proposed by the vendors and suppliers, and works to build scalable designs and solution references that:
Ensure requirements for launch can be met
Bring flexibility to incorporate changing requirements – architect for change
Identify gaps in the proposals and generate solutions to address them
Reduce or eliminate the risk of vendor lock-in
Support functional AND non-functional requirements at scale
Allow for unlimited scale of producers and consumers - live streaming to millions
Ensures best practices, standards and approaches are followed
Meet compliance criteria for territories for which they will operate
Balance time, quality and cost criteria
Meet security, performance, operational benchmarks
And finally, ensure that solution provides business value
Media and streaming platform architects ensure that solutions proposed deliver upon the very best way to implement – not stop at what only the vendor or solution provider has to offer.
4. A path to implementation
With good ground work, the path to implementation will inevitably become simpler. Regardless, the implementation of scalable, highly performing, resilient and reliable OTT platforms still takes work – and often requires ‘squads’ or teams of focussed individuals to own the development and deployment of key areas such as Identity, Billing, Subscriptions, Content, Compliance, Analytics and Data, Apps and others.
These focussed teams are given autonomy to self manage, guided by experienced leads who have hopefully implemented similar services below, and will guide each workstream through from design to production.
It’s no secret that more and more organisations employ fewer and fewer domain expertise, with some business units formed solely of product teams (developers, managers, designers, marketers). The challenge? The domain knowledge and experience needed on a technical level to be able to hold vendors and suppliers to account when things get technically tricky is missing.
Whilst vendors will propose what they are able to offer to meet the requirements set by the business, this is by no means the only way, as any good video platform architect will attest to.
The most successful implementations are those where the business acknowledges the need to guide and control the implementation, either through leveraging internal technical expertise to own the architecture, or by leveraging external experience like the teams we provide at Spicy Mango.
Repeatedly, we see the supplier or vendor only representing their own interests, not those of the client or wider programme. Modern online video platforms (OVP’s) are rarely technology stacks developed solely by a single entity anymore, with nearly all being multi-vendor SaaS based environments – a collection of many individual point products all providing individual elements of the solution. A good set of technical domain expertise brings you an independent arbitrator to put an end to finger pointing when things go wrong.
Building an OTT live streaming or on-demand content platform can be a bit of a daunting task, so I wanted to share a few pointers that I thought may help.
Typically, these kinds of projects start with a discussion where someone up top has promised a launch of a new proposition with some crazy immoveable deadline – or perhaps worse, done a deal with a platform in a box provider and agreed to get something to market that covers every inconceivable use case in the shortest possible timeframe. Sound familiar?
Despite the challenges that lie ahead, I wanted to try to talk you through a things that will hopefully guide you in the right direction. The goal? To build a scalable and reliable platform that doesn’t make vendor lock in and limited scale the first two features on your roadmap.
1. Requirements capture
Requirements fall into a few high-level categories and buckets. Product, business, technology. Typically everything nests under these verticals in some way. It’s a little easier to write up the usual consumer facing ‘functional requirements’ than it is for some of the more often unknown or often forgotten about requirements such as tax management.
The key with requirements capture is to ensure that every detail is covered. I’ll give you a working example.
A product manager will draft a requirement along the lines of “As a user I should be able to search the site”. A good technical architect will have the ability to break this down to 10-15 individual requirements across functional and non-functional that will cover areas like content search, data search, multi-language, filtering, sorting, persistence, notifications of results, null search results, analytics and BI integration, predictive search, response times for results and so on.
The message here is that the more work you do around ensuring the requirements are EXPLICIT and DETAILED, the more pain you’ll save yourself later when the solution the vendor provided doesn’t do what you thought it would do. Remove ambiguity.
2. RFI/RFP process and vendor analysis
Why do we need an RFP? There are many reasons – but primarily think of this as a mechanism to compare potential suitors and suppliers for the streaming platform you’re going to build.
The production of good of RFI and RFP documentation along with the definition of the process are both as equally important as each other. (As an aside – it’s important to know the difference between RFI and RFP!) Knowing how to correctly structure a requirements document that a vendor or provider can understand and reply to in a way that you’ll be able to understand, compare and score will help you more than you know.
A good RFP document and process will:
Reduce the time taken to run the RFP process
Allow vendors to understand your requirements and generate accurate quotations and proposals
Remove ambiguity from responses – ensuring that ‘non-compliant’, ‘compliant’, and ‘roadmap’ requirements are clear
Highlight what vendors are capable of and what they are not
Identify gaps and areas that your business, product and technology teams need that are not fulfilled by either the primary vendor or systems integrator
Allow an ‘apples for apples’ vendor comparison of responses
For good measure – we also suggest selecting a few use cases at random and asking your top 2 or 3 vendors to demonstrate how these features or functionalities work. If they’ve replied with ‘compliant’ – you’ll soon know if they’re telling the truth.
When we write RFP documentation and run processes for our clients, it’s not unusual to see upwards of 1500 functional and non-functional requirements for an OTT or streaming platform defined. If you’re short of this number – you should probably ask yourself if you’ve covered it all thoroughly and correctly.
3. Platform architecture and design
As part of this journey, we’re setting out to build a scalable video streaming platform. The platform architecture and design phase evaluates the requirements identified by the business, compares these to the solutions proposed by the vendors and suppliers, and works to build scalable designs and solution references that:
Ensure requirements for launch can be met
Bring flexibility to incorporate changing requirements – architect for change
Identify gaps in the proposals and generate solutions to address them
Reduce or eliminate the risk of vendor lock-in
Support functional AND non-functional requirements at scale
Allow for unlimited scale of producers and consumers - live streaming to millions
Ensures best practices, standards and approaches are followed
Meet compliance criteria for territories for which they will operate
Balance time, quality and cost criteria
Meet security, performance, operational benchmarks
And finally, ensure that solution provides business value
Media and streaming platform architects ensure that solutions proposed deliver upon the very best way to implement – not stop at what only the vendor or solution provider has to offer.
4. A path to implementation
With good ground work, the path to implementation will inevitably become simpler. Regardless, the implementation of scalable, highly performing, resilient and reliable OTT platforms still takes work – and often requires ‘squads’ or teams of focussed individuals to own the development and deployment of key areas such as Identity, Billing, Subscriptions, Content, Compliance, Analytics and Data, Apps and others.
These focussed teams are given autonomy to self manage, guided by experienced leads who have hopefully implemented similar services below, and will guide each workstream through from design to production.
It’s no secret that more and more organisations employ fewer and fewer domain expertise, with some business units formed solely of product teams (developers, managers, designers, marketers). The challenge? The domain knowledge and experience needed on a technical level to be able to hold vendors and suppliers to account when things get technically tricky is missing.
Whilst vendors will propose what they are able to offer to meet the requirements set by the business, this is by no means the only way, as any good video platform architect will attest to.
The most successful implementations are those where the business acknowledges the need to guide and control the implementation, either through leveraging internal technical expertise to own the architecture, or by leveraging external experience like the teams we provide at Spicy Mango.
Repeatedly, we see the supplier or vendor only representing their own interests, not those of the client or wider programme. Modern online video platforms (OVP’s) are rarely technology stacks developed solely by a single entity anymore, with nearly all being multi-vendor SaaS based environments – a collection of many individual point products all providing individual elements of the solution. A good set of technical domain expertise brings you an independent arbitrator to put an end to finger pointing when things go wrong.
Building an OTT live streaming or on-demand content platform can be a bit of a daunting task, so I wanted to share a few pointers that I thought may help.
Typically, these kinds of projects start with a discussion where someone up top has promised a launch of a new proposition with some crazy immoveable deadline – or perhaps worse, done a deal with a platform in a box provider and agreed to get something to market that covers every inconceivable use case in the shortest possible timeframe. Sound familiar?
Despite the challenges that lie ahead, I wanted to try to talk you through a things that will hopefully guide you in the right direction. The goal? To build a scalable and reliable platform that doesn’t make vendor lock in and limited scale the first two features on your roadmap.
1. Requirements capture
Requirements fall into a few high-level categories and buckets. Product, business, technology. Typically everything nests under these verticals in some way. It’s a little easier to write up the usual consumer facing ‘functional requirements’ than it is for some of the more often unknown or often forgotten about requirements such as tax management.
The key with requirements capture is to ensure that every detail is covered. I’ll give you a working example.
A product manager will draft a requirement along the lines of “As a user I should be able to search the site”. A good technical architect will have the ability to break this down to 10-15 individual requirements across functional and non-functional that will cover areas like content search, data search, multi-language, filtering, sorting, persistence, notifications of results, null search results, analytics and BI integration, predictive search, response times for results and so on.
The message here is that the more work you do around ensuring the requirements are EXPLICIT and DETAILED, the more pain you’ll save yourself later when the solution the vendor provided doesn’t do what you thought it would do. Remove ambiguity.
2. RFI/RFP process and vendor analysis
Why do we need an RFP? There are many reasons – but primarily think of this as a mechanism to compare potential suitors and suppliers for the streaming platform you’re going to build.
The production of good of RFI and RFP documentation along with the definition of the process are both as equally important as each other. (As an aside – it’s important to know the difference between RFI and RFP!) Knowing how to correctly structure a requirements document that a vendor or provider can understand and reply to in a way that you’ll be able to understand, compare and score will help you more than you know.
A good RFP document and process will:
Reduce the time taken to run the RFP process
Allow vendors to understand your requirements and generate accurate quotations and proposals
Remove ambiguity from responses – ensuring that ‘non-compliant’, ‘compliant’, and ‘roadmap’ requirements are clear
Highlight what vendors are capable of and what they are not
Identify gaps and areas that your business, product and technology teams need that are not fulfilled by either the primary vendor or systems integrator
Allow an ‘apples for apples’ vendor comparison of responses
For good measure – we also suggest selecting a few use cases at random and asking your top 2 or 3 vendors to demonstrate how these features or functionalities work. If they’ve replied with ‘compliant’ – you’ll soon know if they’re telling the truth.
When we write RFP documentation and run processes for our clients, it’s not unusual to see upwards of 1500 functional and non-functional requirements for an OTT or streaming platform defined. If you’re short of this number – you should probably ask yourself if you’ve covered it all thoroughly and correctly.
3. Platform architecture and design
As part of this journey, we’re setting out to build a scalable video streaming platform. The platform architecture and design phase evaluates the requirements identified by the business, compares these to the solutions proposed by the vendors and suppliers, and works to build scalable designs and solution references that:
Ensure requirements for launch can be met
Bring flexibility to incorporate changing requirements – architect for change
Identify gaps in the proposals and generate solutions to address them
Reduce or eliminate the risk of vendor lock-in
Support functional AND non-functional requirements at scale
Allow for unlimited scale of producers and consumers - live streaming to millions
Ensures best practices, standards and approaches are followed
Meet compliance criteria for territories for which they will operate
Balance time, quality and cost criteria
Meet security, performance, operational benchmarks
And finally, ensure that solution provides business value
Media and streaming platform architects ensure that solutions proposed deliver upon the very best way to implement – not stop at what only the vendor or solution provider has to offer.
4. A path to implementation
With good ground work, the path to implementation will inevitably become simpler. Regardless, the implementation of scalable, highly performing, resilient and reliable OTT platforms still takes work – and often requires ‘squads’ or teams of focussed individuals to own the development and deployment of key areas such as Identity, Billing, Subscriptions, Content, Compliance, Analytics and Data, Apps and others.
These focussed teams are given autonomy to self manage, guided by experienced leads who have hopefully implemented similar services below, and will guide each workstream through from design to production.
It’s no secret that more and more organisations employ fewer and fewer domain expertise, with some business units formed solely of product teams (developers, managers, designers, marketers). The challenge? The domain knowledge and experience needed on a technical level to be able to hold vendors and suppliers to account when things get technically tricky is missing.
Whilst vendors will propose what they are able to offer to meet the requirements set by the business, this is by no means the only way, as any good video platform architect will attest to.
The most successful implementations are those where the business acknowledges the need to guide and control the implementation, either through leveraging internal technical expertise to own the architecture, or by leveraging external experience like the teams we provide at Spicy Mango.
Repeatedly, we see the supplier or vendor only representing their own interests, not those of the client or wider programme. Modern online video platforms (OVP’s) are rarely technology stacks developed solely by a single entity anymore, with nearly all being multi-vendor SaaS based environments – a collection of many individual point products all providing individual elements of the solution. A good set of technical domain expertise brings you an independent arbitrator to put an end to finger pointing when things go wrong.
Building an OTT live streaming or on-demand content platform can be a bit of a daunting task, so I wanted to share a few pointers that I thought may help.
Typically, these kinds of projects start with a discussion where someone up top has promised a launch of a new proposition with some crazy immoveable deadline – or perhaps worse, done a deal with a platform in a box provider and agreed to get something to market that covers every inconceivable use case in the shortest possible timeframe. Sound familiar?
Despite the challenges that lie ahead, I wanted to try to talk you through a things that will hopefully guide you in the right direction. The goal? To build a scalable and reliable platform that doesn’t make vendor lock in and limited scale the first two features on your roadmap.
1. Requirements capture
Requirements fall into a few high-level categories and buckets. Product, business, technology. Typically everything nests under these verticals in some way. It’s a little easier to write up the usual consumer facing ‘functional requirements’ than it is for some of the more often unknown or often forgotten about requirements such as tax management.
The key with requirements capture is to ensure that every detail is covered. I’ll give you a working example.
A product manager will draft a requirement along the lines of “As a user I should be able to search the site”. A good technical architect will have the ability to break this down to 10-15 individual requirements across functional and non-functional that will cover areas like content search, data search, multi-language, filtering, sorting, persistence, notifications of results, null search results, analytics and BI integration, predictive search, response times for results and so on.
The message here is that the more work you do around ensuring the requirements are EXPLICIT and DETAILED, the more pain you’ll save yourself later when the solution the vendor provided doesn’t do what you thought it would do. Remove ambiguity.
2. RFI/RFP process and vendor analysis
Why do we need an RFP? There are many reasons – but primarily think of this as a mechanism to compare potential suitors and suppliers for the streaming platform you’re going to build.
The production of good of RFI and RFP documentation along with the definition of the process are both as equally important as each other. (As an aside – it’s important to know the difference between RFI and RFP!) Knowing how to correctly structure a requirements document that a vendor or provider can understand and reply to in a way that you’ll be able to understand, compare and score will help you more than you know.
A good RFP document and process will:
Reduce the time taken to run the RFP process
Allow vendors to understand your requirements and generate accurate quotations and proposals
Remove ambiguity from responses – ensuring that ‘non-compliant’, ‘compliant’, and ‘roadmap’ requirements are clear
Highlight what vendors are capable of and what they are not
Identify gaps and areas that your business, product and technology teams need that are not fulfilled by either the primary vendor or systems integrator
Allow an ‘apples for apples’ vendor comparison of responses
For good measure – we also suggest selecting a few use cases at random and asking your top 2 or 3 vendors to demonstrate how these features or functionalities work. If they’ve replied with ‘compliant’ – you’ll soon know if they’re telling the truth.
When we write RFP documentation and run processes for our clients, it’s not unusual to see upwards of 1500 functional and non-functional requirements for an OTT or streaming platform defined. If you’re short of this number – you should probably ask yourself if you’ve covered it all thoroughly and correctly.
3. Platform architecture and design
As part of this journey, we’re setting out to build a scalable video streaming platform. The platform architecture and design phase evaluates the requirements identified by the business, compares these to the solutions proposed by the vendors and suppliers, and works to build scalable designs and solution references that:
Ensure requirements for launch can be met
Bring flexibility to incorporate changing requirements – architect for change
Identify gaps in the proposals and generate solutions to address them
Reduce or eliminate the risk of vendor lock-in
Support functional AND non-functional requirements at scale
Allow for unlimited scale of producers and consumers - live streaming to millions
Ensures best practices, standards and approaches are followed
Meet compliance criteria for territories for which they will operate
Balance time, quality and cost criteria
Meet security, performance, operational benchmarks
And finally, ensure that solution provides business value
Media and streaming platform architects ensure that solutions proposed deliver upon the very best way to implement – not stop at what only the vendor or solution provider has to offer.
4. A path to implementation
With good ground work, the path to implementation will inevitably become simpler. Regardless, the implementation of scalable, highly performing, resilient and reliable OTT platforms still takes work – and often requires ‘squads’ or teams of focussed individuals to own the development and deployment of key areas such as Identity, Billing, Subscriptions, Content, Compliance, Analytics and Data, Apps and others.
These focussed teams are given autonomy to self manage, guided by experienced leads who have hopefully implemented similar services below, and will guide each workstream through from design to production.
It’s no secret that more and more organisations employ fewer and fewer domain expertise, with some business units formed solely of product teams (developers, managers, designers, marketers). The challenge? The domain knowledge and experience needed on a technical level to be able to hold vendors and suppliers to account when things get technically tricky is missing.
Whilst vendors will propose what they are able to offer to meet the requirements set by the business, this is by no means the only way, as any good video platform architect will attest to.
The most successful implementations are those where the business acknowledges the need to guide and control the implementation, either through leveraging internal technical expertise to own the architecture, or by leveraging external experience like the teams we provide at Spicy Mango.
Repeatedly, we see the supplier or vendor only representing their own interests, not those of the client or wider programme. Modern online video platforms (OVP’s) are rarely technology stacks developed solely by a single entity anymore, with nearly all being multi-vendor SaaS based environments – a collection of many individual point products all providing individual elements of the solution. A good set of technical domain expertise brings you an independent arbitrator to put an end to finger pointing when things go wrong.
Building an OTT live streaming or on-demand content platform can be a bit of a daunting task, so I wanted to share a few pointers that I thought may help.
Typically, these kinds of projects start with a discussion where someone up top has promised a launch of a new proposition with some crazy immoveable deadline – or perhaps worse, done a deal with a platform in a box provider and agreed to get something to market that covers every inconceivable use case in the shortest possible timeframe. Sound familiar?
Despite the challenges that lie ahead, I wanted to try to talk you through a things that will hopefully guide you in the right direction. The goal? To build a scalable and reliable platform that doesn’t make vendor lock in and limited scale the first two features on your roadmap.
1. Requirements capture
Requirements fall into a few high-level categories and buckets. Product, business, technology. Typically everything nests under these verticals in some way. It’s a little easier to write up the usual consumer facing ‘functional requirements’ than it is for some of the more often unknown or often forgotten about requirements such as tax management.
The key with requirements capture is to ensure that every detail is covered. I’ll give you a working example.
A product manager will draft a requirement along the lines of “As a user I should be able to search the site”. A good technical architect will have the ability to break this down to 10-15 individual requirements across functional and non-functional that will cover areas like content search, data search, multi-language, filtering, sorting, persistence, notifications of results, null search results, analytics and BI integration, predictive search, response times for results and so on.
The message here is that the more work you do around ensuring the requirements are EXPLICIT and DETAILED, the more pain you’ll save yourself later when the solution the vendor provided doesn’t do what you thought it would do. Remove ambiguity.
2. RFI/RFP process and vendor analysis
Why do we need an RFP? There are many reasons – but primarily think of this as a mechanism to compare potential suitors and suppliers for the streaming platform you’re going to build.
The production of good of RFI and RFP documentation along with the definition of the process are both as equally important as each other. (As an aside – it’s important to know the difference between RFI and RFP!) Knowing how to correctly structure a requirements document that a vendor or provider can understand and reply to in a way that you’ll be able to understand, compare and score will help you more than you know.
A good RFP document and process will:
Reduce the time taken to run the RFP process
Allow vendors to understand your requirements and generate accurate quotations and proposals
Remove ambiguity from responses – ensuring that ‘non-compliant’, ‘compliant’, and ‘roadmap’ requirements are clear
Highlight what vendors are capable of and what they are not
Identify gaps and areas that your business, product and technology teams need that are not fulfilled by either the primary vendor or systems integrator
Allow an ‘apples for apples’ vendor comparison of responses
For good measure – we also suggest selecting a few use cases at random and asking your top 2 or 3 vendors to demonstrate how these features or functionalities work. If they’ve replied with ‘compliant’ – you’ll soon know if they’re telling the truth.
When we write RFP documentation and run processes for our clients, it’s not unusual to see upwards of 1500 functional and non-functional requirements for an OTT or streaming platform defined. If you’re short of this number – you should probably ask yourself if you’ve covered it all thoroughly and correctly.
3. Platform architecture and design
As part of this journey, we’re setting out to build a scalable video streaming platform. The platform architecture and design phase evaluates the requirements identified by the business, compares these to the solutions proposed by the vendors and suppliers, and works to build scalable designs and solution references that:
Ensure requirements for launch can be met
Bring flexibility to incorporate changing requirements – architect for change
Identify gaps in the proposals and generate solutions to address them
Reduce or eliminate the risk of vendor lock-in
Support functional AND non-functional requirements at scale
Allow for unlimited scale of producers and consumers - live streaming to millions
Ensures best practices, standards and approaches are followed
Meet compliance criteria for territories for which they will operate
Balance time, quality and cost criteria
Meet security, performance, operational benchmarks
And finally, ensure that solution provides business value
Media and streaming platform architects ensure that solutions proposed deliver upon the very best way to implement – not stop at what only the vendor or solution provider has to offer.
4. A path to implementation
With good ground work, the path to implementation will inevitably become simpler. Regardless, the implementation of scalable, highly performing, resilient and reliable OTT platforms still takes work – and often requires ‘squads’ or teams of focussed individuals to own the development and deployment of key areas such as Identity, Billing, Subscriptions, Content, Compliance, Analytics and Data, Apps and others.
These focussed teams are given autonomy to self manage, guided by experienced leads who have hopefully implemented similar services below, and will guide each workstream through from design to production.
It’s no secret that more and more organisations employ fewer and fewer domain expertise, with some business units formed solely of product teams (developers, managers, designers, marketers). The challenge? The domain knowledge and experience needed on a technical level to be able to hold vendors and suppliers to account when things get technically tricky is missing.
Whilst vendors will propose what they are able to offer to meet the requirements set by the business, this is by no means the only way, as any good video platform architect will attest to.
The most successful implementations are those where the business acknowledges the need to guide and control the implementation, either through leveraging internal technical expertise to own the architecture, or by leveraging external experience like the teams we provide at Spicy Mango.
Repeatedly, we see the supplier or vendor only representing their own interests, not those of the client or wider programme. Modern online video platforms (OVP’s) are rarely technology stacks developed solely by a single entity anymore, with nearly all being multi-vendor SaaS based environments – a collection of many individual point products all providing individual elements of the solution. A good set of technical domain expertise brings you an independent arbitrator to put an end to finger pointing when things go wrong.
To find out more about anything you've read here, or to learn how Spicy Mango could help, drop us a note at hello@spicymango.co.uk, give us a call, or send us a message using our contact form and we'll be in touch.
More insights you may enjoy
More insights you may enjoy
More insights you may enjoy
More insights you may enjoy
Unlock incredible potential and value with scalable, high performing and reliable platforms and capabilities across sports, broadcast and entertainment.
Get in touch
Contact us - we don't bite
Drop us an email at hello@spicymango.co.uk or call us on +44 (0)844 848 0441 or fill out the contact form below for a friendly chat.
Get in touch
Start your journey
Drop us an email at hello@spicymango.co.uk or call us on +44 (0)844 848 0441 or fill out the contact form below for a friendly chat.
Get in touch
Contact us - we don't bite
Drop us an email at hello@spicymango.co.uk or call us on +44 (0)844 848 0441 or fill out the contact form below for a friendly chat.
Get in touch
Contact us - we don't bite
Drop us an email at hello@spicymango.co.uk or call us on +44 (0)844 848 0441 or fill out the contact form below for a friendly chat.
Get in touch
Contact us - we don't bite
Drop us an email at hello@spicymango.co.uk or call us on +44 (0)844 848 0441 or fill out the contact form below for a friendly chat.