I returned late last week from attending Akamai Technologies’ first Global Customer Conference in Boston. Intended to bring together Akamai’s major customers, in order to share knowledge and information about current and future Akamai products, I think I derived more insight out of my conversations with other media & entertainment customers than out of the program material. I’ll explain why.
CBC has been an Akamai customer for over seven years, and we are quite familiar with the products and services. What I found more valuable was the opportunity to network with my peers in online media & entertainment and digital broadcasting, to see if we share the same challenges As a result, I have come to three common conclusions about all of us:
- We’re all unsure about what will be successful online. While we all pretend that we know what we’re doing, we don’t. There are going to be some bumps ahead, some of them serious. It remains to be seen which ones are going to be fatal.
- We all struggle, with varying degrees of success, to wrangle corporate IT departments into playing nicely with "New Media".
- There’s still no good model for broadcasters to make money on the Internet, at least not to a level that compares with traditional terrestrial services.
There’s also a fourth conclusion, but I’m not sure whether other broadcasters have arrived at it yet: The broadcast side is changing quickly from a tape-based to a file-based workflow, and the new media side of the business is poised to reap the rewards — if only we can bridge the gap between IT engineering and broadcast engineering domains.
The potential success of new media depends on the successful resolution of conclusion #2. So much so that I’ll spend the remainder of this article discussing it. You can either accept or reject the other conclusions as fact; I may return to them in future entries.
The way in which broadcast new media has been implemented is far different than how traditional terrestrial media lines evolved. A quick timeline of the last sixty years of the CBC, for example, will illustrate why:
- 1930’s and 1940’s: Radio broadcasting begins. Radio engineering and maintenance is its own department (obviously, since there is nothing else)
- 1950’s and 1960’s: Television broadcasting begins. Television engineering and maintenance are also their own department.
- 1970’s and 1980’s: Digital revolution. Computers and computer networks become widespread, and corporate MIS/IT departments come into being.
- 1990’s and onward: Inception of the Internet and new media era. Natural alignment with corporate IT and many new media technologies are deployed and managed by IT departments.
As you can see, new media, as a media line, came into being not with its own domain-specific engineering and maintenance departments, but closely aligned with corporate IT — the same department that is most familiar with traditional corporate services like desktops, printing, file sharing, and e-mail. No wonder there is a constant conflict! New media is a business line that wants to try everything new (see conclusion #1) without knowing how things are going to work out; they can’t pay substantial amounts of money for it because they’re not profitable (see conclusion #3) and they don’t play well within the corporate IT box of stability, sustainability, and a conservative rate of change.
In my conversations with other broadcasters, this friction was a recurring theme. Like the problem statements, I can offer three possible resolutions:
- Outsource all new media activities and infrastructure to a separate company (or even a group within the corporation). Do not abide by corporate IT principles, and potentially host the equipment off-site; or
- Abide by corporate IT principles, and try to convince traditional, conservative corporate IT to accept change, flexibility, a desire to try new things, and a higher tolerance for risk, not as a rule, but as an exception for new media; or
- Create a separate engineering group for new media, either as a division of broadcast engineering, or on its own; establish common standards for interoperability with broadcast equipment (to a great extent) and with traditional MIS services (to a lesser extent).
Most broadcasters have already chosen options #1 or #2. I am an advocate of option #3. There are significant negatives to the first two options. The major negative to option #1 is that tighter integration with new file-based broadcast workflows requires tight coupling with new media infrastructure, something which may not be possible if that infrastructure is not built to a common standard (or even residing in the same building!) On the other hand, corporate IT departments can be reluctant to adopt any changes as per option #2, since there is no business imperative to do so. Senior IT management says, "Why should I make an exception for new media? They don’t make any money for this company."
Sadly, the majority of broadcasters (present company included) have adopted option #2, whether consciously or not. Many managers still retain the attitude that "the computers that run the website are just like the computers that run our accounting system", and new media doesn’t yet make enough money for them to make the distinction. This causes no end of frustration for the staff.
Frankly, I’m not too optimistic for the near future. Until someone recognizes the need for option #3, the situation is likely to get worse before it gets better. "Worse" would be a situation where new media suddenly starts making a lot of money, but the traditional IT department can’t meet the business demands due to lack of domain expertise. It’s a revolution waiting to happen, and at the end of it, I predict that many broadcasters will just end up with option 3. It’s just a question of how quickly we’ll get there and how much pain will be involved.