[This article is excerpted from a white paper by EMA and is used with permission.]
Traditional relational databases served the IT industry well in the past.
Yet, in most deployments today they demand significant overhead and expert levels of administration to adapt to change. The fact is, relational databases require cumbersome indexing when faced with the non-hierarchic relationships that are becoming all too common in complex IT ecosystems as well as in dynamic infrastructures associated with cloud and agile.
So, how does this affect your ability to monitor network interdependencies (and react accordingly)? If you’re still relying on relational databases for data center and network management, your organization will be caught in the past.
However, with
a graph database, you’re more prepared than ever to manage and monitor dependences in your network even as requirements and available technology changes. Graph databases like Neo4j make it easier to evolve models of real-world infrastructures, business services, social relationships or business behaviors that are both fluid and multi-dimensional.
Your network data is already a graph, and with a graph database, you can more intuitively manage those interconnected relationships.
Neo4j is built to support high-performance graph queries on large data sets for large enterprises with high-availability requirements. It includes its own
graph query language, and uses native graph processing and a storage system natively optimized for graphs.
As the second post of
a two-part series on Neo4j and network management, we’ve interviewed a software consultant who is working with a large European telecommunications provider to manage and monitor network interdependencies.
Can you tell me a little bit more about you and your organization?
My firm is a software consultancy and I work closely with many Neo4j deployments with a focus on modeling, problem solving and innovation. I see some
distinctive advantages in graph databases, and in particular, in Neo4j’s offering.
Can you share more specifically how you view those advantages?
The graph model is unique with its ability to accommodate highly connected, partially structured datasets that can evolve over time in terms of complexity and structure. Graphs are also naturally capable of providing a wide range of evolvable ad-hoc queries on top of these datasets.
This not only makes for much improved flexibility in design. It also enables relationships to be easily captured that are
unsuited to traditional hierarchic models. It also allows for much better adaptability to changes when the changes themselves are less predictable or not strictly hierarchic in nature. One of the things I especially appreciate is that Neo4j makes it simple to model real-life or business situations – it provides a much better working foundation for key stakeholders who are not necessarily technical.
Can you tell me a little more about the requirements of the deployment you did for a large telecommunications provider?
This company had a very large complex network with many silos and processes – including
network management information spread across more than thirty systems. The large number of data sources was in part due to network complexity, and in part due to different business units, as well as organic growth through mergers and acquisitions. These different sources also created a very non-linear fabric that had to be modeled and understood from various dimensions.
Previous to Neo4j, they had different network layers stored in different systems – for instance, one system might be dedicated to cell towers, another fiber cables and another devoted to information about consumers or enterprise customers.
The company needed a way to predict and warn customers in advance of any service interruptions in order to maintain customer service agreements and avoid financial penalties due to unplanned downtime. With daily changes required to optimize the network infrastructure, managing this effectively was definitely a challenge.
One of their business process challenges was around maintenance and ensuring redundancy – they needed to know if they took a device down for maintenance, exactly who might be impacted and what the penalties might be, as well as what alternate routes might better mitigate the impact.
There was also a more proactive, planning requirement – e.g. planning to lay an alternate cable for backup and knowing how things are connected so best-case alternate paths can be identified. What are all the upstream interdependencies? Downstream interdependencies? etc.
How did you get involved?
This company had some choices between Neo4j and some very rigid and expensive tools designed to fit specific needs. For instance they already had an impact analysis system from which they were extracting spreadsheets and a team of about ten people doing manual work on the spreadsheets, which is expensive and error-prone.
But a small team at that company did a proof of concept with Neo4j and felt that it had many advantages – both in terms of immediate benefits and potential – given the graph nature of many network interdependencies across various processes. Once the POC team showed some initial potential, they got the buy-in to move forward to next steps, and I came on board.
How many people were there on the Proof of Concept Team? And how did the deployment evolve?
There were only three: two developers plus the project manager. It only took a few months to show the benefits. As the deployment evolved, we added someone to support needed integrations. Within four to six months we were able to match the pre-existing system and to demonstrate benefits and advantages. These included fast and powerful queries, along with a custom visualization module.
Then we proceeded to take the next steps to support more complex analysis for root cause – e.g. if you do this or if this occurs, it will cause this specific problem. Or conversely, This is the reason that you experienced this problem. All along the way there was fierce competition to show value, as this telecommunications provider was very serious about managing its costs.
One of the things I like best about Neo4j is that it supports incremental development. You don’t have to get all the data at once to get value from it. You can build your graph in an incremental way, as opposed to more rigid approaches, and then add other layers to accommodate more data and more complex or new relationships.
It was almost a dream business case because you could measure the benefit of the project as the telecommunications provider began to manage production-level changes that impacted its many actual customers. Every time they got something wrong there were immediate costs in penalties. And the values were huge.
What were some of the other benefits that the Neo4j deployment achieved there?
After implementation of the model and the impact analysis queries, it was easy to extend the application to support single point of failure detection thanks to the flexibility of the graph model. Also, by providing an effectively unified cross-domain view, experts from different silos could work together for the first time and agree on a common domain terminology.
Read the first post of our two-part series on Neo4j and network management here.
Dive deeper into how graph databases transform your ability to monitor network interdependencies – click below to download this white paper, How Graph Databases Solve Problems in Network & Data Center Management, and start solving your IT challenges with graph databases.
Download My White Paper
