.NET migration strategies -
KUAM-TV in Guam

How a TV news station in the NeverNeverLand of high technology is deploying next-generation solutions to streamline its operations and service its viewers better


By Jason Salas, MBA, MCP
Web Development Manager, KUAM.COM

KUAM is Guam's largest and most diverse broadcast station, managing (2) radio stations, (2) television channels, and producing original TV programming, including our daily flagship newscasts. We launched our site (KUAM.COM) to be a complementary extension of our omnibus broadcast product in early 2000. As the station's main IT architect, I began researching Microsoft's .NET Framework about a year, to keep up with the challenge of staying on top of the market. As an ASP developer, I was interested in the newer challenges of writing dynamic code to streamline our operations, as a means of allowing us to work on other things.

I find .NET to be truly evolutionary over past incarnations of application development technology in the sense that we write a lot less code with a more object-oriented approach, and can get our information to our viewers in a very swift fashion. We can quickly design an app, write and deploy it easily, and move on to other things. In our business, time is everything...and we live for the moment when we go live for each cast. On almost a daily basis, we're faced with the daunting task of creating something really special, and really interactive...really quickly. And this is a hard thing to do on a consistent basis. Thus, we need rapid-response solutions. And when news breaks suddenly, we pride ourselves on being able to bring comprehensive, interactive coverage to our users worldwide. Cross-media integration is critical to maintaining our position as the local leader in online news.

The big question people have when I speak at functions or lecture about .NET is: so what does it do different than ASP 3.0? My main reaction is defending the position of .NET as not being revolutionary, but truly evolutionary. No one's written a new batch of COM rules or completely revamped HTML...it's process streamlining, integration, and interoperability that are the keys. It's making my job a whole lot easier.

We're deploying .NET applications to optimize performance so that users can access the information they want faster...in a way which is convenient and customized just for them - our objective is to develop the total user experience. By its nature, our homepage rebuilds itself 2 or 3 times daily during the course of a normal day, dynamically-regenerating itself to reflect the day's stories as we cover them. Our migration to .NET consists largely of using data access components as a means of managing our data store of written stories and archived streaming audio and video, and also with ASP.NET's Datagrids for administrative management of our content, both public and non-customer viewable. Combining custom .NET apps with other products like BizTalk Server, we're developing a robust publishing system to make our interactive journalism a snap, and for providing advertising statistics for our advertisers and revenue-sharing partners. I was impressed early on with ASP.NET's fragmented page caching, and we use that feature to further optimize performance.

We're really concentrating on making our stories as interactive as possible, and currently spending hours writing scripts and components is a big drawback. We achieve a lot of interactivity by use of Flash animations and JavaScript-enabled features - each of which being unique to a story - which take time to build in the course of the news day. Thus, we don't want to be bogged down with simple constructs and data management. So .NET satisfies our need to be able to develop robust, reliable applications quickly.
 
Being an NBC affiliate, we also do quite a bit of data exchange with MSNBC, brokering our information and likewise downloading their newsfeeds. We do this currently through a number of data channels, but ASP.NET's easy development interfaces allow us to revamp our existing systems for exporting data to partners.

No one's written a new batch of COM rules or completely revamped HTML...it's process streamlining, integration, and interoperability that are the keys. It's making my job a whole lot easier.

Being that Guam is so small, we naturally have a very small developer community. With .NET's language-agnostic approach, I can bring in or outsource Java and C++ developers and the relative learning curve is greatly reduced, more so than someone starting from scratch. They learn basic C# or Managed C++ syntax, and write apps to integrate with our Visual Basic.NET/C# platform. Our app schema is largely VB.NET-based for major applications, with several C# modules…and this is another key: the seamless integration with cross-language apps is terrific…those who prefer to write C# can keep doing so, and my VB.NET guys can keep writing their own code, too. It's all completely interoperable in the final wash when run through the CLR. This is a huge improvement to a problem I've got now of finding talented developers now with specific skillsets needed to expand our site. Also, custom configuration and session management is a lot more elegant by using global.asax and web.config files is much easier to write, manage, and monitor than in Classic ASP. We'll be using this progression in developing customized services, a "Your News" service of sorts. It's very customizable and scalable, and so much more easier to do, compared to traditional ASP programming.

We're also spending a lot of time researching and building XML Web Services. Very few things in IT got my attention as much as the XML Web services model, and so this is my personal favorite area of .NET development. We're planning several variations of data-centric software services stemming from our news and radio databases such as portable headlines, subscription-driven feeds, and giving people the ability to search through our archives for their favorite stories. Our current portable newsfeed service is cool and is currently in wide use, but is limited in the amount by which clients can customize the output data. They can apply CSS rules, but that's about it. With Web services, we simply expose the data to the consumer, and they build clients that filter, and/or evaluate the data in ways that are appropriate for them, and then write their own clients to display the data so they're completely satisfied with the finished product, which makes it more flexible to incorporate into their own sites. We're also doing much with certain developing the “software as a service” concept and using it for apps that aren't customer-viewable, for improving internal communications and business processes, really milking the B2Bi advantage. It's all really very exciting, and we're really anxious to start.

It's also a concern of ours to have a presence in multi-device and multi-platform markets, so we're also spending lots of time developing mobile solutions so that our outbound news will be more available via WAP, and also for internal communications. We've got a current mobile product through AvantGo that is very popular, but is limited in not being truly connected to the "Mobile Web". True WAP development gives us seamless integration among all outlets, not just the confines of the desktop PC. On that note, chief among my concerns is being able to let our reporters bring as much of our newsroom out into the field with them as possible. In the past, we've been limited to being able to work effectively due to geography...being physically distanced from our newsroom systems. Implementing componentized internal mobile solutions for our reporters will empower them to really keep in constant contact and literally let us work right up until the moment we go live on TV for our newscasts. This lets us deal better with the one factor that really works against us everyday - time.

While we'll still keep the majority of our Classic ASP apps in the short term, I project us being able to realistically cutover to a 40% .NET platform by October of 2002, and possibly 100% integration by mid-2003.

Yet, the learning curve is dramatically steeper than with previous technologies, and while we're obviously extremely excited about using .NET, more organizations here are hesitant to deploy .NET or will do so very gradually, which makes the true effectiveness and growth of our B2Bi-type apps stunted. Many developers I've worked with and talked to have a hard time grasping the true benefits of using XML, object-oriented programming and enhanced security, which is expected. So I spend a lot of time doing technical evangelism not only within my company, but also to the Guam business community's leading IT professionals and business managers.

Guam by its nature will always be a few steps behind the U.S. mainland, but we're doing what we can for the Guam macroeconomy in the round. Many people I've talked to about learning .NET programming naturally think it's a new version of ASP, meaning that the focus is on presentation. We're still bound by the abilities and limitations of HTML, but it's the ease of development for dynamic apps and ability to deploy and manage them that's the key for us.

Our sponsors
KUAM.COM - Guam's online source for news, entertainment, and information

This is Guam's first site produced 100% with the .NET Framework,
developed and maintained by Guam's top Active Server Page developers.

Microsoft ASP.NET

Copyright © 2001-2002 by the ASP.NET User Group of Guam. All rights reserved.
Terms of Use | Privacy Statement