For the last couple of years we’ve been involved in this huge project at Veneto Banca, and our mission was the innovation of the bank’s information technology system from the scratch. We wanted to adopt the microservices paradigm exposed by Martin Fowler and to design a brand new object data model for our business needs.
At some point we realized that we needed a tool to govern the landscape of our services composing the application’s business logic.
During the development of the program, it was very hard to take control of the business components that were developed because of the huge number of application teams working on each specific project or functionality.
While it is true that a service catalogue is something worthwhile for a healthy government process, in a huge, real-world project this doesn’t always lend itself to a “time-to-market” approach.
But then some interesting questions arise:
- Can you describe your multi-channel architecture in terms of layers, services, components?
- What are the impacts on the application if a certain service provider goes down and becomes unreachable?
- How can I change a service behavior (or its configuration) on the fly?
- Which are the impacts if we modify the source code of a service?
So we started investigating the best approach to achieve our goals and we built what we call our “service catalogue”.
The first approach was RDBMS-based because our team already has the expertise we needed, and we wanted to cut straight to the point.
The core solution was the implementation of reader and parser components along with adapters for building the catalogue according to the database schema.
During the testing of our beta version we faced some problems with relationships. It was difficult to write the SQL code to implement the queries we needed in order to extract meaningful information from our repository. Moreover, these queries were difficult to read and understand.
The relationships have lost their semantic meanings and the catalogue was a poor tool to answer some “what if” questions.
Thanks to LARUS and their #1 Neo4j evangelist Lorenzo Speranzoni we discovered the power of graph databases and Neo4j in particular.
We were impressed by the way Neo4j treats relationships; they become first-class citizens of the domain model, and they take a central role in the definition of the information handled by the system.
So we’ve moved forward and refactored our components (except the catalogue builder components) in order to build a graph-based data model for our services. And we got something like this:
A sample of our data model
If you’re wondering why Neo4j, well, these are some of the key features we love:- Natural: A graph is the most natural way to represent entities (nodes) that have connections (relationships).
- Schema-less: We can add new types of nodes, relationships and properties easily, so the model can evolve in a simple way (for example, refactoring properties to nodes with no pain).
- Intuitive: The whiteboard model is the physical model (what we draw on a paper is what we get on the database).
- Powerful: It offers an expressive, declarative query language (Cypher), that let you write concise queries.
- Easy to integrate: It is supported by a rich ecosystem of libraries, tools, drivers and guides provided by partners, users and community contributors.
Take a look on how the process flow looks like when we have to face a software change, and we must discover all the impacts in order to run all the test suites to avoid regressions.
This is only a brief example of the impact analysis that we can do with our service catalogue.
In conclusion, implementing an IT government tool based on Neo4j has been the right choice because:
- Standard DBMSs do not manage relationships in a strict manner for us, but Neo4j does!
- Neo4j is whiteboard friendly; what you draw on your paper is what you get on Neo4j
- It’s powerful and easy. It’s powerful because it’s easy!
- …and last but not least… we like it!
Nicola and Alberto will be presenting at GraphConnect Europe in London on 26 April 2016. Click below to register for GraphConnect and meet Nicola and Alberto in person.
