One of the common issues we face when developing applications for industrial customers, is the issue of accurately representing their domain.
A domain is the set of assets, equipment, departments, systems, that make up the whole of a company’s operations. Organizations usually have fine grained definitions of who should be responsible for managing a specific asset, which department resupplies systems, etc.
A software system should integrate with an organization structure and enable its operations. More often than not, they achieve the opposite, requiring organizations to fit their processes and structure inside their own rigid asset structure.
While promoting standardization, this approach stifles organizational innovations. It leads to faulty and incomplete domain representation, as assets are not recorded as they are, but as fit the system, or not recorded at all. In the end, many systems end up being hacked by system-integrators or in-house teams to make them fit, or a custom solution is being developed.
Very often these limitations are driven by technological limitations, SQL databases (still the norm for most industrial applications) requiring a rigid structure to be performant.
Graphs
We think that domains can best be described using graphs. A graph is a representation of information using node (vertices) and links (edges).
The following example should help to shed some light on the concept, and explain why we think it is such a great fit for representing domains:
- Company A operates a small plant.
- The plant has systems, composed of equipment or sub-systems. An equipment or a sub-system can be shared by multiple parent-systems.
- At the same time, each equipment is linked to 2 departments, the maintenance department, and the production department.
- Each equipment also has supervisor, a specific person, and a back-up supervisor pool, a pool of people that can be called up if the supervisor is unavailable.
Now you can see how this would start to be very complex when designed in the traditional fashion, leading to complex and inflexible implementations.
Now look at how we could implement this using a graph:
Suddenly your complex domain can be organized in a nice, coherent way, all relationships being represented exactly the way they are in reality. There is no limit as to how you should configure your operations, register your assets, organize your teams.
Of course, graphs have existed for a long time. They just have been notoriously difficult to implement in traditional SQL technologies as such. They are mostly used in the design phase of a traditional implementation. They describe the rigid tables and relationships that are then hard coded in the database structure.
What has changed? Graph databases
A graph database is a database that has been specially designed and implemented to deal with graphs. They can traverse graphs to look for relationship insanely fast and are faster than a traditional tailored-made SQL model would.
In a graph database you define your graph as a graph. Tables, relationships, everything is configurable at runtime, there is no rigid structure. The graph evolves together with your domain.
A graph database comes with its own language for querying and managing graphs directly. Developers do not have to worry about implementing the graph logic. Application managers do not have to worry about the maintaining integrity. The database takes care of it all.
Graph database technology is now mature enough to be deployed as support for industrial grade applications, and alleviate the limitations created by the SQL databases technology. Products such as SAP OrientDB or Neo4J have been around for a while, are battle tested and widely used.
At Cuurios, we think it is time for the industry to embrace graphs. Let your applications represent your business, and not the other way around!!
STAY TUNED!
Cuurios is currently developing its brand-new software platform according to these principles.
It will combine this new representation of operational domains, with self-service algorithms and hands-on data processing, to create a platform that works for the engineers and the operators!
But more on this next time!
