Runko Works
Menu

Case study

From MVP to an enterprise knowledge-graph platform

Data from disparate legacy systems in one knowledge graph, so search, analytics and new applications plug into one platform instead of each source.

Client
Global energy technology company
Role
Lead software architect, team of up to 30
Period
2021 – now
Area
Platforms & data
Stack
Knowledge graphs · ontologies · microservices · cloud-native · ETL/ELT · Terraform · Kubernetes · GitLab CI/CD

Why it mattered

A large company keeps its data in systems that grew over many years: legacy databases, business tools, shared drives. Every new search, report or application has to integrate with each of them again, and every integration breaks a little differently.

A knowledge graph puts the data and the relationships between it in one place, so new consumers plug into one platform instead of each source separately. The platform had proven itself as an MVP. The job was to turn it into something the business can run on, while the ground kept moving underneath: two large projects merged, infrastructure moved, and the company’s networks were rebuilt.

How it works

Getting the data in

  • Extraction and adaptation from legacy systems, business tools and databases (MS SQL, Oracle, PostgreSQL, a cloud data warehouse), from shared drives, and directly from tools through their APIs and SDKs.
  • Structured and unstructured data, tables and trees, mapped into one model through data structure analysis and ontologies.

One platform instead of many consumers of many sources

  • A source-agnostic design: a search UI, an analytics layer and further applications consume the graph, not the sources. When the original programme changed course, the platform kept serving its other consumers.
  • Two large projects with several years of history each merged into one platform.

Infrastructure that can be operated

  • Parts of the system scattered across an OpenShift cluster and Windows virtual machines moved to the cloud as far as possible, under one architecture of cloud-native microservices.
  • An enterprise network carve-out: every network and connection rebuilt.
  • The project moved to infrastructure as code; DevSecOps and CI/CD practices established inside the existing teams.
  • Identity and access management for the platform inside a complex enterprise landscape.

People

  • Coordination of up to 30 people: a product owner, two external architects and two to three cross-functional development teams, with the architecture owned end to end.

Why this matters for AI

The same problems stand between most companies and useful AI in their business processes. An assistant or an agent is only as good as the data it can reach: if that data is scattered, inconsistent or locked in legacy systems, it will answer confidently from the wrong half. AI works on a reliable foundation of well-structured data, and building that foundation is the part I know how to do.