Gustav Poola, Chief Executive Officer at Levercode

17 May 2022

We have to take the right approach to problem-solving - as of now, the mainstream programming isn’t sustainable

Founded in 2014, the Estonian technology company Levercode stands out on the local IT scene for its reliance on ‘old’ principles in creating more sustainable ‘new’ solutions. Sounds like a contradiction in terms, right? But the company’s CTO, Gustav Poola, says that old principles can be surprisingly innovative. In this interview he talks about how you can create solutions that are truly reliable as opposed to the sort that constantly need patching up.

What kind of problems does Levercode work to sort out?

We’re a tech company. Most people think tech or IT companies have to have loads of people doing programming and coming up with solutions whatever field they work in. But our view at Levercode is that we don’t want to have to deal with programming, which is to say sorting out a problem, off the bat. First and foremost we want to model the nature of the problem: what factors caused it?

When you start to model a problem – who’s involved, who the problem affects – quite a different map emerges. And on that map we want to be the go-to expert in problem-modelling.

What are other companies doing differently?

All too often when coming up with solutions, the fact the solution doesn’t yet exist is seen as the problem. No one asks what the problem is that needs to be sorted out. And companies involved in IT and programming don’t usually have an answer to that question.

In any case, in IT terms, Levercode is more of an I company than a T company. Which is to say we’re less about tools and more about mining the mapping and modelling processes for information and data. We try to find out as much as we can before we say we’re ready to offer a solution.

So others are approaching it the wrong way round?

Everyone says there’s a lack of programmers. But it’s not that at all – there’s a lack of big system engineers creating the basis on which people should even set about programming in the first place.

We want to work out what’s at the root of the problem. When someone says they’re coming up with solutions that can’t be found on today’s market, that’s not a problem. Levercode looks at big systems from the point of view of the data processing we want to improve so that the underlying problem goes away.

What’s needed for that?

You have to look at the basic components everyone works with but which get very little attention. For Levercode, those components are data, processes, where the data are processed and constraints, which is to say regulative norms. So like money laundering laws, the requirements of the Financial Inspectorate, protection of privacy – all of which are constraining factors you have to take into account.

We’ve put together three things: data; interoperability, i.e. the data exchange layer; and access – who’s allowed to get involved in processes. Identity has been productionised as LeverID. That means access to processes is only granted to those who are identified and need access to process the data they have to process.

How do you ensure system security?

An unsecure system is just a system whose specifications are wanting. Our education system produces a lot of programmers who study programming in different languages, but there’s very little focus on training up risk assessors for big systems. You can’t start coming up with a solution until you know what the problem is. If you make a list of the components needed in order to create a big, reliable, properly scalable solution, you’ll find programmers in quite a few places on the list.

The unsecure systems we see these days were created by people who were forced into a role they were unsuited to, or ended up in it because of a lack of anyone more qualified to do it. If that results in unsuitable output, that output still ends up being used by the next experts on the list. And it shouldn’t be that way.

And the solution to that is...?

The only way you can make something more reliable is by doing a better job with its specifications. The thing itself isn’t unsecure – it’s just doing what it was specified to do. If the specifications were wanting, or people were involved in setting them up who weren’t fit for the role, then down the line the need for all sorts of other security solutions will come up.

Our principle in Levercode is to start by figuring out what the problems are between the three components – data, processes and the parties involved in them – and creating a proper model with which to test the risks and the impact that constraints have on data-processing. Only once you’ve pinpointed and mitigated the risks can you work on the specifications. Only then should the programmer get to work.

Our principle is to approach solutions from the right angle. That way, in later phases, we can point out where low levels of reliability are likely to pose a risk or undermine the system. And then it’s easy to sort it out down the line. If you approach it the other way round, chaos ensues.

There are a lot of solutions on the Estonian IT scene today that people are constantly trying to improve, like public procurement systems. What actually needs to be done?

The stuff that public funds are being funnelled into at the moment isn’t creating any new value, but is just about reducing the impact of mistakes that have been poorly modelled. We’re using systems that have been papered over so many times, but the cracks beneath them are getting bigger.

We live in a world that’s fraught with risks. Most of them never progress to actual attacks, but when they do, it’s not like someone kicks your infrastructure doors in: the attacks our systems are currently coming under are purely mathematical. They’re incredibly hard to detect, because you don’t recognise their pattern until the attack is underway. If you haven’t done your prep – modelling and risk-assessment – the weaknesses are built in.

It’s not new programmers we need, but a new principle. We don’t need next-generation programmers, but people who’ll adapt the new principle to the existing IT landscape. At Levercode we want to process data in a way that guarantees the machine doing the processing is reliable, scalable and flexible.

So what is Levercode’s vision?

There’s more and more data all the time, and data needs to be processed. We all follow the law in our work, but laws act as constraints – and so you get ‘special conditions’. When you create a fixed solution that can’t be adapted to deal with constraints, all too often you have to work on pointless additional developments for it or start again from scratch.

If we’re coming up with an identity platform and data exchange layers that have to work long-term, our vision is to create solutions that will be adaptable to the ever-increasing number of constraints imposed by laws. If those constraints affect data-processing, then for fixed systems that means an attack on your business model. Our vision is for those business models to be as adaptable as they can be in regard to the right systems. We work to ensure that constraints don’t slam the brakes on business models and the achievement of their goals.

What sort of people does the Levercode team need?

People with a broad outlook who are all about synthesis. By which I mean creating something new based on data collection and analytics. I don’t want to step on anybody’s toes, but the technological approach that’s being widely taught in Estonia today is pretty superficial. Levercode needs big system engineers more than it does software creators.

We need engineers who work on the creation and risk assessment of process models and automatics. The kind of people who create abstract models whose value lies in the fact that they’re noise-free. When you come up with a model, you realise who the parties are and what data and processes are involved. Programming based on applied testing is really popular at the moment, especially among younger people, but it doesn’t guarantee long-term sustainability.

Formal logic solutions these days are too simplistic and don’t come with the strength calculations needed to take them out of the lab and into the real world of the Internet. No programmer knows how many protective layers need to be built around a logic construction so that it’s capable of fending off attacks and dealing with regulatory constraints whilst maintaining its reliability and functionality in all of the evolving situations it’s designed to operate in. Programming today isn’t addressing that.

We’re on the lookout for people who’ll provide the sort of strength calculations that will allow for good programming work further down the line.

Share this article: