Valters Jansons is a Latvian IT solutions architect working from South Korea. He designs and reviews the architecture of complex, integration‑heavy IT landscapes where custom applications, vendor platforms, and legacy systems all have to work together in a hybrid hosting environment.
He has spent a decade in that work: six years growing from junior system administrator to lead DevOps engineer at the cloud business of a pan‑European IT distributor, three and a half years as a customer‑facing solutions architect at a Baltic grocery retail group, and a parallel run at an infrastructure operator for public blockchain networks, ending as its chief technology officer. Since late 2025 he has worked independently through an IT architecture consultancy.
He built this up without a computer science degree. The practical education came from open source first, and then from operating systems in production.
The work
IT architecture, as Jansons practices it, is mostly translation. On one side are the stakeholders with budgets, deadlines, and a rough vision of the outcome. On the other are the engineers who will carry whatever gets decided for years to come. The job is to make each side's constraints understandable to the other, and to land on one shared picture of what is being built.
The day‑to‑day is rarely flashy. It's mapping what is actually there, and working out which parts are forgotten legacy and which ones everyone quietly depends on. It's naming an owner for each component and each API contract between them. It's setting expectations across services, so that mission‑critical systems don't get breaking changes shipped on Friday evening. And it's judging how a vendor's proposal lands in the landscape that already exists, rather than how it looks in a demo.
He's drawn to the boundaries between systems. The expensive failures, in his experience, are rarely inside a service. They're in the space between them.
How he thinks
Jansons wants to know how something works, not just how it's described. Documentation, vendor claims, and architecture diagrams are all opening hypotheses. The running system is the evidence, and the gap between the two is usually where the useful information is. It's also why he has never stopped running his own Linux systems - the instinct for how things behave doesn't survive on documentation alone.
He's comfortable owning the unclaimed middle between solutions. Most people avoid it because nothing there is clearly anyone's fault, which is exactly why he'll give it a name and ask who should be accountable.
A seventy‑page design document rots on a shelf instead of being used and updated. He'd rather be understood than look impressive: a decision isn't finished if it can't be explained plainly to the engineer who will inherit it.
Novelty has a budget, and everything charged against it comes back as maintenance for someone. So the boring option is the default, and the flashy one is what has to be argued for. The bleeding edge has its place, but its cost should be consciously accepted.
And he assumes he'll turn out to be wrong about something during investigation work. Assumptions will break. Conditions will change. What matters is that the reasoning is still there in six months, so the next person can pick up where the thinking left off rather than starting over.
Things he'll argue about
-
Most integration failures are ownership failures.
The technical part of a broken integration is usually small and fixable. The reason it silently stayed broken for eight weeks is that two teams were out of sync. Each believed the other owned the contract between them, or nobody thought anyone was still using that specific enum field. An architecture that assigns ownership clearly beats one with a tidy flowchart.
-
A decision nobody can explain was never made.
If nobody can remember why a decision was made, or the reasoning only lived in a chat thread from two years ago that has since been purged, then for all practical purposes it was never made. Not everything needs a lengthy document, but it does need a trail. Without one, the choice either gets relitigated from scratch or stands as something that looks arbitrary.
-
If it can't be operated, it isn't done.
Observability and maintainability don't start as a separate phase after delivery. A coherent monitoring strategy across all components, and a plan for safe patching at three in the morning, are best worked out at design time. Skipping the operational side early is tempting, but it stacks technical debt that comes due exactly when there's least room to absorb it.
-
"We'll standardize it later" is not a plan.
Later doesn't get scheduled. It gets postponed the first time because it is a small fix, and postponed after that because it has grown into a refactor nobody can budget for. Every non‑standard choice should have a reason behind it, because it will be paid for eventually, out of a budget something else needed more.
-
A local workaround is a permanent fork.
When a dependency is wrong, patching it in a local tree is the fast fix. But that patch has an owner now: rebased at every upgrade, invisible to anyone reading the upstream documentation, and impossible to justify to the next maintainer who finds it. Sending the fix upstream costs more once and less forever. The bar for keeping a change local should be that someone can say why it can't go upstream.
-
Secure by default. Document the exceptions.
The restrictive setting should be the one nobody has to ask for. The open one should cost somebody a conversation. When this flow is inverted, exceptions stop being exceptions: cheap to grant, cheap to forget, and quietly the standard within a year. Each one needs its rationale attached.
The main roles
-
Dec 2025 - present
Vibe Solutions
IT Solutions Architect
Since December 2025, Jansons has worked full time through Vibe Solutions, an IT architecture consultancy. Engagements are solution and integration design for organizations with complex, integration‑heavy landscapes: current‑state assessments, reviews of vendor design proposals and integration contracts, evaluation of target‑state options, and standing architectural advice.
-
Jul 2022 - Dec 2025
Rimi Baltic Group
IT Customer Solutions Architect
In the Customer Experience division, Jansons worked on the systems that Rimi's shoppers touch every day. He aligned landscape strategy across several product teams and their stakeholders, took on technical investigations, and assessed initiative proposals for risk and viability, giving each one a path forward that engineers could realistically implement. A large part of the work was cloud enablement: loosening the product teams' dependency on central infrastructure teams, and standardizing the software delivery lifecycle around it.
-
Jul 2022 - Apr 2025
kjnodes
Technical Lead to Chief Technology Officer
Alongside the Rimi role, Jansons ran infrastructure for public blockchain networks at kjnodes, a small Latvia‑based validator operator. Downtime there carries a direct financial penalty, charged to the operator and to the people who trusted it with their stake. That record is public: every signature and every miss lands on a chain anyone can read, and delegators choose where to stake accordingly. The work was keeping that record clean by automating chain upgrades so a coordinated halt doesn't turn into a missed block, and hardening the key management and signing path the whole operation rests on. The team also ran relayer services and the private and public RPC endpoints other people built against.
-
May 2016 - Jul 2022
ALSO Cloud
Junior System Administrator to DevOps Engineer to Lead DevOps Engineer
Jansons spent his first six years at the global cloud business of a pan‑European IT distributor. The early work was all plumbing: internal notification relays, infrastructure defined as code, an overhaul of configuration orchestration, continuous integration and delivery pipelines, and a mixed Linux and Windows fleet spanning public and private cloud. As lead his scope became the platform itself. Half the job was running the operations team, while the other half was brokering between the developers and the infrastructure side. He owned business continuity across separate geographical clusters, each carrying its own live traffic and each ready to fail over to a different region. He chose the tooling and ran the migrations onto it, assisted with automated integration testing so developers could validate components together, and took on the tedious end as well - read‑only archived backups, and the auditor meetings that went with them.
How he learned it
Jansons grew up tinkering with technology. In 2013, he started contributing to Paranoid Android, an open‑source aftermarket Android distribution. He was still in school, but the work was tangible regardless: enhancements to core operating system components, mostly Java, with occasional drops into native C++ to hook the things that were not so easy to reach. The other half was bringing new Android releases to older hardware, back in the age when each version still carried major improvements people anticipated. The result shipped to strangers who flashed it onto their own phones, which is an unforgiving way to learn what regressions feel like. Although the Android work wound down when his professional career started, the open‑source contributing never did.
In 2016 he started as a junior system administrator, and worked up through the whole technical ladder of the discipline at one company. Every step worked the same way: build the solution, put it into use, and be responsible for maintaining it.
The pattern of learning by doing has held since. Jansons holds Microsoft certifications, among them Azure Solutions Architect Expert and DevOps Engineer Expert. All of them came after the work rather than before it.
Teaching
For most of a decade, part of Jansons's responsibilities has been making other engineers better at their jobs.
At ALSO Cloud it was written into the lead role: building up the operations team's site reliability and DevOps practice, and handing people initiatives they could grow into rather than tickets to churn through.
The rest of the teaching opportunities he sought out. Between 2020 and 2021, he taught at Riga Coding School, running bootcamps for career‑changers and beginners: object‑oriented programming with .NET and Java, plus the basics around it, from database structures to version control with Git. Then, in 2023 and 2024, he mentored through Riga TechGirls, assisting women getting started with their tech careers.
He believes in growing and retaining talent rather than hiring around the gap. In architecture engagements the approach is the same: sitting with someone until the thing makes sense to them too. And it rarely runs in one direction: explaining a system to someone who doesn't already know it tends to surface the parts nobody had questioned.
Elsewhere
Jansons goes by the handle sigv online, or signalv where four letters are too few.
- GitHub @sigv
- LinkedIn /in/vjansons
- Vibe Solutions IT architecture consultancy