Truenumber tip: Language versus database

If you’ve ever bought a part at an auto-parts store, you know that the conversation goes like this: “I need a battery for my 2011 Jeep Grand-Cherokee”. “OK, what model?” “um…Laredo 4x4” “Engine?” “it’s a six”.

Next time you order, you might save time by saying “I need an alternator for my 6-cylinder 2011 Jeep Grand-Cherokee Laredo 4x4.”. That’s a mouthful. In truenumber terms, it’s human language confronting a parts-store database.

That long sentence is a kind of reading of the screen the clerk ends up with on the computer. The database has column names like “model” and “levelName” for Grand-Cherokee and Laredo, but when we speak, the sequence of adjectives is what narrows down the many connotations we have for a given word. “Laredo” is a city in Texas (also Missouri and Montana), but “Grand-Cherokee Laredo” is pretty certain to communicate what is meant.

Keeping this in mind is helpful when writing truenumbers. A database specifies a particular thing by defining a table with columns named to mean something to developers,. Humans refer to a particular thing by stringing together words into descriptive noun phrase, and truenumbers are made from such phrases.

The SQL query “SELECT * from carTable WHERE levelName=’Laredo’ and model=’Grand-Cherokee’” will pull up the car from a database. In Truenumbers, searching for sentences where the subject contains “Grand-Cherokee Laredo” will do the same thing, without requiring knowledge of any schema or SQL. Unlike a schema, you can feel free to add more detail to your phrases when needed, because data will be accessed by search, not by specifying fields. So feel free to add “new” or “used” to your car when needed. No new database column needed.

MBSE needs Truenumbers

Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities. SysML is the accepted modeling language for MBSE, and the mission is to replace traditional engineering documents with a family of object models.

This diagram is an example of a complete, well-defined SysML Activity Diagram. What’s missing are the labels, which are arbitrary from SysML’s point of view, but without which we can have no idea what the diagram is about. Together with the comments SysML encourages us to write, these are really what determine the engineering content of SysML.

So the reality of MBSE is that engineering is still 100% expressed in natural language, supported by meaningful diagrams, which is a pretty good description of the engineering documents MBSE sets out to replace. The value that MBSE adds (and it’s considerable) is that information once locked in pages and pages of free text becomes more organized and accessible.

We could do much more to support Systems Engineering if we captured this natural language content in an organized and accessible way. This one sentence is enough to describe vehicle braking:

“In order to minimize stopping distance, the ABS system of a vehicle prevents each wheel from locking by modulating the braking force.” 

It tells us more than the diagram.  The phrase “ABS system of a vehicle’” identifies the system of interest, and  “minimize stopping distance” tells us the purpose of the ABS.  The phrase “prevents each wheel from locking” tells us what the ABS does, and “modulating the braking force” describes how it does it.  To make these statements more accessible, we can factor the one sentence into three:

“minimizing stopping distance” is the purpose of the ABS system of vehicle”
“preventing each wheel from locking” is the function of the ABS system of vehicle”
“modulating braking force” is an implementation strategy of the ABS system of vehicle”

Managing truenumber sentences like these complements SysML models by cataloging and organizing the expressive language that must always be present to explain the meaning and context of any model.

Look it up in the Index

Books have been the vault for knowledge since ancient times, and the web is inheriting that role. Books have an index in the back, and the web has search engines, both are ways to access information by content. Want to know about Bengal Tigers, search for “Bengal Tigers”. Whether an index entry or a search string, these are meaningful to humans, and act as keys for retrieving information. Data is content too, but the evolution of data for computers has gone down a different path. More like a filing system than a book, schemas, objects, or other kinds of models sort information in a particular way, accessed by column or table names, like the labels on file drawers and folders.

Like a wall of file cabinets, once you determine a schema for your data, you have to live with it for a long time. Different organizations or departments in an enterprise evolve their own filing systems or schemas. Electronic document stores allow more fluid schemes of tagging, and web-like searching of content, but structured data remains mostly filed by table and column according to a schema.

