Raiffeisenbank: Our purpose - to come to superperformance of development teams on methodology of Google

Nikolay Knysh, CTO of retail business of Raiffeisenbank

The moment when the IT stops being the selected service for business and becomes its integral part, has an accurate cut-off: IT commands have business KPI. As shows experience of the world IT companies, it has a huge impact on speed and quality of product development. Raiffeisenbank which in many respects became the IT company – a quarter of employees of the bank in Russia works at IT positions – also saved up many cases connected with development the DevOps-expert.

Our experience shows that for perekhodgoa from interaction on politicians and regulations to joint work several years, the sequence in development of DevOps-approaches and active information support in bank are necessary.

Credit cards were one of the first products of Raiffeisenbank in which development began to be conducted using the principles of DevOps. In 2017 the credit card with the non-standard greys-period in 110 days was started in only four months. Before transition to DevOps the similar project, taking into account testing of a product, could take year.

At the end of 2019 for new debit the Cashback of the card occupied transition to the new module of calculation of a cashback two months. What changed during this time and what errors need to be considered, making transition from classical methodology of development to DevOps?

DevOps: high culture of life

The importance of standards in DevOps is even higher at agile approach to development of products. Working with 25 self-organizing commands, you are not able to afford to have a mess in engineering practicians. The first that needs to be made, - to find time to development of end-to-end standards. When independent experts carry out the assessment of our DevOps-approaches, they are impressed by development of our IT standards.

Their development began with the fact that a few years ago we tried to write in general all standards and to force each command to adhere to them. Specially trained people went with the long list of all tools on leaflets and noted ticks whether the command uses this or that standard. It did not bring good results.

At the Moscow office of Raiffeisenbank

Now we do not demand compliance to all list of IT standards from our commands, we were focused on several main which allow us to move quicker to full-scale internal internal open source to approach. For example, this autotesting, review of the code and practice of continuous integration\continuous delivery and also trunk base development. If earlier control over software was administrative, then now it is scripts which are automatically connected to repositories and check them.

One of key roles which appears at this stage is the technical lead. It is not in classical scrum-models, however this role allowed us to provide efficiency of development process and support of software and also implementation of standards and the practician in product commands. Technical leads played them key roles. Explaining to our IT commands that the most difficult platforms can pass to DevOps, we often cite as an example Oracle Siebel CRM, a classical bank CRM system. By default it, perhaps, is the most DevOps-unadapted, Siebel does not provide the classical mechanism of control of versions of objects, it is impossible to connect popular static code analyzers to it (for example, SonarQube), it is badly adapted for implementation of autotests and avtodeploya.

At the same time in bank about 10 independent commands to which to have to live in a uniform release cycle of a system are already engaged in development in Siebel. To organize smooth and painless development process and supports of a system, we had to develop standards of multi-team development, to create own framework of autotesting for Java and to construct the mechanism of transfer of changes, general for all commands, between Wednesdays on Atlassian stack.

Change of the BPM platform was another story of success. In Raiffeisenbank a BPM system is responsible for modeling, execution and monitoring of operation of credit pipelines. In 2018 we passed from the monolithic BPM platform which used at that time, to the BPM solution Camunda. It was selected for several reasons:

• the solution architecture supports DevOps by default, it does not need to be finished
• allows to display quickly new services in produktiv
• the platform has open source codes
• maintains the maximum level of automation (testings, data migrations)

On the moment of start of transition to Camunda regression testing of the solution took 6 hours. In several months we managed to reduce this time till 2-3 o'clock. Now regress of start of new services and updates of the credit pipeline takes no more than 1.5 hours. Thus, from the moment of start of migration we managed to reduce regress time by Camunda by 4 times. Also it was succeeded to reduce considerably quantity of errors on production environment.

One more important step which we take now – selection of a role of domain experts. Their task is to give the greatest possible examination on each of the directions of development. For example, we will have domain autotesting experts, a frontend to development, monitoring. A task of these experts – to come to product commands and to analyze a maturity of each command in the examination, to share examination with a command and to implement the best practices for each platform.

IT the specialist of Raiffeisenbank in division in Omsk

What's next: perspectives of development of DevOps in Raiffeisenbank

We set before ourselves the purpose to come to indicators of superproductive development teams on methodology DORA/Google. For this purpose it is necessary to bring indicators of speed of development software, its stability and availability to peak values and to make so that they mutually strengthened each other.

This year we will pass to use of OKR model – the uniform command purposes for the owner of a product, a technical lead, a scrum master and the domain expert and also a development team. It will allow to remove the main contradiction between business and development – business itself comes to understanding of need of observance of IT standards when sees that their non-compliance leads to the fact that it cannot release new functionality as quickly as it is necessary.

Instead of the conclusion: 4 errors which need to be avoided in DevOps if you bank

1. Do not ignore culture: for full transition to DevOps it is necessary to begin with buy-in from the management and commands, but not with tool kit. Give to a stage of start of an initiative time, significant for such big transition.

2. Do not revaluate the forces in implementation of IT standards, otherwise you will waste time. Select 2-3 practices, be focused on them, on reaching result expand sleep juice.

3. Be not afraid to begin with the most difficult and unadapted systems and applications to DevOps if it is your priority.

4. Do not use standard approaches to organizational structure. If you need roles which are not in classical frameworks – experiment and you enter them.

The source of a photo is Raiffeisenbank