What is it?

Steinmetz is a tool I built for my master’s thesis that helps teams decompose monolithic Java applications into microservices through visual analysis and data-driven recommendations. Instead of relying purely on domain knowledge or gut feeling, it analyzes your codebase from multiple angles and suggests where service boundaries should be drawn.

The name comes from the German word for “stonemason” – someone who cuts and shapes stone. Seemed fitting for a tool that breaks apart monoliths.

GitHub: https://github.com/loehnertz/Steinmetz

Why I built it

I’d seen multiple teams struggle with the “microservices transition” where good intentions led to either overly granular services or poor separation of concerns. The problem is that deciding where to draw boundaries is hard, and most advice is vague (“bounded contexts!”) without concrete guidance.

I wanted something that could analyze an actual codebase and provide data-backed recommendations rather than just principles. Not to replace human judgement, but to inform it with concrete metrics.

How it works

Steinmetz analyzes backend code from four different dimensions:

• Static Analysis – Examines source code structure and dependencies
• Dynamic Analysis – Processes runtime behavior via profiler recordings
• Semantic Analysis – Understands code semantics and relationships through natural language processing
• Evolutionary Analysis – Traces development patterns through version control logs

Using this multi-faceted approach, it employs seven different graph clustering algorithms to identify natural service boundaries within monolithic codebases. A custom genetic algorithm then optimizes the clustering parameters to produce the best decomposition recommendations.

Key features:

• Multi-Algorithm Clustering – Seven different algorithms analyze the codebase from different angles
• Genetic Algorithm Optimisation – Fine-tunes clustering parameters automatically
• Advanced Visualization – Three different visualization formats to explore and validate proposed boundaries
• Minimal Requirements – Needs only source code, version control logs, and optionally profiler data

Tech stack

I built Steinmetz with:

• Backend: Kotlin for the analysis engine and API
• Frontend: Vue.js for interactive visualizations
• Database: Neo4j with graph algorithms for relationship analysis
• Deployment: Docker and Docker Compose for containerised setup

The whole thing is distributed under the Apache 2.0 license and represents 447 commits of development work focused on making microservice decomposition more systematic and less arbitrary.

What I learned

Building Steinmetz taught me a lot about the gap between theoretical advice and practical tooling. It’s easy to say “use bounded contexts” but much harder to actually identify them in a 10-year-old codebase with inconsistent architecture.

The multi-dimensional analysis approach proved valuable – different algorithms highlighted different aspects of the codebase, and combining them gave a more complete picture than any single metric could.

I also learned that visualization is crucial. Teams need to be able to see the proposed decomposition and understand why certain classes are grouped together. Raw metrics don’t convince people; interactive graphs do.

The tool is designed for teams facing the challenge of breaking apart legacy monoliths. It won’t make the decisions for you, but it will give you concrete, data-backed starting points that are way better than guessing.