Asset Management and Access Management — Graph database in play
Asset Management Using Graph
Graph DB Concept
Many have been written around graph databases. The topic and concept is not new and the technology evolves around graph databases in a fast pace. While there are many graph databases are in use and most of them follow their own proprietary way of working with them. A good effort that Apache put forth in this direction is the concept of Gremlin language.
Gremlin of Apache Tinkerpop is a data flow language helps easy and standard for graph traversal. Gremlin adds a common standard which any graph database vendor can follow and comply. The main advantage in designing your application around Gremlin traversal is to avoid any vendor lock-in with any particular graph database vendor. Gremlin caters to all required traversal and it is safe to use the concept from day one of your System Design if ever you plan to use a graph database. This document provide a fundamental direction to use of graph database for advanced asset management and access control (entitlement — which could be fine grained / coarse grained).
Asset management can go to any depth that it could just be a software store for any asset level information/metadata for your organization or it could be tightly integrated along with asset performance management systems as well. It will be a perfect choice to make the asset store/hierarchy management and asset metadata management as a single unit of service — as per concepts of micro service — and to leverage them from any loosely coupled dependent service in the application suite or the organization. In most companies we could find an ERP system that manages a lot of asset or its metadata while having them for extensive access to-fro inside and outside of the organization could be a question. Figure-1 shows a use case where asset manager acts as a single shop for any application in the enterprise. The asset manager itself can depend on an ERP system to fetch and store assets.
An asset management component is useful regardless you have a central store like an ERP (SAP..) or any other system. This article talks about an asset manager that can handle assets, its relation to each other — this could be any connection or even a hierarchical order. However, matters like embedded/externalized graph database, replication are not intended.
In case of of asset management, the solution revolves around having each asset added as individual vertex in the graph. Each vertex can have as many data items as key-value pair — the intention would be to keep the asset metadata stored along. One can design the system such that each asset can be of its own kind and carry its own flavor of metadata. However, a well defined design would be to create assets from a template which would be managed with the set of application services.
Once assets are created, one can add relations — edges of graph — with which the assets are connected either in a hierarchical or non-hierarchical pattern.
In case an entitlement management is required, then the design should extend to add subject(who) as graph vertices. The Subjects and Assets can be connected with the intended permission/s as graph edges. This way edge defines a particular permission on one or more assets.
Figure 2 depicts few arbitrary assets in an office and a set of users who are provided or allocated access to those assets. The label on lines from users to asset indicates the entitlement/permission that a user has.
Asset management and subsequent use cases is a complex problem statement which has to be explored in detail. This quick reference article gives a glimpse of how to start with the solution using a graph database.