Current I’m focused to large enterprises and consult them
designing and implementing IT solutions for their core business. These projects formed my point of view on NoSQL graph databases I present in this blog. My point of view is practice driven and based on my many real life experiences with projects and products as a solution architect, which is my main project role. I already came in touch with NoSQL for 3 years ago by design of the Solution for Stem Cell matching. Since then I can see a significant increase in the need for graph databases in enterprise environments. This is also reflected by the trend analysis of Google searches.
This increased need in the industry for graph databases has been very little considered so far. After my short research I found the presentation by Jans Aasman, Ph.D., AllegroGraph, “Enterprise Requirements for Graph Databases”. I would recommend it to get an impression of the graph and its usage.
There are also brief disquisitions of DEX, Neo4J, Oracle Spatial and Graph or Virtuoso. They show the approaches from the technological’s point of view why NoSQL should be applied. I see these more as solutions and the measures to satisfy the business requirements and does not consider the NoSQL, graph databases as an end in itself. Regarding the term clarifying, is from my perspective important to establish, that today the graph databases and triple stores can be used for similar purposes even though they are originally created for different needs.
First I think it is important to distinguish the terms graph databases and triple stores. They can be used for similar purposes even though they are originally created for different needs. From my point of view are the Graph Databases and Triple Stores for many Business Cases a Synonym. The Triple Stores are older as Graph Databases and used with focus on geographical, telecommunication networks and semantic web. With Triple Stores are easy possible to build Graph Data Structures and store in the Database.
At large enterprises, certain aspects have greater importance than just the mere usage of worn, hyped technologies. The technology should be used as the leverage to maximize the business value and never used as an end in themselves.
These facts are recognized early by large enterprises. Enterprises try to establish Enterprise Architecture Management (EAM) or IT Advisory to govern this challenge. Usage of the NoSQL Graph Databases is to be brought in the line with corporate -strategy, -objectives and legal requirements.
The decisive point is to find the right balance between:
- The progress through the graph database technology to ensure the competitive advantage
- Unnecessary investments that are only indirectly useful
but directly generate costs
For this reason may EAM or IT Advisory not to slow the Technological Innovation progress as a Graph Databases, thereby to slow the Agility of the Business Processes and implicitly prevent the growth of the Business Value. EAM or IT Advisory have to support the technological progress, as mentioned above, but with the right balance.
The requirements are classified into six different groups, for these requirements I mean that these are critical for the large enterprises. On my point of view are these requirements realized by architectural principle “Use NoSQL Graph Databases in our enterprise” if the following requirements are achieved. The architectural principle is put to use by the EAM or IT Advisory.
- Main functional Requirements on Enterprise are
- Business cases of the graph, semantic, geographic or relational -nature are based on core business processes to deliver maximum business value to client
- Business cases of the analytics and business intelligence nature for decision making
- Business cases of the social and semantic analytics for customer performance to incise customer relations
- Main Strategy Requirements are
- Use new technology as Graph Databases from NoSQL to ensure the competitive advantage
- Market share of the product
- Financial invest by the vendor into the product to ensure the future viability
- Maturity and financial stability of the product vendor
- Skill spread and price on the market for this product
- A global product consulting
- Main Efficiency & Implementation Requirements are
- Modeling notations and tools
- Normalization rules such as 1. or 2. normal forms
- Usage in Applications based on industry standards such as JPA (ORM) and JTA in Java and others
- Effectiveness and breadth of applicability
- Non Functional Requirements with Enterprise focus are
- Performance and Concurrency, Scalability
- Recoverability, Online Backup, Automatic Failover
- Main Operations on DataCenter Requirements are
- Current and familiar Skills in Operations
- Personal Costs for SLA-s
- Product Support
- Main Pricing Requirements are
- Standard Product pricing models
- Standard License per CPU Core or named User
- Standard and extended Support and Maintenance Costs
- Private Cloud/SaaS pricing models with regard of the federal law
- Pay per transaction
- Pay for Service per unit of measurement
Each Enterprise have own view to this Requirements and own Target Architecture. Both of this are to adapt to own Client needs. My point of view is only one possible recommendation to move in right way.
As we have seen by the definition of requirements for large enterprises are the customer need for NoSQL Graph Databases growing and at the same time are the requirements to these products extremely high. When the NoSQL – Graph Database products achieve the above defined requirements with high coverage then will these products have a bright prospects to be used in width and will survive the technology hype with success.
My next Post are enormously affected by the ability of Relational Databases. This are the Notations and normalization Rules such as 1. or 2. Normal-Form. By the next chance I will write about in the road from logical Domain Model to the Logical Graph Model of the NoSQL, Graph Database in the enterprise world.
Enterprise Requirements for Graph Databases, Ph.D. Jans Aasman, AllegroGraph, http://architects.dzone.com/articles/enterprise-requirements-graph