SAT FUSIONSOFTWARE ARCHITECTURE PRACTICE

Ambitious software for ambitious companies. no. nobody’s system is “ambitious”. it is old, and touching it is expensive.

SAT Fusion — software architecture practice, Czechia

I am hired to make systems smaller.

I am called in when the system already exists and already hurts: releases have become slow and expensive, nobody wants to open the core, and the people who built it can no longer explain the whole of it. I read it, find the part that actually carries the business, cut the rest, redesign that critical path and take the result to production. Not to a presentation.

One architect.
From the first conversation
to production.

Isometric cutaway of a frame: three separated levels with columns, bracing and dimension lines

What I am called for

Four kinds of work

Untangle

this is what most calls are about

An architectural reading of a system already in production, then rebuilding it while it keeps running. Architecture, the live system, hands-on development and the integrations around it — four things most firms sell separately. Here it is one job, and it is priced as a rescue, which is what it is.

See a case

Build

A new system built for production from the first week, rather than a proposal about one. It starts with a conversation about the business and ends with something under real load, in an architecture the next hire can read.

How it goes

Integrate

Where the system meets the outside world: hardware, payment rails, state reporting platforms, supplier feeds. A wrong assumption on that seam is usually not a bug. It is a regulatory incident with your name next to it.

Where it has been

Lead

Technical ownership without a hire. Not a fraction of a person for a fraction of the time, but full access to one — brought in for a decision too large to make alone, and released once it is made.

Talk it over

Two cases, two timescales

Clients are named on request, not on the page
Retail · vending hardware

The demo had been slipping for weeks. Fourteen days later the first machine was working on the street.

Retail through vending hardware under state traceability rules for precious metals: every transaction has to be provable, not merely recorded. The system was eight months old, eight people had built it, and rewriting it was not an option.

The pain was not the quality of the work: nobody could take the product from the first step to the last and say it was ready. Effort was going into what would matter in a year, while the first release was underestimated.

One question against everything: what stops us going live tomorrow? First we wrote down what the system already did — you cannot safely remove what nobody has written down. Then about 80% of what existed was removed and the rest finished. What had been one inseparable lump came apart into thirteen parts that could be worked on one at a time.

Joined on 17 June, first test run on 30 June, and from 1 July the first machine was live, restocked by a contractor’s courier. That is the time to launch, not the time of the work: the bulk of the system landed over the two months that followed, with the business already running on it.

  • 8 months old at entry
  • team of 8
  • ~80% of code removed
  • 13 separate parts
  • 14 days to the first machine live
Details in conversation
Banking · regulatory reporting and internal systems

Five people cannot hold fifty different worlds in their heads.

A team of about five people is responsible for roughly fifty applications, eight to ten in flight at once. The thing to count was never the applications but the switches between them: each system had its own habits, its own way of being built and released, its own shape.

The variety looked like a technical problem and was a human one. Much of the estate was built between 2005 and 2010, and every system still carries the habits of the year it was born in. But that was not the pain. The pain was that every entry into a colleague’s system cost a day of remembering — and five people stop coping long before fifty applications run out.

What gets standardized is the pain, not the technology: one way to build a system, one way to release it, one way to set it up. Whatever did not hurt enough was left alone — parts of the estate still talk to each other the old way, and leaving them is cheaper than bringing them into line.

How you can tell the pain is gone: when the environment changed what it demanded, the applications themselves barely moved. What changed was one thin layer, and it changed the same way in every application it touched. The first change was made by the most expensive person on the team; the rest were repeated by the cheapest. Work that would once have meant rebuilding fifty applications cost almost nothing. The rest follows from the same place: more than 60% of the estate rewritten, moved or built the new way, and incidents have stayed quiet.

Details in conversation

Three moves, in this order

How the work goes
  1. 01

    Read

    Write down what the system does today — before anyone starts having opinions about what it should do. You cannot safely remove what nobody has written down.

  2. 02

    Cut

    Remove what carries no load. Most systems carry more weight than the business needs; this is sculpture rather than accretion, and it is most of the work.

  3. 03

    Rebuild

    Redesign the critical path and build it while the system stays alive. The result is a release in production, not a presentation about one.

Twenty years of other people’s difficult places

What has already come through
20+ yearsin commercial development
from 2 months to 4 yearsthe client sets the length: they decide when they take ownership of the system back. After that I stay a phone call away.

Eight fields below, and the list is not exhaustive. In five I owned the result outright; in three I answered for the architecture, or for the code inside someone else’s design.

“Technical owner” is the person who talks to the business in the language of the business, and to the developers and the code in the language of IT.

Banking

Regulatory reporting for a US regulator, anti-fraud, financial document routing, corporate portal.

Technical owner
Insurance

Systems for an international group.

Development
Oil and gas

Electronic document flow for accounting.

Technical owner
Green mortgages

A state scheme subsidising the rate for energy-efficient homes: one of the intake funnels, and eight-plus systems to hold together behind it.

Development
Retail

Shelf and planogram layout, analytics for category managers.

Technical owner
Vending hardware

Retail under state precious-metals traceability rules.

Technical owner
Laboratories

One laboratory information system and its integration with instruments over ZigBee.

Architecture and development
Mobile games

Personal projects, outside client work.

Technical owner
Portraitno photo yet
No handover. No substitute.

One person carries all of it

Whoever reads your system is the same person who writes the fix, and the same person who later explains it to your team. Nothing is passed down to whoever happened to be free this week.

One person carrying it is not the same as one person holding it hostage. The test is simple: when a good engineer leaves, the system keeps running. When a bad one leaves, it falls over at once.

This is not a boutique habit. It is why the architecture from the case above still matches the code months after handover.

Pavel Tsiber

Start here

Tell me what hurts, and what it costs.

Two things are enough for a first conversation: what hurts, and one number that can be measured — hours, money, share of failures, missed SLAs. That number is how we both see later whether it hurts less. Not a ticket, not a specification.

[email protected]

Complexity is ordinary.
Clarity is not.
Let us fix that.