Squared Away
Whether responding to natural or man-made disasters or other incidents, a centralized and pervasive notification system requires a stable yet scalable back-end environment.
At the Coast Guard, we implemented the Alert and Warning System (AWS) so that the agency could reach the maritime community through multiple redundant channels in minutes, instead of hours, with detailed information for safe courses of action before, during and following an incident.
AWS is making a big difference in improving the Coast Guard's communications and coordination internally and with other agencies, the maritime industry and partners. It took quite a bit of planning and research, however, to develop a system that meets our needs on a tight budget. Here are three best practices we learned along the way that might help your agency:
Plan and design your IT system to be scalable.
Before the Coast Guard had AWS, it used very-high-frequency (VHF) marine radio broadcasts, faxes and local phone trees. These were ineffective and costly avenues for relaying information to execute our missions.
In 2007, the Coast Guard launched the initial AWS project. We began small for two reasons. First, the project had limited funding and resources. One advantage? The small implementation for the first version of AWS allowed the Coast Guard to evaluate a prototype system before ramping up widespread use. Second, the minimum requirement was to enable the Captains of the Ports to communicate maritime security-level changes to the maritime industry, as outlined in the Maritime Transportation Security Act of 2002. The agency decided to provide this alerting and notification service to 25,000 maritime partners and stakeholders.
The tool worked well, and the Coast Guard kept expanding AWS. By the end of 2009, the system had gained an additional 25,000 Coast Guard users, allowing operational commanders in Coast Guard districts and sectors to reach other Coast Guard personnel and maritime partners within their areas of responsibility.
Since then, AWS has been used to manage Coast Guard and federal responses to several crises, including the Deepwater Horizon oil spill, last year's earthquakes in American Samoa and Haiti, and the March earthquake and tsunami in Japan.
Currently, we are planning to expand AWS use to 50,000 Transportation Security Administration officials and TSA airline partners. The new capability is expected to be in service by the end of September.
After comprehensive market research and a detailed alternative analysis, the Coast Guard bought commercial mass notification software that can run on the existing IBM blade infrastructure because the solution is scalable and easy to manage.
The Coast Guard made the decision to own and operate its own hardware and infrastructure, so that our developers would have better control over managing installation activities and controlling software configurations.
Developing and deploying a new group of users in AWS is simple and requires minor software configurations. If there is a need to upgrade the infrastructure, the system can easily scale up by adding blades and additional network and phone lines.
Design and build your IT system to be flexible and to take on new requirements within system limitations.
It is challenging enough to develop and deploy a system that fully meets the requirements, but in today's dynamic environment, it is getting much more difficult to design and deploy systems under evolving system requirements and changing user needs.
Early on, the Coast Guard saw that AWS could be a powerful communications tool capable of supporting a broad range of missions beyond maritime security. For that reason, the AWS team searched for an adaptable commercial product that it could manage centrally and modify easily. Because it is a centralized web serverÂbased system, there is no need to radically upgrade hardware or install special software at local commands.
Also, the system deployment can be done in top-down fashion, in which Coast Guard developers determine when and how the system will be implemented or upgraded without affecting local operations. Often, developers can work with users to configure software to meet their specialized requirements.
It makes sense to keep software configuration requirements to a minimum and avoid making changes to source code or core components. That makes periodic system upgrades and security patches simpler to implement. Plus, agency developers can then create a unique data hierarchy to reflect current command structure or create a new hierarchy without making changes to underlying code or core components.
— Lt. Cmdr. Ted Kim
Make your system easy to use and maintain, which will reduce operational and maintenance costs.
Another reason to adopt a commercial product is because the lion's share of IT lifecycle expenditures typically goes toward operational and maintenance demands. In the case of AWS, the Coast Guard set two requirements to drive down these costs: The system had to be easy for its operators to use, and it could not require professional IT support at the local level.
Making that happen requires work up front during a systems implementation. Coast Guard developers worked closely with AWS operators to design easy-to-navigate interfaces as well as agencyÂspecific texts and AWS terminologies that would reduce initial and continuous training costs. To optimize learning, the team also developed a basic training package that consists of web-based live training and an online help guide.
Using online tools that can be hosted centrally will also keep costs low. The Alert and Warning System is a web-based application that can be accessed over the existing Coast Guard network through the agency's standard desktop or notebook system.
Avoiding hardware upgrades at the local units saved a lot of money on materials now as well as on managing equipment down the road. All security patches and system upgrades are done at the central level.
With the creation of the Alert and Warning System, the Coast Guard operational community has embraced network-centric security and emergency communications. The centralized server-based system replaced a cumbersome nonstandard notification process that depended on a string of actions across many levels of the organization. There were too many potential single points of failure.
