Just Enough Data Model: A Hero's Journey Into The Modeling World




The data modeling aspect of implementing the Future Airborne Capability Environment (FACE) Technical Standard continues to be a challenge for numerous organizations. The process is considered by many to be too difficult or intractable for new programs. Where past publications have discussed the mechanical difficulties of developing a data model, this paper illustrates some of the more philosophical and structural aspects of building a data model.


These concepts are introduced using an outlandish story that follows an engineer through the process of developing a data model. Along the way, it introduces the myriad concepts that modelers will face when building FACE™ data models. It also notes a couple of developmental milestones with an indication of the sufficiency of the model.


While this paper could be more concise and much more technical, abundant artistic license is taken to produce something that might be readable in a single sitting and that may prevent the premature death of an e-book reader succumbing to a sudden flood of sleep-induced drool. It is intentionally over-the-top. Data modeling is challenging topic and we are doing our best to have a little fun with it. While the technical aspects are intended to be taken seriously, the rest of the paper is not. Enjoy.

Day 1 - Introduction

Legends told of a man – nay, a hero – who towered three whole heads above all others. Every aspect of his existence was beyond compare.


One time, the entire engineering bay had tried to figure out when he arrived at work…and when he went home. It was as if our hero had a sixth sense. When someone got the idea to come in early – hero would mysteriously arrive earlier. When the team stayed late, he was the one who shut down the lab and turned out the last light. And then there was the time he discovered when the engineering team started a pool to decode his work schedule, subverted the entire effort, and won the kitty. One night, while the team went out to grab sandwiches, he programmed the lab robot with a facial recognition algorithm to greet everyone by name and hurl comical insults at them.


The hero, they said, never turned down a challenge and never lost a bet. Thus, when the company’s first data architecture project arrived, our fateful hero was chosen to bring his might to bear and build the data model. He graciously accepted the project, and rapidly consumed every book and article written on model-based systems engineering. He even sent an electronic copy of the FACE Technical Standard (Edition 3.0, of course) to a local printer to have it hardbound just so he could tell others that he literally read the standard “cover-to-cover.” And he did. Twice. He even read a silly, self-contradictory (yet oddly self-consistent) whitepaper about how hard it is to data model.[1]

“Drivel,” he thought and just as quickly dismissed the paper.


Fortunately, although not much was actually explained about the process, the FACE Technical Standard was very clear about where to start data modeling – the Shared Data Model. Per the standard, this model “provides the core extensible elements from which USMs are built.”


Hitting his favorite search engine (who are we kidding, our hero had developed his own search engine – 46696e64.com – that he hosted on an top-of-the-line BitCoin mining rig which he also built in his spare time), he searched for “FACE Shared Data Model” and was instantly rewarded with a link to the publicly released model on The Open Group’s website.


After downloading the FACE Shared Data Model from The Open Group’s public site, he opened the file to start reading it.


At this point, it should be mentioned that heroes of this caliber do not use the text editors of mere mortals. In a pinch, they might use something like Notepad++, but heroes of near immortal status have an ultimately powerful tool – emacs with a full complement of scripts and a complex assortment of key-combinations[2] with outrageous names like: Klingon death grip, iron hook and tap, the dynamo, the double-triple, meta-x-spook, and The Constable.After unleashing this secret weapon upon the shared data model, he looked upon the screen. What he felt in that moment, no one would ever know. Those looking upon his visage swear they saw fear. Some say they saw a single bead of sweat form on the edge of his brow. Others say it was a tear.


The lore that surrounds this very moment was memorialized with a simple plaque in the shape of a circle. In its very center, there was a dot and around the edge, the date was encoded – in binary – in the proper (and only logical) format day-month-year. Every single person in the lab (and even the lab puppy – which was a Labrador retriever – so yes, the lab’s lab) swore that the plaque was a circumpunct and represented how everyone rallied around the hero. Everyone knew, however, that it was a tear viewed from the top, as it – pulled by gravity – hurtled toward the floor to form a teeny tiny splash that, despite the minuscule amount of moister, washed the hopes and dreams of the team away for nearly two months.


Yes, friends, that day, the hero felt something he had never felt in his entire life. Was it fear? Doubt? Uncertainty? To be fair, not even our hero was sure because this was such a foreign experience. So, he did what he always did when confronted with discomfort: he took a step forward. He started studying the model – after all, how hard could a little XML be?


