Graphs in the Enterprise - Part I

Graphs (not charts and pretty pictures) are an abstraction that was first used by Euler in 1736 to solve the now famous Konigsberg problem. This mathematical abstraction has been proven to be useful in several niche domains where complex networks (graphs are also known as networks) had to be analyzed. Graphs got really popular with Google and their page rank solution to the internet search problem which proved to be a real value add and revolutionary. What started out as a useful data structure became more popular as companies such as Facebook, LinkedIn started building huge graphs with billions of nodes and edges, companies started realizing the true potential of Graphs. Today we have several vendors selling graph databases and Amazon entered the fray recently with its Neptune database as the answer to Graph problems.

Before we make a case for Graphs, let us see what type of enterprise data has a graphical structure. In future articles we will deal with the derivative questions like, even if the data can be represented in a graph, why should one use it. And if we use it can we achieve tangible value. To begin with let us look at the data starting with the customer.

Customer Hierarchy - Graph

For companies that sell to businesses the definition of customer can be slightly hazy and could refer to the channel partner who pays for the product or the end customer who actually uses the product. Even within an account there could be multiple divisions that could purchase the product and have different accounts. But ignoring the ground realities and complexities associated with specific customers, let us look at the channel. A simple channel hierarchy would look something like this and is easy to model in a graph.

While this is the business view of the customer hierarchy, the hierarchy changes when they are entered into an ERP system like Oracle or SAP. Oracle for example uses what it calls the Trading Community Architecture (TCA) while SAP uses a slight variation in the terminology and distinguishes its customer entities through the partner functions. When the data is represented the customer hierarchy looks as shown below.

The actual customer hierarchy only becomes visible when we actually look at the transactions that happen between the company and its business partners. Now let us look at what happens to the hierarchy when we bring in the transactions. Let us take an example within an Oracle ERP. A customer (Apps Consultants) say works with a dealer (Razor Technology LLC - a real partner of Netapp pulled from their website) who then places an order with a Netapp distributor to fulfill the order. The notional hierarchy will look as shown below.

The actual hierarchy if Netapp captures the end customer information then it would look some what like this. Even though this is a simple scenario we can still see the relationships, if the graph is well designed. Also a graph analytic query could combine some of these patterns into a node by itself and build the hierarchy. We will look at Graph analytic queries in a future article.

To get the same picture from a relational database probably would be a large query and that too for a specific order. Doing this for multiple orders over time would make those queries extremely cumbersome.

So a reader may ask where are we going with this. How does it help an enterprise? Who does it help in the enterprise? How should one go about building such an enterprise graph?

We will answer all of these in greater detail in future articles, but for now let us see how such a representation can help enterprises. Graph can help in identifying the following:

• Show the community of customers who purchase similar products
• Show the customers who purchase the same product frequently but with the same seasonal pattern (say every two weeks from June to August, but only once a month afterwards).
• Show the segment purchase journey over time

All of the above questions would be hard to answer with a relational database and a graph would add significantly if the organization is ready to act on such information. In a future article we will show with examples on how such Graph Analytics could answer these questions.

Kiran Pingali is the founder of Apps Consultants Inc. a Colorado corporation helping enterprises in their journey of digital transformation and helping them achieve better outcomes since 2005. We use Graph features for building Machine learning models to bring the causal relationships that may be hidden in the complex interactions between the enterprise and its customer. Apps Consultants is also a Neo4j partner and help our clients build graph based technology solutions for various business problems. We work with various business divisions to help them implement data driven decision making and decision automation into their business processes.

Through our Decision Products we provide customers with custom designed managed software solutions, built and maintained on the cloud. We help companies go from ideation, prototyping to pilot and full scale deployment in agile fashion by incorporating design thinking principles into our inception process. Call us to learn more about how Apps Consultants can help you make better decisions to achieve favorable outcomes.