Previous page in the section: Genesis of GraphApps
Coupling in Business Applications
Professional applications generate a lot of coupling, most of them are due to our ways of architecting the application and our ways of coding. And those ways of architecting and coding are highly related to the capability of the technologies we use.
At the end of the 90’s, the question of efficiency in coding was at the center of business application concerns. That was the wave of object-oriented programming (Small Talk first, then C++ then Java) and the real production use of relational databases (there were still a lot of indexed sequential databases in production). The design question was also at the center of attention. UML was born.
From the mid 2000’s, those preoccupations let the place to the multiple web technologies that push for enthusiastic “code first” spirit.
On the backend side, despite all those new frontend innovations, things have not change a lot since 20 years. ORM were existing back then (I was using it in 1994) and they are widely used today. Application servers are now Oracle Java Spring based or Microsoft .Net based and they have replaced the ANSI C and ANSI C++ Unix-based Oracle Tuxedo and mainframes TP monitors such as IBM CICS. But fundamentally, the application building method did not change a lot in terms of coupling generation.
In this page, we won’t speak about the Cobol mainframe applications but, as there is still a lot of Cobol mainframe applications out there, it would need also some discussion.
What Do We Mean By Coupling?
In professional applications, we have the requirement of managing “business concepts” and to attach to a bunch of them “business rules” or “management rules”.
Those business concepts must be implemented in the code in some way and stored inside the database. This is true for all technologies being Cobol/mainframe, C/C++/Unix TP monitors of Java/.Net application servers.
The fact is, business concepts have semantic links between one another. Persisting those links generates “hard coupling” which makes the software we produce not so “soft” as we would like.
Let’s consider two business concepts A and B and let’s suppose that functional analysis provided the information that A contains zero or one B.
In our code, we will have the A class pointing towards its potential instance of B (that can be null). It is probable that the table storing As will contain a column referencing the B ID the instance of A is linked to. Indeed, “A structurally knows B”.
Let’s consider now that A contains a list of B. The code will contain the same direction in the coupling : A will know structurally B. But the standard way of implementing that into a relational database brings another level of coupling.
Indeed, the table representing B contains a column with A IDs. Woo, this is bad because now we have B knowing structurally A inside the database on top of A knowing B structurally inside the code!
We have to realize that a business applications usually contains dozens to hundreds of business concepts having one-to-one or on-to-many relationships. The least that we can say is that:
Before even implementing a single business rule, the code and the database are full of structural coupling.
We call that coupling because, in the future, when we will make the global application evolve, when the application will live after the first production delivery, we will have to cope with all those hard coupling.
Hard Coupling Is Costing a Lot Of Money
That’s a fact that hard coupling costs a lot of money. Because, during the evolution period, we will have to structurally modify the application. This modification:
- Will be dangerous,
- Will require a lot of costly non regression testing,
- Will often require a data migration when the database evolved,
- Will generate bugs that will be expensive to fix.
Indeed, we can thing about coupling as the principal source of technical debt in the software the industry builds.
But if we think a bit about that fact, it seems quite puzzling: what we say is that
The core technology we use (object-oriented programming and relational databases) forces us to generate technical debt from the very beginning of application construction.
That’s why the software industry is obsessed by patterns: because they mitigate the issue by trying to introduce design best practices which objective is to reduce coupling.
In GraphApps, we think the issue of current technology (OOP and RDMS) cannot be fixed with design patterns (even if patterns can reduce some coupling issues).
The fact is most companies having many applications to maintain know that this is true.
For more than 20 years that I build software, I always wondered why our industry was so “archaic”. We call our engineering activity “software” but we should say that we build “hard-software”: our very tools for building software application are generating a kind of glue that progressively reduce our capability of making software evolutions.
Hard-Software Function Point Cost is Continuously Increasing With Time
An application can be sized using the FPA method.
Let’s suppose you application is weighting 1,000 function points (FP) and you have a constant budget for the maintenance and evolution phase. If you measure, year after year, the number of function points that you will develop per year with the same budget, you will discover that this number is decreasing towards zero. If you can develop 10 FP year 1, you will end up below the 1 FP per year after some years.
For 20 years, I observed this hidden rule attached to our way of doing software:
In OO/RDMS application, in the maintenance phase, the cost of the marginal function point tends to infinity.
Generally, when the cost of the marginal function point is becoming too expensive, IT departments and IT service companies ask for a complete rewriting of the software.
For sure, not all companies are facing the same troubles: if you only have small applications, you can rewrite a part of your applications frequently. I saw that in some parts of the IT systems of some telecom operators. For sure, you have to have money to do that because decommissioning applications is also costly.
But if your core business is relying on big applications with multiple business rules, knowing the success rate of big application rewriting projects (quite low), it is normal to hesitate and try to convince the CEO or the business users to find another solution. Nowadays, a lot of companies and state offices are a bit paralyzed by this impossible choice:
- Launch a big rewriting project that will surely cost a lot of money but not surely converge towards a new usable business application application;
- Run in a best effort mode for the maintenance and evolution (after a while, this is mostly bug fixes) and realize small developments around the big system that cannot be rewritten.
The Hope Brought By Graph Databases
We will get back to the sample of the business concept A having a list of Bs but in a graph database concept.
A and B are not hardly coupled in the database. That is great, because the base will be able to evolve in its links.
The Big Data industry has discovered for quite some time the immense advantages of the graph databases for business intelligence. But what about the management applications?
Here is what the industry is proposing us, through the use of Object-Graph Mapping (OGM instead of ORM).
Nooo! Software coupling again while the database offers no structural coupling! Can we do better?
Yes we can! This is what we, at GraphApps, propose: a code with the same level of loosely coupling than the database.
To know how we manage to do that, read the next page.
Next page: To be continued