The Discovery of Attributed Directed Graph Databases
End of 2013, I discovered attributed directed graph databases, a kind of mix between semantic graph databases and relational databases. I remember that we were discussing the topic of the use of object-oriented databases in PLM software with a friend of mine.
I was searching (again) for better ways to develop business enterprise class applications. For me, an old software engineer, developing enterprise applications is still painful enough for us to think about what could be changed in our way to do it. That’s what engineers do: they try to do it better.
I know that nowadays developers are obsessed with hypes and new changing fancy technology. But the fact is most of the companies today cannot rewrite this core systems (very often written in Cobol on mainframes), just because, overall, it’s too complicated.
“Typed Rows” Linked with “Typed Foreign Keys”
Suddenly, nodes were having types (or labels usable as types) and were containing typed fields. They were objects/concepts that did not contain any information about their relationships to the other objects. The relationship information was another kind of artifact: the relationship. It also had a type and typed fields.
I was using graphs in modeling for a long time, in free-style graph diagrams for systemic or dependency analysis (with Yed, CmapTools and Compendium mostly) then with semantic-like graph diagrams (with Yed for enterprise project portfolio problems, roadmap building or architecture analysis) then with graph models such as those realized with the Open Group Archimate modeling language (with Archimatetool mostly) for enterprise architecture based projects.
Indeed, at this moment, I was already a “graph believer” because manipulating instances of node types and instances of relationship types were enabling very powerful, accurate and semantically exact representations. If you added the capability of working on a single graph model with multiple views, each of them representing a part of (or a view on) the same graph, you had the most powerful modeling tool ever.
The fact of externalizing relationships from core data was going in the proper direction: Reduce coupling in data
Indeed the first natural use of graph databases (I mean non RDF semantic graph databases) is big data. For sure, as long as data can be imported, explored, linked differently that the initial linkage and re-explored, provided you have a simple query language, data manipulation is changing fundamentally. Remember the pain to create physical views or OLAP cubes: with graph databases, you can aggregate nodes by other nodes, iterate, have “walkers” that recalculate everything, etc.
Graphs Inside The Software?
But, as easy as the graph data can be manipulated in the BI/BD (Business Intelligence/Big Data) world, I was still obsessed by the capability of reducing drastically the complexity of developing huge and complex business applications.
Many times in the past, I faced application design issues that came from the impossibility of respecting all requirements. It was necessary to make choices.
As a software architects, we try to find the less worst compromise considering the set of requirements and use cases (AKA the scope) that you deal with. That’s what design is about.
I always found this approach as unsatisfactory because:
- Most of the time, you have to reduce the scope, you have to choose between the use cases that you could implement. Depending on your choice, the design will be different. That was a real issue for me for years.
- If you pretend you can plan extensibility based on what directions the software will go to, you’re most of the time wrong. Because, we, software guys, are not business people. So, most of the time, our forecasts are quite bad. That means that when the software evolves, we have to redesign, to migrate the data and to retest everything. After several generations of maintenance developers on the same code, modifications are rarer because they are more costly.
Why Are We Generating Technical Debt?
Software architects should be obsessed by the reduction of technical debt.
That was my obsession. How to design and code so that we can reduce future debt? What is wrong with our software practices? It is not easy to identify and I read all the software gurus of the planet (mostly American guys, thanks to them).
I also thought about frameworks, programming models, reusable components, all the stuff that were created to mitigate this technical debt issue. For sure, if you’re developing from scratch an application, there are many great tools in the market and a lot of them are open source. But the troubles begin when you maintain all the crappy code that you’ve created. You discover that your new use case breaks a lot of stuff and that, most often, you did not know in the first place how the frameworks you used were really working.
With graph databases, for the first time in my life, I was feeling that we had something new, something great, something revolutionary. A lot of people said to me: “don’t bother, developers are just following hypes; they don’t design anymore; they don’t know what they are doing; they won’t be interested”. Perhaps. But I remember the words of Steve McConnell in his book Professional Software Development:
The proper question is not “What is software development currently?” but rather “What should professional software development be?” In my opinion, the answer to that question is clear: Professional software development should be engineering. Is it? No. But should it be? Unquestionably, yes.
GraphApps is an engineering solution to create better applications that will be maintainable forever and that don’t generate technical debt, or at least in a very different way than the one that companies know today.
My all software life, being in application projects or software products, I battled with coupling. How to reduce them? Because the less dependencies, the easier the maintenance.
Ans graph databases technology was opening the capability to answer to this question:
How can we reduce useless coupling inside the code itself?
The reasoning was quite simple: if we perform coupling reduction into the code (code “softness”) and use “soft data” (with a graph database), we can create a new generation of business applications. Indeed, we can create real “soft-ware” or “soft-software”, instead of creating “hard-software” as we usually do.
I was bound to find a programming model to do that, a list of rules that would enable to create those next-generation applications.
The pages in this section will try to make software architects and software engineers understand the GraphApps programming model of this new programming paradigm, called Graph-Oriented Programming. In a lot of ways, this programming paradigm is a melt of existing programming models:
- Object-oriented design and programming for sure,
- Functional programming,
- Design by Contract,
- Rule-based programming.
At GraphApps, we are convinced that our tools are the first ones to implement a programming model that will open a new era in software engineering, especially in business enterprise software and business enterprise applications.
Next page: Coupling in Enterprise Applications