After a couple of minutes (and a couple of elisp macros to help navigate), he was comfortable navigating around the model, but that didn’t make it any easier to understand.


The Shared Data Model (or “SDM” as the professionals call it) is divided into two main sections: the Conceptual Model and the Logical Model. It was easy to discern between the two segments of the model since each element was labeled with either “conceptual” or “logical.” Furthermore, the model was organized by sets of opening and closing tags (after all, this is XML) which gave the model a hierarchical organization.


In the conceptual model, he found a number of “observable” nodes. This type of element only existed in the conceptual level. These elements were intended to correspond to physical phenomena that could be, well, observed. Despite have a reasonably complete set of physical things that can be observed – a list which contained everything from distance to speed to absorbed dose and even weird things relating to radiance – that is all it seemed to be. It did not lead to anything else.


This is a data model? He quickly filed the thought away and continued inspection.


Hero spent some time reading the definitions of the observables. It seemed as if the definitions provided some much-needed clarification on the meaning of the observables. The labels themselves were not descriptive enough, so, he reasoned, the ultimate meaning must come from the name and definition.[3]


Having read the standard three times, our hero knew that that he would find much more information about the observables in the Logical Model. This was one of the so-called variation points that the architecture was intended to allow. It just makes sense. And, to our hero, it did. But to the bystanders, to the mere mortals who were not privy to the inner workings of his mind, it was not nearly as obvious.


The structure of the data model was intended to allow software interfaces to be documented simultaneously at three different levels of abstraction. The most abstract representation is the Conceptual Model. This eponymous model is merely full of concepts. The concept of position is represented merely as the all-encompassing idea of position. The Conceptual model does not detail the position beyond the definition provided by the observable and the context in which it is used.


The Logical Model is a little more specific. It describes how the different observables are measured. Thus, things like coordinate systems and units are combined to define measurements. A measurement might define the fact that a Temperature (this is another SDM observable) can be measured using Celsius, Fahrenheit, or Kelvin. By accurately documenting this information, one can ensure that the proper units are used to express the value in an interface. And, since different systems can use different units, the measurements provide an acceptable variation point for developing a system using a data architecture.


The most concrete level of the data model is called the Platform Model. This model redefines the data in the way it is presented on-the-wire. Computers communicate in bits and bytes – not concepts. However, as most programmers have seen, some applications may represent a value as a float while others represent it as an integer or even a string.


Figure 1 – One concept may be represented in many ways at different levels of abstraction




So, just like our hero said, it just makes sense. In spite of the four times our hero read the technical standard, he printed out Figure 34 on Page 328. It was the key to understanding the logical content. (Yes, ladies and gentlemen, figure 34 is the equivalent of the Little Orphan Annie Secret Decoder Ring for the Logical Model. While it will most certainly not tell you to “Drink more Ovaltine,” it will make the clear the enigma that is the logical model.) This diagram shows all the relationships between the different elements in the logical level.


Hero looked around. The lab was quiet…everyone had gone home. As he stood up, he noticed something on the floor, so he leaned over to inspect it. Odd, I don’t remember eating anything purple and gooey today.


Those who have spent any time data modeling know what that purple goo is, but our hero was just beginning his journey.


Day 2 – Forming

Ideally, the second day of data modeling would have started after the day’s first cup of coffee, but things did not quite happen like that. Many times throughout the night, our story’s hero awoke in a cold sweat. Each time, he found specters of metamodel diagrams stuck in the corners of his mind extending their orientation attributes out to drain the life out of any wary modeler who dared to get too close.


At some unholy hour of the morning, long before the sun contemplated breaking the cool of the night, while headlights were not only a good idea, but an absolute necessity, our hero returned to the office.

Today, he would endeavor to build a data model.


After logging into his Linux boxen and firing up emacs (okay, it was Xemacs – and our hero still ran Window Maker because it was, as he said, “wickedly fast”), he loaded up the SDM and endeavored to create an entity.


Reaching into his project archive, he found the Interface Control Document (ICD) for the definitions of all the interfaces his system needed to implement – Open Stovepipe 42.


Hero turned to the first message:


Table 1 – Definition of fictitious Open Stovepipe Message 1