As a nerdy 12-year-old, my favourite book was the Book of Heroic Failures by Stephen Pile, a chronicle of human inadequacy in all its glory. The highlight of this book for me was the tale of Pedro Carolina, a man who endeavoured to develop a Portuguese-English phrasebook. A noble cause which was hindered only by his lack of ability to speak English and lack of a Portuguese-English dictionary.
He did however possess a French-English dictionary, a Portuguese-French dictionary and a truly can-do attitude. The results of his labour were of no benefit to Portuguese holidaymakers but reduced a 12-year-old me to hysterics of laughter. I cheerfully recall this story often, but it was only when I started working at Ortelius that I started to draw comparisons between myself and Mr Carolina.
I work as an Information Modeller. The job of an Information Modeller can be glibly summarized as turning reality into something that can be stored in a database. This is done by designing information models. Traditionally in software design there are three types of information models: Conceptual, Logical and Physical. You start with a Conceptual model which is a high-level description of what we want to digitize and how they relate to each other. You then move to a Logical model which describes how these objects would ideally be created in a database. Finally, you implement this in a physical model which is an actual implementation of the database with data maintained by users.
This is conventional wisdom for information modelling but whether this approach is fit for purpose is open to question. What makes the tale of Pedro’s phrasebook funny is how obviously inappropriate the methodology was and objectively poor the results were. It is the linguistic equivalent of eating soup with a fork. But when the subject is more obscure, it is harder to divine how and when the methodology is flawed.
The first issue with the conventional approach is that the first two models (Conceptual and Logical) happen only on paper. They remain an untested theory until the expensive and complex task of implementing the Physical model begins. This is then compounded by the incompatibility in form of the differing models.
‘Most enterprise systems are relational databases which deal with binary connections between tables of data. But people have a much more fluid and nuanced way of visualising how things are connected. That is why conceptual models represent information as visual equivalents of a sentence (object – verb – subject). The gap between these two layers of abstraction should not be underestimated, and a lot of expense is incurred when a paper-based model meets the limitations and reality of software development.
It was joining Ortelius that prompted this realization for me. Using Ortelius’s software, inorigo, the first time I had worked with graph database functionality. A graph database works in the same way as a Conceptual model in that it reflects objects as nodes (objects) and edges (relations between objects) allowing you to connect things as you would in natural language.
For the first time, I was able to build and test conceptual models with the same format and relations as they would have in a drawing. This enabled hypothesis testing on a high-level long before any development work began. This approach made me a better Information Modeller and made me reassess a way of working that I once considered fundamental to the development process. A result of stress testing models in a graph database is that you can see where they fail, forcing you to consider how they can be improved. Countless iterations of this process have had profound effect on how we at Ortelius think about information and provide the foundation for what we offer our customers.
Author: Ferdia Kehoe, Information Modeller at Ortelius