Indexing structured data by phrases similar to a book index or web search is a new idea. It turns out that there is nothing lost, and much gained relative to model-based data. You learn something by looking at how file cabinets are organized, but much more when you read over the index in the back of a book. With computers in the picture, queries and other computational tasks can be better than with schematic data because it is naturally indexed by content, and there’s more information to work with. We believe phrase-oriented data will be the way most structured data is represented in the future.

DEVOPS isn’t enough

“The US must have the ability to quickly respond to adversary advancements - rapid & continuous SW development will be essential to achieving this outcome.” - Defense Science Board

The DoD’s commitment to agile development and deployment (DEVOPS) has already shown that it can quickly create point solutions as needs and threats arise. But a barrage of incremental improvements can’t achieve the digital transformation of military processes required to meet the challenges of the 21st century.

“To conduct Multi-Domain Battle, all domains and warfighting functions must be integrated to deliver a holistic solution . Federated solutions will not work. We need a comprehensive, integrated approach inherent in our forces. The operational framework of the future is critical.“
- General David Perkins (TRADOC)

Just give them the facts

Why is development in the loop of military operations in the first place? It’s because the many different data sources, formats and databases required are system level technologies, so point applications are needed to deliver intelligible information to warfighters. This tightly couples DEVOPS agility to warfighting agility.

In business, this paradigm was disrupted by the spreadsheet. Giving users the ability to own and work with data directly took the COBOL application programmers out of the loop. Business agility and productivity skyrocketed.

Giving military operations direct control of information, in a universal form they can understand and work with (not spreadsheets), would be equally transformational. Situational awareness, communication and collaboration would involve command, intelligence and operations working directly with information, so far fewer point applications and updates would be needed.

Truenumbers can do it

Spreadsheets aren’t the military framework of the future, of course, but Truenumbers can be.

Devil’s Bargain

You don’t really remember COBOL do you? There’s a good reason for that. Back when enterprises first started keeping databases, the only way you could use them was to have I.T. write a COBOL program to generate a report for you. As users realized the power of data, requests for new reports piled up faster than I.T. could handle, and the “COBOL problem” became the I.T. hot topic of the day.

Paradigm shift to the rescue. Around 1980, the spreadsheet came along letting users commandeer a little data for themselves and play around with it as they chose to do calcs, reports, models, whenever they wanted. COBOL came off the critical path, and went back to batch processing in the back office. Business agility and productivity soared.

The devil gets his due. Of course, this kind of user empowerment didn’t come for free. The cost was loss of data integrity, and governance, errors increased, file and version management became big issues. The COBOL problem turned into the spreadsheet problem.

The uneasy truce. Thirty five years later, we are still balancing user empowerment with information integrity. Desktop software, Web 2.0 and big data have given users tremendous power and flexibility, but the devil’s bargain hasn’t changed: Users don’t get to have data. It remains remote as SQL, XML or JSON, in clouds, lakes and fabrics in the land of I.T.

The final frontier. But why is it that we can only touch data indirectly through applications? Why does it have to be kept out of sight in arcane, domain-specific vaults so that adding new kinds of data is like rebuilding the pyramids? There used to be good reasons related to hardware, performance and the needs of development, but with today’s tech, it’s just a bad habit, and the devil hopes you won’t find out. There is no reason users can have direct custody of data. All of it, if they want to. Sounds simple, but it’s a disruptive change far bigger than spreadsheets were, and is the true definition of digital transformation.

Truenumbers. It’s a way of representing data as individual facts, self-described in a structured natural language. so what they are, and what they are about are entirely up to you. No silos because truenumbers can be about anything in any domain. Immutable, individually secure and portable, truenumbers enable data integrity, compliance, security and governance far better than any back office system, and which extend all the way to the edge. Even in your desktop documents and spreadsheets. The devil’s bargain is broken, which is better for I.T. too. No longer tasked with translating data into schemas and writing code just to make it intelligible to users again, I.T. will build better and more interoperable systems much faster because they and the user community will finally be speaking the same universal language of data.