Technology
OTT build vs buy - what's the best approach?
OTT build vs buy - what's the best approach?
OTT build vs buy - what's the best approach?
OTT build vs buy - what's the best approach?
Chris Wood
4 min read
|
21 Nov 2023
In OTT platform development, what do we really mean by the term "commodity"? Are we all on the same page with the concept of what is "valuable", and should we be changing our thinking?
In OTT design and build projects, one of the topics that comes up often relates to bits of the stack that customers want to own, versus the bits they don’t - often described as “commodity”. If I’ve learnt anything from my 20 years in OTT, it has taught me that the term commodity is very much a subjective and not an objective point of measure. Let me try to explain.
The rationale of the perceived higher value bits of the chain (the “non-commodity bits”), and those that service providers want ownership of, are the direct touch points the consumer has with the service - the experience, the look and the feel. It stands to reason that apps and websites can be paramount to either the success or failure of the offering.
By complete contrast, many back-end services like video and content management, syndication or metadata processing - no one typically wants to "own". Why? Despite being where all the intelligence is and them being complicated, costly to develop and maintain and requiring a lot of expertise to get right, they’re still viewed as “low-value commodity components”. I mean, it’s so easy to go to market and buy a standard off-the-shelf "do anything" CMS right?
The result is that most service providers today buy commodity components off the shelf - but are using internally staffed teams to develop and own the front end. Seems sensible right? Well, I'm not so sure.
Any good front-end application or platform can only be as good as the back-end services that are feeding it. Whether this be editorial articles, video, audio, images and artwork or data. To date, despite a lot of trying, I’ve never been able to design an experience that a good front-end development team was unable to build. However, by comparison, I’ve experienced a HUGE number of projects that have had their time and cost budgets blown because of an inability to do something simple in the “commodity CMS”. Why does happen? It's simple to answer but often the elephant in the room. Fundamentally, a lack of due diligence or validation of technology, product or business requirements in these "commodity" components.
Despite a media and OTT market that is utterly littered with app developers and development houses that can build high-quality apps to almost any imaginable design, I still can't get my head around the fact that these front-end components are still viewed as the things that are critical to own - despite the underlying fact that the features and capabilities that make it to the front end, are entirely dependent and reliant on the bits that sit behind the scenes.
What happens next is a situation that we've all experienced first-hand. These commodity components that were so easy to buy off the shelf and didn’t warrant the time investment because they have no value or “all do the same thing”, are suddenly blocking roadmaps, generating increasing development costs and technical debt - as teams try to circumvent and resolve the simple thing they're trying to do on the front end.
This behaviour compounds and over time and starts to form most of the reason Quality of Experience (QoE) becomes a challenge. Proxies, abstractions and client-heavy engineering, instead of server-side logic winning out. Any and all means are used to bypass limitations in back-end services. Technical debt grows and grows.
Where do we close out? I'm always the guy arguing that the commodity low-value component, isn’t the back-end platform, but the front-end bit that is so easily built to any art of the possible design with any half-capable development team or partner. It’s fundamentally the bit that will never really block your ability to do something cool for your fans or audience.
The argument over putting more time, care and attention (maybe even having to "own") bits of the back-end platform, starts to make more sense. From experience, a CMS for example, is one of the single biggest impactful components in your solution - and one that fundamentally drives everything you do or will want to do on your roadmap that the consumer or fan will interface with.
What you do today, tomorrow and in three years is decided by the decisions you make over the platform that's sitting behind those shiny apps.
Maybe flipping the commodity model on its head is worth some extra thought?
In OTT platform development, what do we really mean by the term "commodity"? Are we all on the same page with the concept of what is "valuable", and should we be changing our thinking?
In OTT design and build projects, one of the topics that comes up often relates to bits of the stack that customers want to own, versus the bits they don’t - often described as “commodity”. If I’ve learnt anything from my 20 years in OTT, it has taught me that the term commodity is very much a subjective and not an objective point of measure. Let me try to explain.
The rationale of the perceived higher value bits of the chain (the “non-commodity bits”), and those that service providers want ownership of, are the direct touch points the consumer has with the service - the experience, the look and the feel. It stands to reason that apps and websites can be paramount to either the success or failure of the offering.
By complete contrast, many back-end services like video and content management, syndication or metadata processing - no one typically wants to "own". Why? Despite being where all the intelligence is and them being complicated, costly to develop and maintain and requiring a lot of expertise to get right, they’re still viewed as “low-value commodity components”. I mean, it’s so easy to go to market and buy a standard off-the-shelf "do anything" CMS right?
The result is that most service providers today buy commodity components off the shelf - but are using internally staffed teams to develop and own the front end. Seems sensible right? Well, I'm not so sure.
Any good front-end application or platform can only be as good as the back-end services that are feeding it. Whether this be editorial articles, video, audio, images and artwork or data. To date, despite a lot of trying, I’ve never been able to design an experience that a good front-end development team was unable to build. However, by comparison, I’ve experienced a HUGE number of projects that have had their time and cost budgets blown because of an inability to do something simple in the “commodity CMS”. Why does happen? It's simple to answer but often the elephant in the room. Fundamentally, a lack of due diligence or validation of technology, product or business requirements in these "commodity" components.
Despite a media and OTT market that is utterly littered with app developers and development houses that can build high-quality apps to almost any imaginable design, I still can't get my head around the fact that these front-end components are still viewed as the things that are critical to own - despite the underlying fact that the features and capabilities that make it to the front end, are entirely dependent and reliant on the bits that sit behind the scenes.
What happens next is a situation that we've all experienced first-hand. These commodity components that were so easy to buy off the shelf and didn’t warrant the time investment because they have no value or “all do the same thing”, are suddenly blocking roadmaps, generating increasing development costs and technical debt - as teams try to circumvent and resolve the simple thing they're trying to do on the front end.
This behaviour compounds and over time and starts to form most of the reason Quality of Experience (QoE) becomes a challenge. Proxies, abstractions and client-heavy engineering, instead of server-side logic winning out. Any and all means are used to bypass limitations in back-end services. Technical debt grows and grows.
Where do we close out? I'm always the guy arguing that the commodity low-value component, isn’t the back-end platform, but the front-end bit that is so easily built to any art of the possible design with any half-capable development team or partner. It’s fundamentally the bit that will never really block your ability to do something cool for your fans or audience.
The argument over putting more time, care and attention (maybe even having to "own") bits of the back-end platform, starts to make more sense. From experience, a CMS for example, is one of the single biggest impactful components in your solution - and one that fundamentally drives everything you do or will want to do on your roadmap that the consumer or fan will interface with.
What you do today, tomorrow and in three years is decided by the decisions you make over the platform that's sitting behind those shiny apps.
Maybe flipping the commodity model on its head is worth some extra thought?
In OTT platform development, what do we really mean by the term "commodity"? Are we all on the same page with the concept of what is "valuable", and should we be changing our thinking?
In OTT design and build projects, one of the topics that comes up often relates to bits of the stack that customers want to own, versus the bits they don’t - often described as “commodity”. If I’ve learnt anything from my 20 years in OTT, it has taught me that the term commodity is very much a subjective and not an objective point of measure. Let me try to explain.
The rationale of the perceived higher value bits of the chain (the “non-commodity bits”), and those that service providers want ownership of, are the direct touch points the consumer has with the service - the experience, the look and the feel. It stands to reason that apps and websites can be paramount to either the success or failure of the offering.
By complete contrast, many back-end services like video and content management, syndication or metadata processing - no one typically wants to "own". Why? Despite being where all the intelligence is and them being complicated, costly to develop and maintain and requiring a lot of expertise to get right, they’re still viewed as “low-value commodity components”. I mean, it’s so easy to go to market and buy a standard off-the-shelf "do anything" CMS right?
The result is that most service providers today buy commodity components off the shelf - but are using internally staffed teams to develop and own the front end. Seems sensible right? Well, I'm not so sure.
Any good front-end application or platform can only be as good as the back-end services that are feeding it. Whether this be editorial articles, video, audio, images and artwork or data. To date, despite a lot of trying, I’ve never been able to design an experience that a good front-end development team was unable to build. However, by comparison, I’ve experienced a HUGE number of projects that have had their time and cost budgets blown because of an inability to do something simple in the “commodity CMS”. Why does happen? It's simple to answer but often the elephant in the room. Fundamentally, a lack of due diligence or validation of technology, product or business requirements in these "commodity" components.
Despite a media and OTT market that is utterly littered with app developers and development houses that can build high-quality apps to almost any imaginable design, I still can't get my head around the fact that these front-end components are still viewed as the things that are critical to own - despite the underlying fact that the features and capabilities that make it to the front end, are entirely dependent and reliant on the bits that sit behind the scenes.
What happens next is a situation that we've all experienced first-hand. These commodity components that were so easy to buy off the shelf and didn’t warrant the time investment because they have no value or “all do the same thing”, are suddenly blocking roadmaps, generating increasing development costs and technical debt - as teams try to circumvent and resolve the simple thing they're trying to do on the front end.
This behaviour compounds and over time and starts to form most of the reason Quality of Experience (QoE) becomes a challenge. Proxies, abstractions and client-heavy engineering, instead of server-side logic winning out. Any and all means are used to bypass limitations in back-end services. Technical debt grows and grows.
Where do we close out? I'm always the guy arguing that the commodity low-value component, isn’t the back-end platform, but the front-end bit that is so easily built to any art of the possible design with any half-capable development team or partner. It’s fundamentally the bit that will never really block your ability to do something cool for your fans or audience.
The argument over putting more time, care and attention (maybe even having to "own") bits of the back-end platform, starts to make more sense. From experience, a CMS for example, is one of the single biggest impactful components in your solution - and one that fundamentally drives everything you do or will want to do on your roadmap that the consumer or fan will interface with.
What you do today, tomorrow and in three years is decided by the decisions you make over the platform that's sitting behind those shiny apps.
Maybe flipping the commodity model on its head is worth some extra thought?
In OTT platform development, what do we really mean by the term "commodity"? Are we all on the same page with the concept of what is "valuable", and should we be changing our thinking?
In OTT design and build projects, one of the topics that comes up often relates to bits of the stack that customers want to own, versus the bits they don’t - often described as “commodity”. If I’ve learnt anything from my 20 years in OTT, it has taught me that the term commodity is very much a subjective and not an objective point of measure. Let me try to explain.
The rationale of the perceived higher value bits of the chain (the “non-commodity bits”), and those that service providers want ownership of, are the direct touch points the consumer has with the service - the experience, the look and the feel. It stands to reason that apps and websites can be paramount to either the success or failure of the offering.
By complete contrast, many back-end services like video and content management, syndication or metadata processing - no one typically wants to "own". Why? Despite being where all the intelligence is and them being complicated, costly to develop and maintain and requiring a lot of expertise to get right, they’re still viewed as “low-value commodity components”. I mean, it’s so easy to go to market and buy a standard off-the-shelf "do anything" CMS right?
The result is that most service providers today buy commodity components off the shelf - but are using internally staffed teams to develop and own the front end. Seems sensible right? Well, I'm not so sure.
Any good front-end application or platform can only be as good as the back-end services that are feeding it. Whether this be editorial articles, video, audio, images and artwork or data. To date, despite a lot of trying, I’ve never been able to design an experience that a good front-end development team was unable to build. However, by comparison, I’ve experienced a HUGE number of projects that have had their time and cost budgets blown because of an inability to do something simple in the “commodity CMS”. Why does happen? It's simple to answer but often the elephant in the room. Fundamentally, a lack of due diligence or validation of technology, product or business requirements in these "commodity" components.
Despite a media and OTT market that is utterly littered with app developers and development houses that can build high-quality apps to almost any imaginable design, I still can't get my head around the fact that these front-end components are still viewed as the things that are critical to own - despite the underlying fact that the features and capabilities that make it to the front end, are entirely dependent and reliant on the bits that sit behind the scenes.
What happens next is a situation that we've all experienced first-hand. These commodity components that were so easy to buy off the shelf and didn’t warrant the time investment because they have no value or “all do the same thing”, are suddenly blocking roadmaps, generating increasing development costs and technical debt - as teams try to circumvent and resolve the simple thing they're trying to do on the front end.
This behaviour compounds and over time and starts to form most of the reason Quality of Experience (QoE) becomes a challenge. Proxies, abstractions and client-heavy engineering, instead of server-side logic winning out. Any and all means are used to bypass limitations in back-end services. Technical debt grows and grows.
Where do we close out? I'm always the guy arguing that the commodity low-value component, isn’t the back-end platform, but the front-end bit that is so easily built to any art of the possible design with any half-capable development team or partner. It’s fundamentally the bit that will never really block your ability to do something cool for your fans or audience.
The argument over putting more time, care and attention (maybe even having to "own") bits of the back-end platform, starts to make more sense. From experience, a CMS for example, is one of the single biggest impactful components in your solution - and one that fundamentally drives everything you do or will want to do on your roadmap that the consumer or fan will interface with.
What you do today, tomorrow and in three years is decided by the decisions you make over the platform that's sitting behind those shiny apps.
Maybe flipping the commodity model on its head is worth some extra thought?
In OTT platform development, what do we really mean by the term "commodity"? Are we all on the same page with the concept of what is "valuable", and should we be changing our thinking?
In OTT design and build projects, one of the topics that comes up often relates to bits of the stack that customers want to own, versus the bits they don’t - often described as “commodity”. If I’ve learnt anything from my 20 years in OTT, it has taught me that the term commodity is very much a subjective and not an objective point of measure. Let me try to explain.
The rationale of the perceived higher value bits of the chain (the “non-commodity bits”), and those that service providers want ownership of, are the direct touch points the consumer has with the service - the experience, the look and the feel. It stands to reason that apps and websites can be paramount to either the success or failure of the offering.
By complete contrast, many back-end services like video and content management, syndication or metadata processing - no one typically wants to "own". Why? Despite being where all the intelligence is and them being complicated, costly to develop and maintain and requiring a lot of expertise to get right, they’re still viewed as “low-value commodity components”. I mean, it’s so easy to go to market and buy a standard off-the-shelf "do anything" CMS right?
The result is that most service providers today buy commodity components off the shelf - but are using internally staffed teams to develop and own the front end. Seems sensible right? Well, I'm not so sure.
Any good front-end application or platform can only be as good as the back-end services that are feeding it. Whether this be editorial articles, video, audio, images and artwork or data. To date, despite a lot of trying, I’ve never been able to design an experience that a good front-end development team was unable to build. However, by comparison, I’ve experienced a HUGE number of projects that have had their time and cost budgets blown because of an inability to do something simple in the “commodity CMS”. Why does happen? It's simple to answer but often the elephant in the room. Fundamentally, a lack of due diligence or validation of technology, product or business requirements in these "commodity" components.
Despite a media and OTT market that is utterly littered with app developers and development houses that can build high-quality apps to almost any imaginable design, I still can't get my head around the fact that these front-end components are still viewed as the things that are critical to own - despite the underlying fact that the features and capabilities that make it to the front end, are entirely dependent and reliant on the bits that sit behind the scenes.
What happens next is a situation that we've all experienced first-hand. These commodity components that were so easy to buy off the shelf and didn’t warrant the time investment because they have no value or “all do the same thing”, are suddenly blocking roadmaps, generating increasing development costs and technical debt - as teams try to circumvent and resolve the simple thing they're trying to do on the front end.
This behaviour compounds and over time and starts to form most of the reason Quality of Experience (QoE) becomes a challenge. Proxies, abstractions and client-heavy engineering, instead of server-side logic winning out. Any and all means are used to bypass limitations in back-end services. Technical debt grows and grows.
Where do we close out? I'm always the guy arguing that the commodity low-value component, isn’t the back-end platform, but the front-end bit that is so easily built to any art of the possible design with any half-capable development team or partner. It’s fundamentally the bit that will never really block your ability to do something cool for your fans or audience.
The argument over putting more time, care and attention (maybe even having to "own") bits of the back-end platform, starts to make more sense. From experience, a CMS for example, is one of the single biggest impactful components in your solution - and one that fundamentally drives everything you do or will want to do on your roadmap that the consumer or fan will interface with.
What you do today, tomorrow and in three years is decided by the decisions you make over the platform that's sitting behind those shiny apps.
Maybe flipping the commodity model on its head is worth some extra thought?
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.