Juha Huotari data · systems · useful tools

Solution analyst · architect · builder

I turn complicated problems into systems people can work with.

I help turn business needs into data, software, and operating practices that people can understand and change safely. Most of my professional work is in financial and insurance data platforms. Outside work, I build infrastructure, software, and practical experiments to test the same ideas at home.

See what I work on Read Kotona ↗
Four areas of work 60.9° N · FIN
01 / DATA

Turning policy, source data, and user needs into models that teams can inspect, test, and maintain.

850kregulated documents / year
5,500+source attributes mapped
130+mapping releases
72executable SQL controls

Selected work

Things I build
to answer real questions.

These projects range from daily infrastructure to early experiments. Each one is here because it solves a concrete problem, and each still has something left to prove.

View
SYS / 01 active use

Coordinating complex work

Vuoro

A set of small tools for coordinating work across repositories, sessions, people, and coding agents. It records who is doing what, what changed, and whether the result was actually accepted.

Helps with
Clear tasks, hand-offs, audit history, and recovery after interruption
Avoids
One large control panel that quietly becomes the only place work can happen
What still needs proving

Updates across several repositories and recovery after partial failure need more use under real workloads.

Inspect the project
SYS / 02 operating

Home infrastructure

Appservice

The code and operating record for my Kubernetes homelab. It keeps configuration, upgrade rules, backup checks, and recovery instructions together so repairs do not depend on memory.

Includes
GitOps configuration, recovery rules, and tested backup restores
Avoids
Important fixes that exist only in a terminal history or my head
What still needs proving

A backup only counts when it can be restored. Those tests must be repeated as the cluster changes.

Inspect the project
SYS / 03 active platform

Household data and automation

Household operating platform

A shared model for household reporting, plans, approvals, and automation. Devices report what is happening now; the platform keeps the longer-lived meaning, such as costs, goals, and decisions.

Includes
Shared definitions, scenarios, decision history, and proposed actions
Avoids
An assistant taking consequential action without a visible approval step
What still needs proving

A second substantial integration must show that the common model is genuinely reusable.

Inspect the project
SYS / 04 published notes

A public technical notebook

Kotona

A place to publish project notes, decisions, failures, and patterns worth returning to. Writing turns scattered work into something another person—or a future version of me—can inspect.

Includes
Dated notes, project records, references, and changes of mind
Avoids
Presenting work in progress as universal advice or finished truth
What still needs proving

The notes should work for people, future me, and software agents without becoming bland for all three.

Enter the notebook

How I work

Make the problem clear.
Make the way back clear too.

I prefer systems where responsibilities are explicit, important decisions survive the meeting or chat, and a failed change has a planned route back.

  1. 01

    Decide where the truth lives

    Choose which system records each important fact before building dashboards or integrations around it.

    avoids conflicting records
  2. 02

    Make important rules executable

    Put critical expectations into schemas, interfaces, permissions, tests, or approval steps—not only documentation.

    makes rules testable
  3. 03

    Keep a useful record

    Record what was requested, changed, accepted, rejected, and replaced. A long chat log is not the same as evidence.

    makes decisions traceable
  4. 04

    Plan the way back

    Backups, migrations, retries, and hand-offs count only when someone can test and explain the recovery path.

    makes recovery real
  5. 05

    Let use change the design

    Use new tools early, keep track of failed directions, and remove machinery that costs more than it helps.

    keeps design honest

Professional experience

A few numbers
behind the approach.

Financial and insurance platforms make vague requirements expensive. These examples show the scale of the work and my part in it without exposing employer or customer detail.

15 → 10source tables to reporting views

Requirements ownership

One reporting pipeline, traced end to end

Owned requirements across trading, custody, customer, product, agreement, and fee data, then translated them into 185 field-level mappings.

regulated reporting
5,500+unique source attributes

Cloud migration

Old data made useful in new products

Shaped more than 130 mapping releases and six cloud data products. Moving a field was not considered enough; its business meaning also had to survive.

data product design
72automated SQL checks

Quality assurance

Clear checks instead of recurring arguments

Converted mapping and delivery expectations into SQL checks that made defects reproducible and easier to fix.

testable data quality
10+solution analysts

Leadership

Better ways of working, shared across a team

Co-led a solution-analysis practice through templates, demonstrations, AI adoption, documentation improvements, and guest speakers.

team practice

Where I add value

Turning a messy enterprise problem into a workable design—and staying involved long enough to see where the design is wrong.

requirements analysisdata architecturesystem boundariestechnical facilitationoperational readinessuseful automation

Current questions / September 2026

What I am trying
to understand next.

Individual tools change quickly. These questions last longer and keep me from mistaking the latest implementation for the final answer.

Q / 01

What should automation decide?

Capability is not permission. The useful question is which results a tool may make final without asking a person.

Q / 02

When does a small project need structure?

When several tools, collaborators—or one person returning months later—can no longer rely on shared memory.

Q / 03

What is worth preserving?

Logs and data are plentiful. Useful knowledge is selected, dated, linked to its source, and allowed to become outdated.

Outside the technical work

The curiosity travels.

I live in Finland. Away from data and infrastructure, I spend time on ancient history, cooking, travel, making things, 3D printing, and game ideas that usually acquire an economy before they acquire a title.

Read “The workshop is learning my accent”