TV TOKYO BUILDS COMMERCIAL BROADCASTING SYSTEM WITH LANSA AND JAVA
Editors Note: The case study below is based on a translation of a TV Tokyo case study that appeared in i Magazine in Japan. www.imagazine.co.jp
Commercial broadcasting systems are mission-critical systems for television stations. TV Tokyo (and TV Osaka) undertook a complete overhaul of the legacy System i commercial broadcasting system, developed over 20 years ago, to handle the switch to digital broadcasting on 1 December 2003. The project was led by TV Tokyo Systems, Inc., which is a subsidiary company of the TV network.
There were no commercial software packages that met the broadcaster’s specialized requirements, so the company opted for in-house development and selected LANSA as the development tool. The system was designed to be browser-based, except for the complex queue sheet processing that needed a Windows rich client/server interface. (Queue sheets are time allocation sheets that contain the structure of a television program from start to finish in units of seconds). While Java was used to develop the user interface with a strong visual element (1,060 programs) and batch processing was developed in CL/RPG (355 programs), everything else was developed in LANSA (3,200 programs).
- Aim of the Rebuild
- Reasons for development tool selection
- Project Challenges
- The Project in Hindsight
- Company and System Information
Aim of the Rebuild
The new system needed to let staff in the editing, sales, production, technical and other departments process a wide range of information from many sources, from basic program information to detailed broadcasting schedules, including television commercial sales slots, actual broadcast sequences and production costs. Ultimately by transmitting the broadcasting data to the transmission facilities, it enables the actual television programs and advertising to go to air.
The new system also had to support both analog and digital broadcasting during the changeover period from the initial introduction of digital broadcasting in 2003, until the final switch to digital-only broadcasting in 2011. In addition to handling the requirements of conventional analog broadcasting, the new system’s requirements included a wide range of completely new functions to handle the demands of the new digital era, such as the introduction of datacasting and the building of EPGs (electronic program guides). Definition of requirements started in July 2001 and the system became operational in March 2004.
Reasons for Development Tool Selection
Due to the strict deadline, productivity was a major factor in selecting the development tool for the project. As it had been decided that the iSeries, which had been in use for many years at TV Tokyo, would continue to be used, only development tools with the highest level of compatibility with the iSeries, mainly 4GL type tools, were considered.
Not only did LANSA have a good track record with the iSeries, the evaluation process also identified a number of key points that led to a positive evaluation and the selection of LANSA. These included the facts that “The syntax of RDML (LANSA’s development language) is similar to CL, so it is easy for RPG developers to adopt”, that “web as well as client/server applications can be developed in RDML and are reusable in other scenarios” as well as “Providing templates and common subroutines, repository registration tools and the like makes development productivity high”.
Project Challenges
The initial target for implementation of the new system was December 2003. It was felt that the approximately two and a half year period from July 2001, would be sufficient time to complete the project in time for commencement of digital broadcasting. However, this did not prove to be the case, due to a number of unique factors.
In addition to the huge scale of the development task, with over 4,600 programs in total, an operations system had to be built to support digital broadcasting, which at that point in time was a completely new situation. No one had any experience with the new operational requirements. It was therefore an extremely unusual situation as it was not possible to accurately define the requirements for the project at the start.
As a result, the requirement definition process was very protracted and changes to the specifications occurred frequently and continued even after development had commenced. On a number of occasions, already completed work had to be redone. Major delays in the development schedule occurred compared to the original plan and an increasing number of staff were brought in to make up for the lost time.
The project was led by TV Tokyo Systems, Inc., which is a subsidiary company of the TV network and while SE Laboratory and IBM Japan were in charge of LANSA technical support, three other companies were jointly responsible for the actual development. The project started out with a 16-person team, consisting of eight staff from TV Tokyo Systems, Inc., and eight staff from the three cooperating companies. At the project’s peak, the development team had grown to over 100 people and that team structure continued for almost six months.
Work on the TV Osaka development project, which had different application specifications and hardware requirements to the TV Tokyo project, was also done in parallel with the TV Tokyo development. This doubled the volume of work.
The more people are involved in a project, the more difficult communication becomes. Gaps in communication occurred, blowing out the development schedule even further, creating a snowball effect. One example was different decisions made by individual company teams on whether to implement record locking either before updating the database or before displaying the data on screen. In most cases, the cause of such conflicting decisions was a lack of time to fully communicate with all of the developers in the different companies.
In July/August 2003, TV Tokyo Systems, Inc. decided to reorganize the project team to better manage changes to the requirements and reduce redevelopment work. Five people were appointed from various divisions of TV Tokyo as the key operational leaders to work full-time on-the-ground with the developers. The intention was to make management of the project smoother by giving these key personnel authority and responsibility for making decisions on the detailed specifications on site.
This organizational change proved successful and the commercial broadcasting system went operational in March 2004, only three months behind the original target date. The system was then fine-tuned for another six months after implementation.
The fact that the “pure development period” accounted for only about six months of the actual two-and-a-half-years of the project, gives an idea of just how arduous it was to manage the requirements specification for this project.
The Project in Hindsight
Looking back on the project, Mr. Kazuyuki Nakama (Deputy Manager, Operations Department, TV Tokyo Systems, Inc.) comments, “It is very difficult to define the requirements for a completely new type of system. That is why I now think that we should have established the system of having key personnel stationed on site to decide on the requirements earlier.”
“Also, when there are large teams involved, there tends to be a lack of communication and it inevitably takes a long time to get decisions made. The project should be led by a select group of four to five key people, including a leader acting as the “control tower,” to coordinate everything, including the definition of requirements.”
Mr. Nakama, while acknowledging the high degree of functionality of the LANSA product, notes that one area for improvement was a lack of training for TV Tokyo’s staff. Because they were initially not directly involved in the actual development, staff had little choice but to commence this project without a thorough understanding of LANSA. Therefore, they could not take full advantage of the LANSA Repository or achieve maximum productivity.
Mr. Nakama feels that through the company’s initiatives to improve productivity, such as creating templates and programs that could be used commonly throughout the system, and creating tools to register huge volumes of repository data efficiently, the number of man-hours was less than half of that compared to RPG.
While the company attempted to improve development productivity by standardizing the screen structure and creating templates that met the operational requirements, there were a host of cosmetic changes demanded by the end users after the programs were generated. Thus, the templates had to be customized to accommodate these demands, all of which hindered productivity.
“It is important to explain the major features and constraints of using LANSA templates to the end users and gain their understanding in advance that programs generated from templates should be used “as is” like a black box. When you incorporate checkpoints in your workflow to make sure you get the design decisions right in the template, you have a very productive development environment.”
“It is important to specify the requirements in sufficient detail during the design stage,” concludes Mr. Nakama.
Company and System Information
- TV Tokyo Corporation, part of the Nikkei Group, is a major TV broadcasting company in Japan, broadcasting to over 32 million households or about 70 percent of the entire nation.
- TV Tokyo uses an IBM iSeries model 830
- For more information, please visit: www.tv-tokyo.co.jp
- TV Tokyo Systems, Inc., was established in 1987 and is headquartered in Minato-Ku, Tokyo. Its capital is 10 million yen, with a turnover of 1.22 billion yen and it has 25 employees.
- TV Tokyo Systems Inc. provides services related to software planning, development, management, consulting and network management for TV Tokyo and other Japanese TV networks.
- For more information visit www.systx.co.jp
