R2O | Research to Operations

With R2O posited as central to the evolution of an organization’s operations, the exact purpose of proving grounds and testbeds within a transition cycle is easily blurred beyond the immediate objective of demonstrating research in the operational setting. But make no mistake; senior leadership and managers are responsible for establishing strategic and tactical priorities and guiding all activities within the organization. It is not the place of R2O processes or actors within R2O to challenge the proposed direction, or potentially more detrimental, shallowly confirm them. Instead, activities that occur as part of a transition cycle should inspire new avenues for an organization to explore in achieving its mission. This may seem like a fine line, but the core difference here is evidence. There are several forums within the R2O process that provide evidence about how practitioners are responding to new scientific research and technology. This evidence should be carefully collected and a

Achieving the right meeting content, structure, and schedule is difficult, regardless of the nature of the organization. Meetings on topics related to R2O are sometimes even more onerous to plan, because the participants are diverse in their function. Yet they are necessary to ensure active communication throughout the process. But who should be invited? What should be talked about? How long should they last? Should participants present slides? While there are no simple answers for any of these questions, there are certain considerations that can contribute to better decisions about planning a meeting within the R2O community.   Establish the topic(s) first, attendees second, and length last. It is important not to position meetings for failure before they begin, and unfortunately, focusing on the attendees and length without a clear outline of what needs to be discussed or accomplished is an impediment to engagement. Meetings should have the least number of people participating as po

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 signifi

Though R2O activities are complicated by their cross-organizational span, they should not exist in isolation. The vision and strategy from senior leadership of primary participants should establish top-level priorities for R2O tasks in concert with learning and technology evolution plans, including, in the case of the meteorological community, observing system enhancements. Technology should provide a framework or impetus for R2O transitions, and some transitions may require updates to software or hardware independently. In addition, R2O must also take cues from the learning community, and vice versa, to assure that user organizations that sponsor the R2O process, and train practitioners, are meeting their purpose. Today, many organizations have Chief Executive Officers (CEOs), Chief Learning Officers (CLOs), and Chief Technology Officers (CTOs), but the concept of a “Chief R2O Officer” in the front office does not yet exist, in part because the R2O era is young and the risks and benef