Like most boys my age at that time, I wanted to be an astronaut. Fate, however, intervened, in the form of nearsightedness, so I had to find an alternative occupation.  Coming to my rescue for the launch of Apollo 11 was my father, who presented me with a huge booklet that broke down the entire mission into each of its key components in great detail.  I had my answer – I was going to be a flight controller, and maybe even one day a flight director like Gene Kranz.  I had the entire Saturn V launch sequence memorized from the transfer to internal power at the T-minus fifteen minute mark down to liftoff, and would impress my father by beating the public affairs announcer to the punch by announcing, “initiating automatic sequence in 5, 4, 3 …”

A fascinating book came out last year called, “Go, Flight!: The Unsung Heroes of Mission Control".  In the process of telling the personal stories, recounting the heroic events, and describing the various roles in the mission control center (MCC), one recurring theme caught my attention – that of the communications (comms) loop.

The three primary roles in the MCC are:

• Flight Controller (FC): The lead specialist for each major function, with separate FC roles and consoles for systems such as guidance, flight dynamics, communications, power, and for the ISS, payload experiments, the robotic arm, and docked vehicles. Their console (today) will generally consist of a primary workscreen for access to procedures, flight rules, timelines, etc …, several other system telemetry / status monitors, and an audio monitor with headset – the Comms Loop.
• CAPCOM: Short for ‘capsule communication’ from the early days, this is the sole channel for direct communication with the spacecraft.
• Flight Director (FD): A senior management-level position - the flight director is the person ultimately responsible for the spacecraft. All commands to the vehicle must be approved by, and typically go through, the FD.

Communications is structured though various loops or channels:

• The Flight Director’s Loop, the central communication channel, consisting of the FD, the FCs and CAPCOM.
• The CAPCOM, or Air-to-ground, loop, where CAPCOM, typically a fellow astronaut, communicates between mission control and the spacecraft.
• FC-specific loops. An example might be a Guidance Loop during a launch, where the guidance FC is in contact with support personnel elsewhere in mission control or at the system's contractor’s headquarters, where more detailed answers can be had.

To see how this works, take a listen to the riveting final minutes of the first lunar landing, where you can simultaneously hear both the Air-to-ground and the Flight Director’s loops.  It doesn’t take long to realize why these loops are kept separate – can you image trying to concentrate on landing while having to listen in on all the mission control chatter as well?

To further complicate the matter, the FC’s or the FD might be on multiple loops simultaneously, sometimes up to as many as eight different channels at the same time. For example, during the power-up of a payload experiment, the ISS Power FC would be paying close attention to that activity as it might affect the electrical power systems, along with also always being active on the FD loop, their support team loop, and listening in to Air-to-ground.

It’s no different in your organization. Marketing needs to know what both sales and R&D are doing.  Production wants the status of raw materials from suppliers, products coming out of R&D, and how products are performing out in the field.  Customer service needs shipment and invoice history along with product spec and warranty data. Sales needs that same shipment and invoice data to match with their CRM.  And senior management wants all the above on the FD loop.

How are you going to support and implement such a complex data, communication and BI platform?

One way is through data virtualization.

Data virtualization is the effective response to data silos arising through mergers and acquisitions involving disparate platforms, middleware, applications and database systems, the implementation of a distributed data policy, or from the elongated state of coexistence between traditional and newer technologies – "heterogeneous architectures" – as they overlap during growth and transition.

In this fragmented environment data, virtualization provides a virtual, secure view of your data without moving it. Business users get an abstracted view of the data where the data sources can be modified without changing any of the business logic, and more importantly, the business users cannot write/modify/corrupt the source data.

To the business user it appears as if they are accessing a single data warehouse – the data virtualization software gives the impression that data is integrated and stored in a database when in fact it is not. It just looks that way. Using this software it is possible to create multiple virtual views of data from multiple underlying internal and external data sources to present data as if it was integrated. When queried by applications and tools, this software then integrates the necessary data ‘on-the-fly’ at run-time to serve up integrated data on-demand.

For a detailed explanation of how data virtualization works and how it can be applied to everyday business processes such as marketing, operations, logistics or service, check out “Data Virtualization – Flexible Technology for the Agile Enterprise”.

Anyone can build a single comms loop and make it work through brute force, but building, integrating and then sharing the multiple comms loops necessary to launch a moon rocket, manage the ISS, or run a complex business effectively, competitively and profitably requires a level of integration most readily achieved via data virtualization.