Origination Platform: Someone Else's Failure Is Your Problem

Dmitry was born in Serpukhov but spent his conscious childhood in Ryazan. He belongs to a generation that had no computer as children, and getting one changed a lot for him: after the fourth grade came a gymnasium, by the eighth a maths-and-physics track, and computer science with Pascal and environments for algorithmic thinking became his favourite subject. Abstract mathematics attracted him less: in programming he saw the middle ground between algorithms and a result you can touch. Then came WordPress sites built for money and a first attempt at C++ that scared him off. His class worshipped Moscow, but he found no motivation to drill with tutors for a capital university, so he read what he recalls as applied informatics at the Ryazan radio engineering university. University gave him time management and the habit of owning what he learned, and his brightest memory is a first-year project where he wrote and kept complicating a game. Hence his conclusion about himself: the product comes first, not the technology.

He found his first permanent job in his fourth year: a coursemate mentioned he was already working at the bank, Dmitry asked for a referral and got a week from the recruiter to prepare — he barely knew Java and spent that week catching up on it and SQL. The employer was a contractor whose director was a former bank employee, and the bank itself was its main client. He was asked to post his CV on HeadHunter; the next day Sber wrote to him, he went there too, ended up with two offers and chose neither technology nor salary but the company: a small young bank where something might work out. He joined in 2016 as a Java Junior Developer, though there was little Java in it — IBM products, JavaScript and SQL. A BPM department of eleven people did everything, so he touched the application flow, scoring and verification alike; the bank had around five million clients then, and its products lived in one monolith.

Dmitry calls the replacement of the boxed solutions luck: he landed with two seasoned engineers, both architects as he recalls, who owned the core of the application flow and were rewriting it, felt permanently stupid next to them, and grew from a junior into the engineer who moved verification off IBM alone. There were two big iterations. The first swapped IBM for Java and Java EE with its application servers, minimal changes but an extensible flow; the hardest piece was the homegrown task engine holding process state, and the steps moved into separate packages behind interfaces: launching SIM cards meant extending the model and a few ifs, since a SIM card needs less scoring than a credit card. The main problem stayed — one team, one service and one planning queue for products with wildly different economics. The second iteration kept the shared steps — storing an application, submission, scoring, deduplication — in the core and moved the specifics into what they now call the product process, starting, as he recalls it, with investments. Alexander sees a healthy driver here: the autonomy of business verticals.

The next turn grew from an everyday pain: the team was growing, repositories appeared several at a time in some weeks, someone wanted them templated, two interns were hired — and Dmitry, as their mentor, found himself leading the department's first infrastructure development team. The team built repository templates, a tool with statistics on broken applications so support could prioritise fixes, an application health tool for business troubleshooting — working out where an application stumbled between scoring and delivery — and shared tooling for mocks that became popular company-wide, because there are many integrations and little chance they all work in the test environment. The idea that the business draws BPMN boxes while engineers implement them never became reality: the diagram lives in the code and in version control, nobody holds a monopoly on it, and an engineer is still needed beside the stakeholder and the analyst. Dmitry explains Camunda's popularity by its golden mean, and calls the promise that the business will design everything itself wishful thinking.

The department the team lived in dealt with reliability as a whole — third-line support, development and SRE — and Dmitry, by his own joke, started sliding, or rather climbing, towards reliability. The domain's specifics are a combinatorial explosion of integrations: the application flow stalls if any master system sneezes, if a client cannot be saved or scoring does not answer, and the availability graph looks like a fir tree where one fallen branch turns it all red. Hence retries, circuit breakers and a long fight for seconds: the calls run sequentially, so the mobile app's response time is the sum of many systems. The tool the company uses to compute availability was born in that department's SRE team — you cannot manage that many dependencies without measuring them. Alexander adds that nines multiply, latencies accumulate and without tracing such depth is impossible to unpick. The longest part was cultural, not technical: unlearning the habit of calling a neighbour's failed call somebody else's problem, when the backlog held no share for technical work.

Via a deputy role and the reliability group Dmitry arrived where he is now, responsible for both reliability and the Origination platform, for over two years. The word, he explains, is better known on the market as activation or onboarding: the platform starts right after acquisition and carries the client to the point of active membership in the ecosystem. The difficulty is an equation of fifty-plus large products, acquisition channels and the need not to crush the client with that choice, so the platform measures conversion into opening and into the ecosystem, client experience and, like any internal platform, time to market and time to change — the tax of its own constraints. The immediate challenges are a multi-product basket that breaks the one client, one application paradigm, and two different flows for individuals and legal entities. He calls himself a technical manager: he codes at home, works through the largest technical RFCs and through processes, and advises listeners to find a domain they care about, build reading into their schedule and not lock themselves into being just a Java developer.