By Dr Tim O’Neill, originally published in InfoWorld
For businesses with massive volumes of data and digital assets, graph databases provide a better way to make data available to users, query it, manipulate it and analyze it in real-time.
And in the not so distant future — forecast by UBS in their recent Davos paper “The Fourth Industrial Revolution” — a world of “extreme connectivity” where intelligent software and even robots become standard, graph databases will leapfrog the abilities of other database technologies.
Many IT leaders including enterprise architects are already turning to graph databases to gain an edge.
Social media giants like Facebook and large e-retailers like Amazon and eBay have led the charge, moving away from the familiar but rigid, structured, tabular relational databases. NoSQL and graph databases are already the preferred back-end or persistent storage used to drive many social and retail apps.
Relational databases still do run many core functions. They work well for simple HR, technical support and IT operations applications. But their lack of flexibility means that they’re often not equipped to deal with data that is rapidly changing not only in content, but in structure. They can lack the speed and scalability users now demand of their enterprise products.
Rather than using rigid tables to collect and structure information, a graph database structures data as objects with direct relationships to other objects. This provides flexibility in structuring data. It also prevents your application from having to continually scan for individual objects in massive tables — and that means big increases in speed.
Graph databases for enterprise modeling
For an enterprise architect or digital transformation specialist working to model a business and deliver answers and analysis quickly, storing data in a graph databases gives two large advantages.
Firstly, the value in enterprise architecture comes not from understanding details of entities in isolation, but from understanding the relationships between those entities and the rest of the enterprise. This allows EAs to grasp the impact that changing one entity will have across an entire organization.
(As an aside, this is also what makes them ideal as the back end for modern social networks. It is not enough for a social network to know two people are connected. The graph database allows the system to understand how these people are connected and quickly identify common friends, interests, or activities.)
Secondly, enterprise architects who can bring this “connected relationships” understanding to their organization’s IT and business strategy can provide more accurate and rich information about the business. Ultimately, they are able to give more nuanced, detailed and superior advice.
Turning the tables
For an architect in a fast-moving business, or one involved in a change-management project, inflexibility is often a source of frustration, and in the worst cases, the failure of a project.
The structure of relational databases behind other enterprise architecture tools can become a (potentially unsteady) “stack” of multiple intermediate tables. Querying this structure is a slow process. The database can also be difficult to maintain or edit.
When new frameworks are introduced or when enterprises need to capture new or different information about current systems, the underlying database structure will also need to change.
To implement these changes in an enterprise architecture repository built on a relational database would require an end-to-end rebuild of the underlying databases.
When an EA has to use a relational database back-end to draw an architecture, what they are doing is squeezing a complex structure into a single table or rigid set of tables. Both detail and structure are often lost or altered. The node itself is stored “far away” from the attributes. This leads to performance hits when re-assembling the data, and makes the data harder to query and understand.
The ABACUS enterprise architecture tool has used graph database technology for over 15 years.
The graph advantage
For enterprise architects the advantage of a graph database back-end include:
- Quicker access to your data
- Being able to quickly and easily extend or change metamodels “on the fly”
- Not being restricted to one framework – being able to tailor hybrid frameworks according to business needs
- Being able to execute both simple queries that involve two directly connected entities, and also more complex queries which involve crosses over architectural layers very quickly
- Being able to capture an unlimited number of properties and store information on relationships easily to provide more detail about the relationship itself.
Using an “enterprise graph” (an EA repository based on a graph database) gives enterprise architects the tools to manage the extreme data volumes and extreme connectivity of current and future businesses.
So, a key question to ask of your existing EA tool or to include in your next EA tool assessment is: “Does the tool use a graph database natively for the storage of data?”
We’ve designed the ABACUS enterprise architecture tool so you can move quickly to import your data, deliver value, provide advice and guide the business towards its goals. Test drive ABACUS today.