R2O and technology are mutual enablers

Designing and deploying software that meets the reliability and performance requirements of an operational environment but the flexibility needs of ongoing development and R2O transitions is not easy. It is even more of challenge if designing the technological solution precedes any other evolutionary activity.

The National Weather Service (NWS) uses the Advanced Weather Interactive Processing System (AWIPS) as their primary weather information visualization and dissemination tool. The original AWIPS software was very modular. Different decoders were written for different types of weather data. Decoders did not share a common design template and were generally not reliant on other portions of the software.

Within the past decade, the software was upgraded into a service-oriented architecture (SOA). SOA has been heralded as a way to organize and reuse capabilities. As part of object-oriented programming of plug-ins and fragments, an improperly devised and implemented SOA produces significant interdependencies within the software. These interdependencies can make it difficult to troubleshoot issues. Furthermore, for large software projects, changes to existing methods within the software can lead to unintended consequences because testing all of the functionality that relies on a modified method is difficult and timely, while new methods risk duplicating existing functionality if there is insufficient documentation. This can make SOA software less desirable for operational environments despite the development and business benefits of having a core set of utilities.

The deployment of the migrated version of AWIPS was delayed years, likely because the task to convert all of the existing functionality from the early version while maintaining the reliability and performance requirements proved unwieldy for such a large software system. That is not to say that some technology evolution for AWIPS was unnecessary. After all, the original software was designed in the 1990s and the codebase was stale. However, the process of architecting and migrating a new AWIPS began before it was understood how the users had evolved, what today’s meteorologists needed from the software, and why an evolution was necessary from the broader corporate, if not community, perspective. If a technologist or software architect had looked at the evolution of the organization and practitioners that ultimately use AWIPS, the modus for change would have encompassed the mission beyond simply software maintenance.

In the weather community, technology falls into one of several major categories, and software like AWIPS, for visualizing weather information, is just one such category. Observing systems, including ground-based in-situ weather stations, Doppler radars, and satellites; complex computing, for running advanced algorithms and numerical weather prediction models; and dissemination or networking, for moving information within the community or out to the public are other technologies that are necessary to contemplate vis-à-vis the organizational mission. Each category has its own governance, but R2O should be considered as part of technology evolution within and between each category, because the categories are not disparate. For example, improvements in observing systems require more computing power and increases network demands to deliver imagery and products for visualization.

The support between technology and R2O should be mutual and somewhat balanced. Underlying a successful R2O process is a technology evolution strategy that enables activities within portfolios matched to the organizational mission or community goals. While the costs for technology that directly aids R2O activities should be strongly considered against other budget lines, R2O managers must be mindful of properly allocating funds for sustaining technology for broader consumption beyond R2O. Enterprise technology can be tremendous if it enables research, operations, and the transition so that all three are sustained. But shorting one of those areas can be problematic.

It is also problematic to lose sight of this dynamic balance. It is not unusual for managers to have genuine concern over whether the technology that is in place is “cutting edge” for their organization. But this line of thinking is a bit idealistic because it does not consider what is relevant. We have not wholly abandoned pens and paper in place of electronic tablets. Managers must first be able to clearly articulate what capabilities meet or further the mission and why those capabilities are important, an area where R2O can be beneficial, instead of trying to jump to provide the “how”. Those details are necessary for devising the right technological solution.