Legacy: Facade First, Storage Later

Alexey is from the Urals: born in the late eighties in Krasnoufimsk, living in Yekaterinburg, he left school with a silver medal and got a home computer only in the eleventh grade. He came into IT through a vocational training centre that gave schoolchildren a trade: seamstress and typist for the girls, driver training for the boys, and computer operator open to boys and girls alike. Entry to programming meant a lateral-thinking test — a rooster laying an egg on a sloping roof, the right answer being that roosters do not lay eggs. They were taught Basic and Turbo Pascal, and once computing arrived at school, Alexey finished a task, went to the canteen and came back to find the whole class and the teacher copying his solution. He applied in the pre-unified-exam era, when university exams clashed, and chose a vocational pedagogical university: much pedagogy and psychology, little computer science, and databases as the most interesting subject — the only exam he failed first time.

After graduating he returned to his home town to settle the army question and became system administrator of the district financial department: nobody to learn from, and a working day bookended by switching the server on and off. At his interview the panel read out a printed list of questions with answers and checked his wording — Alexander calls that a classic interviewing anti-pattern. Two years later Alexey returned to Yekaterinburg, freelanced in PHP and joined a consultancy with two departments: one rolling out quality management standards, the other implementing a document management system built in Izhevsk. The biggest optimisation for clients turned out to be parallel approval: paper travels from person to person in sequence, while the system lets them sign off independently. Alexander recalls his pedantic ISO 9000 lecturer — product quality is secured only through well-run processes — a thought that returns near the end.

What kept Alexey in consulting was an offer to lead a new direction: instead of customising a closed platform, build their own technology base. The economics were simple — a licence plus mandatory annual support, while many of the platform's functions were useless to small companies; open source ideas and import substitution were in the air, and the old solutions required Windows. He chose Java and a framework from a Samara company, then called Cuba Platform: Spring, interface rendering and a built-in BPM engine in one box. The first product, for the neighbouring quality department, took almost a year and, he admits, never took off — another idea did. He and a colleague joined a Yekaterinburg bank as outstaff on the same framework, writing a credit conveyor: an application walked through steps up to scoring, with processes running in a standalone Camunda. He tells one of those failures himself: they did not understand concurrency, everything worked on a single application, and in production the applications stalled with exactly one processed.

A couple of years on Alexey joined the staff as a senior developer, and when the colleague acting as team lead left he took over development — ten to fifteen people — while still writing plenty of code: scoring configuration tables, and queues built inside Oracle to replace the shared MQ, which under their load took down the rest of the bank's queues. During covid he looked at the market, chose by company rather than domain — a large company always has rotation — and joined T-Bank as a developer in the process reengineering team switching Siebel off. Ironically, at his previous job he had only just rolled the same CRM out. Alexander jokes that the system meant to bury Siebel ended before Siebel was switched off, and notes that parachuting developers into other teams' services is a rather poor practice. Alexey explains the reason by scale: the business grew several times over, the system was never designed for that, Siebel going down meant the bank going down, and recovery took six hours.

Next he was asked to stand up the companies domain team: a developer from Yekaterinburg, an analyst and a tester from Siebel, and the job of giving consumers a REST API instead of SOAP. He designed the API, agreed it with stakeholders and shipped it quickly as a proxy over Siebel — consumers migrate onto the contract while proper storage is built underneath. In roughly a year it worked out: two-way replication with a chosen master, where whatever reached the old system takes priority, and a service comparing data across databases by configurable rules so the team spots divergence itself. The replication services were made configurable: edit a config, restart, and they pick up new Kafka topics, tables and calls. Alexander calls this the classic way to organise a migration: agree the contract early, hide the implementation behind a facade, run the stages in parallel. A funny effect: with the load gone Siebel became very stable and the remaining teams saw no reason to move; his team sometimes deliberately delayed fixes, while readiness for the full shutdown was checked centrally — outages of a day, then two, then three, on test before production.

As an architect Alexey built shared tools for the department: Entity Constructor, for instance, spins up storage with ready-made CRUD from JSON over REST and helped with the Philippines launch. Then the CTO said reliability needed harder thinking: availability targets and incident management appeared, and Alexey was named CRO, chief reliability officer. This is where the quality management standard paid off: an incident means correcting the consequences, finding the cause and closing it with a corrective action. He started with transparency and the question of why nobody knew, then set up metrics, a service map and observability. Standard platform offerings were not enough: Postgres was sharded, the balancers stayed bespoke because of access rights and masking of phone numbers and names, and the search index lives separately. On AI he says it gives the product speed but harms juniors: the interview answer is there, the depth is not. He still counts himself an engineer, yet now prefers managing several domains; he wrote the architecture reviews himself at first, then assembled a pool of reviewers, leaving the decision with the team.