R2O | Research to Operations

In today’s era of “big data” permeating the meteorological community, it is easy to find examples of enterprise architectures that process, store, and serve weather information to the internal and external users. Implemented with the intent to further a strategy, and organize and homogenize processes, these enterprise architectures are multi-faceted in the purposes that they further. For example, a single instance of enterprise architecture must, at least, serve certain business or community requirements; meet information technology standards; integrate data models; provide access and customization for core users and related but diverse partners; and connect with applications. In a previous post, an ideal enterprise-grade platform for R2O was postulated . But are enterprise architectures always the right solution? Can they be “too big to fail”? And what are the implications for R2O? Proponents of enterprise architectures will revel about organizational, process, and information technol

Not all research byproducts that enter the R2O cycle exit it with a successful implementation in front of a practitioner. And while this is never an ideal scenario, this is not a failure of the process so long as the cycle has provided a rigorous testing and evaluation environment. Failures arise when research byproducts fail to reach operational implementation because the R2O cycle slows down or breaks down. In other words, the transition failure is the result of complications of the process itself, rather than an issue that is specific to the introduced byproduct. Collaboration and interdependence between organizational support, the research idea, and operational need have summarily described the fundamental mechanics of the R2O cycle, but these are very much first order descriptors rather than attributes of individual stages internal to the cycle. This is important to distinguish because too much interdependence within the cycle can thwart R2O activities by reducing the speed at w