Modernizing Product Specification Databases

The product specification database needs a refresh if its to keep up with the pace of modern business. Fortunately, Graph technology can help.

What is the Product Specification Database?

Why Does It Need a Refresh?

Challenges In Modernizing the Database

The Graph Data Warehouse

Graph Data Warehouse Requirements

Getting Started

What is the Product Specification Database?

The product specification database is a repository of product information used by manufacturing companies to store important details on the materials and components used in the manufacturing process. This database is kept up to date with manual input from different teams such as engineering, quality control, and compliance, and is relied on by many downstream reporting functions.

In many scenarios, teams at local or regional levels leverage data from the specification database and enrich it to suit their specific needs. For example, a local research team may conduct material tests and store these results in a local database. A procurement professional may take specifications from a specific supplier and use this locally to make purchasing decisions.

Why does the database need a refresh?

Regional differences in how this data is produced and consumed create problems for data engineers and data analysts whose job is to extract meaningful insights from this data. Having distributed specification data creates a potential compliance issue and leaves open the possibility that incorrect data not only persists but can also become duplicated and used by executives when making important decisions.

Manufacturers also tend to struggle with the structure of the specification database itself. Over the years, the database grows in complexity as each new product, product line, team member, acquisition, and regulation adds its own layer of complexity to the database.

This complexity makes it extremely difficult for users to analyze this information. Most analytical efforts are completely custom. They often require a great deal of technical expertise and the process of procuring accurate information can take weeks to complete. A lack of transparency and the chance to propagate errors further compounds the issue. A simple question such as “Can I sell this product in this region?” can be very difficult to answer.

Solving these problems can provide huge returns. It will mean that users across the organization (and potentially across the supply chain itself) will benefit from ready access to data that is easily accessible, easy to understand, and of improved quality. This will create new opportunities for the business and the cost to leverage this data will be vastly reduced requiring much less technical expertise and custom work.

The value of this is immeasurable but the journey to get there can be costly if not done right.

Challenges in Modernizing the Database

There are three key challenges organizations will need to overcome when modernizing their specification databases:

1. Databases designed for data capture, not for analytics: The structure of the product or material specification database itself is typically not designed for analytics. Anything but surface-level queries can be a challenge to code and complex queries may be very slow to run. This is a challenge with legacy databases in general. Any database that has evolved over the last 10-20 years is likely to have this problem. Overcoming this issue requires a complete overhaul of the database or a costly migration to a newer system. Given the importance of these databases, neither option is very palatable for most organizations.
2. Local, isolated data: Another challenge is the existence of locally maintained databases. Performing cross-database analysis requires data extracts from these databases which are done manually and on an ad-hoc basis. This creates delays and is an inefficient process for a set of activities that are done regularly. Migrating local databases to a global database requires time, specialized skills, and a normalization process however newer technologies have made this much easier.
3. Data normalization: Data normalization is the process of normalizing data from different sources into a common structure. Achieving this would require a separate platform where this normalized data can be maintained. The ability to map the disparate data to this normalized form will also represent a challenge if the organization lacks the proper skills and tooling.

The Graph Data Warehouse As the New Face of the Specification Database

One approach that can deliver greater insights with less cost and less impact would be to implement a central, graph data warehouse that can combine specification data under one roof. This data warehouse would sit between users who wish to interact with the specification data and the specification databases themselves.

The graph data warehouse is well suited for this type of scenario for several reasons:

Analytical Performance Users will be able to implement very complex queries that will not degrade the performance of the specification database. The data warehouse can be designed in such a way as to make these queries easier to develop and faster to render.

The breadth of Analysis The graph data warehouse approach will allow users to perform more advanced analysis without an increase in code complexity. Instead of surface-level analysis, users can drill deeper into the data to find answers to their most complex questions.

Flexibility The flexible data model is easier to adjust and adapts better to changing conditions. With a property graph, in particular, different data specifications are easier to handle. This will be the case when combining data from multiple sources such as from locally used databases as the data properties will differ. A NoSQL database like the graph excels in this category.

Data Normalization By normalizing the data structure in the graph, users will have a better understanding of the data they are leveraging. The use of this data will be more consistent and problems or errors in the data will be easier to spot and easier to resolve. Another benefit is that technical jargon can be mapped to terms easier to understand by non-technical users.

The purpose of a data warehouse is to increase analytical capabilities without impacting source systems. In this case, the use of a graph data warehouse makes for a solid approach.

GDW Requirements

The graph data warehouse is the perfect data platform for hosting a purpose-built analytics capability that can sit alongside and augment a specification database. To develop the data warehouse the organization will need a few, key capabilities:

A Common Data Model: The graph data warehouse will need to leverage a common data model which is flexible enough to handle a wide degree of scenarios. The model will need to map specification data to products, lab results, manufacturers, suppliers, teams, regions, regulations, and other facets of the product development lifecycle.

ETL/ Batch Processes: The graph data warehouse is a separate data platform that holds specification data from multiple systems in one common repository. Therefore the data in the data warehouse needs to be synchronized with data from external sources. This will require Extract, Transform and Load (ETL) processes that sync these data platforms together.

Self-Service Dashboarding and Reporting: This will allow non-technical users the freedom to query the specification database on-demand and in an easy manner allowing them to quickly get the answers they seek without relying on data engineers to get involved for each query.

Administrative Capabilities: Given the sensitive nature of the data it is important for warehouse administrators to easily on and off-board users to specific data domains within the data warehouse and to track who can access what.

User Forms and Workflow: There will be times when data is incorrectly captured, is missing, or requires some form of human feedback. This will almost always be the case when blending data from different sources for the first time.

Why Process Tempo?

Legacy databases are often designed for data capture and not for in-depth analysis. This is almost always the case with the Product Specification Database (as an example). This simply means that any time a user wants to perform anything but surface-level analysis it requires a data specialist to be involved - and not just any specialist either. It has to be someone very familiar with the target database.

This reliance is a real bottleneck because it means stakeholders now have to wait for answers. This places a real constraint on decision-making and can negatively impact the overall health of the company. Decision makers need access to timely information and when the data required for these decisions are slow to arrive it means opportunities for positive change are lost.

Organizations should therefore do everything possible to make this data more accessible. Modernizing the database itself represents a golden opportunity to solve this problem. However, organizations are often frightened off by the price tag. Are there alternatives? The answer is yes: Process Tempo.

At its core, Process Tempo stores data in a flexible graph data warehouse. The platform also includes a number of features that can accelerate the implementation of a graph data warehouse:

• A no-code environment for developing graph data models
• Built-in integration and ETL features
• A no-code environment for true self-service dashboards
• Embedded workflow features
• Central governance and control

GET STARTED

Schedule a discovery session or demonstration.