Blog

You might have seen the recent news reports about the collision between U.S. and Russian communication satellites. The U.S. satellite was one of the Iridium satellites. What wasn’t reported and you probably don’t know is that an object database management system (ODBMS) is an important part of the Iridium system. Even though ODBMSs are a bit off-topic for this blog, it is a technology with which I’ve been involved since the late 1980s. So, I’m adding some technical detail to this story.

The Iridium system includes over 66 low-earth-orbit satellites. That low orbit makes it possible to use low-power devices with a small antenna on Earth (satellite phones). Low orbit also means that Iridium satellites orbit the earth in less than 90 minutes. So during a typical telephone conversation, messages must be dynamically rerouted from one satellite to another. The Objectivity/DB ODBMS is used in the Iridium base stations for the message routing as well as network management. The developers described the Iridium switching problem as the equivalent to re-configuring an ATM switch every 4 minutes.

My understanding is that the part of the Iridium system that uses Objectivity/DB had nothing to do with the collision. Nevertheless, as it turns out, a new system is in the works to manage collision avoidance in space that uses Objectivity/DB as well. It is the Space High Accuracy Catalog (SHAC) project that will be deployed by Lockheed and used by the Joint Space Operations Center at the Vandenberg Air Force Base in California. The new system will provide improved collision avoidance and real-time tracking of hundreds of thousands of objects and debris in space. The goal is that decisions about spacecraft placement and collision avoidance can be made in seconds, rather than hours or days.

I am now also posting on the Cutter Blog. My initial posting is (The Acronym) SOA is (Perhaps) Dead (at Some Companies); Long Live Services. It is a response to Anne Thomas Manes’ SOA is Dead; Long Live Services on her blog at the Burton Group.

The typical definition of an atomic task or process is one that cannot be decomposed further. This is vague and subject to interpretation. The Decomposition Matrix on this site uses a specific definition: A task (for business process diagrams) or a process (for data flow diagrams) is atomic if every input relates to every output in the Decomposition Matrix. In other words, all cells in the matrix are checked. Each decomposition that is displayed on Results page at this site indicates whether any further decomposition is possible. That information appears at the bottom of the Results page. The Results page also sets up a sub-matrix for further decomposition should you want to see the next level of decomposition. One of the earlier Blog postings has an example.