Interview with TAdviser: Alfa-Bank chief information officer Sergey Polyakov On upcoming digitalization 2.0

Sergey Polyakov: Let's start with paper. Paperlessness is a symbol and measure of the level of digital maturity, and not only a practical task. However, the issue of achieving this goal is mostly not related to IT, but to regulatory and legal requirements and practices, well, just human habits. Technically, making processes paperless is not so difficult - there are databases that store images, and applications that recognize and convert images into texts. There are ways to protect electronic documents with electronic similarities of "watermarks" or, say, steganography. There are unstructured data storage systems that can be indexed and searched quickly. There are processing chains that use such objects - this can all be done, it's a lot of work, but engineering is not very difficult. So the challenge is not technology.

As I see it, now in various government bodies there is a process of digitalization, its own distraught, and it must be assumed that there are a lot of people thinking about how to change requirements, legal norms, regulation, approaches. This means that the following may happen: we are now investing in paperlessness based on current regulation and generally accepted practices, and regulation and habits will change in a couple of years, then investment may be premature. Therefore, in solving the paperless problem, not so much a strategy as a tactic is important: a general vector for eliminating paper documentation, but with the focus and prioritization of processes in which an understandable regulatory, legal and behavioral picture is already developing. As a curiosity, in many points of sale in the States, after entering the PIN code, you will also be asked to sign a check. Not much...

Sergey Polyakov: The bank's work with me personally has definitely flowed completely.

The idea of ​ ​ banking digitalization as a whole is to transfer customers to remote self-service channels. Mobile bank is one of these channels. Good, in any case, in plain sight, mobile banks today do not only lazy. I take advantage of many of them, everyone has some features, fun, but mainly, cosmetic differences. Today, the mobile banking application is a mature product, and even if you are not able to make mobile applications yourself, you can contact the external organization that will build it for you.

Customer-centric value moves from a great interface to reliability and the ability to perform a wider range of operations. And this is already a merit not so much of a mobile application, but of all that is behind it - a bank middle and back office.

In the first wave of digitalization, banks had the task of transferring basic one-step transactional relationships with the client to mobile applications - to see the statement, to transfer money. I came in, I did, I came out. Everything was simple and fast, ejail teams baked microservices supporting similar functions as pies, time-to-market counted for hours, everyone rejoiced and thought that this would always be the case.

Then the simple "digitalized" interactions ended, and everything became unexpectedly difficult. We want to do more interesting things in a mobile bank, receive services that, by their essence, cannot be executed in a second - say, mortgage get. We want the bank to guess our needs, think for us. Such tasks are not solved in a mobile application, this is solved in the deep layers of the technological and operational infrastructure. Somewhere in the bowels of the middle office, many elements and processes should interact, plus it may be necessary integration with external resources - with state authentication,,,. And Tax Service TRAFFIC POLICE credit history bureaus all these deep processes should give you a result in the form of "yes," "no," or somehow, like "yes, and this is what we have for you, since you are here..." in the mobile application.

From the point of view of the mobile application, everything is simple - I asked a question and received an answer, it is no more difficult than asking for an account balance. But unlike the balance service, which several programmers can do in two weeks in the form of a microservice, a complex query triggers a tortuous process in the bowels of banking systems that can crawl with a snake for hours and days, come to the surface in the form of additional interaction with the client in the same mobile, or maybe a call, and dozens or even hundreds of people are already working on it, and many systems are involved. Whether these systems are ready for such interactions and integrations is a central issue and a challenge to the second phase of digitalization.

In the department, such a complex service is provided by an operator or client manager - this person is your "technology" of integration. He can go to one application, to another, write something on a sheet of paper, put it in the third application, and here you got the answer. When you have a digital bank, this process should be end-to-end, automatic, it should not be tied to either a person or paper (remember about paperlessness?). And the result should be exposed through a mobile application. The mobile application is only the tip of the iceberg, everything else inside. Reformatting internal, deep systems for these types of tasks, tasks of the second phase of digitalization, and there is our root task, our challenge. This is something we will be working on for the next two or three years.

Sergey Polyakov: I don't know this. And this is such a good "I don't know." I do not want to know this, because my task as the head of the technology block is to build a scheme, an architecture that allows you to solve entire classes of problems, and not to find private solutions for momentary problems. Therefore, I need to know not about the future features of applications, but about the classes of upcoming tasks, and their mapping to interacting technological stacks. For example, between the moment when something comes to the head of the business line, and the moment when we can realize this, some reasonable, limited time would pass. Say, three months. But if I tell him "I'm sorry, but we are not imprisoned for this, we first need to build a bridge between the data storage module, the credit module and the compliance system, and it, this system, I'm sorry, will refactorize, so we will need to wait another six months," which means that I have not completed my work - the technological stacks should not only be ready, but also ready to interact with each other.

The danger of your question is this. If I know what specific functions the business wants to implement, I am tempted to start building solutions specifically for these functions, very quickly, but very specifically. With ejail teams, this often happens. But I do not want to be in this situation because then I will get into that immense task of cross-system integrations that we have already talked about. Don't get me wrong - IT naturally has an understanding of what type of tasks the bank will solve for the next few years, in which direction business lines will move. For example, we will develop mortgages and cash loans, we will improve scoring, we will improve the customer recognition system for secondary offers in order to make them more relevant, monetize data, and be distraught. The number of different ideas on the business side is huge - but it is impossible to build technologies specifically for each, and therefore I look not at tasks, but at task classes, and I also build technological architectures for classes, and not for specific tasks.

Sergey Polyakov: This is the other side of the same coin. If at first we talked about remote self-service channels, then we are talking about close service channels - through operators in the departments, well, on the phone.

As the theater begins with a wardrobe, the bank branch begins with the arrangement of a digital queue. When the client came to the department, first he needs to be identified, then, identifying, get additional information - both obvious (demographic and legal data) and enriched - all that will allow us to form an appetizing, personalized offer, or even two or three, while the client goes from the threshold to the window. Well, let's not forget, we need to do what the client actually came to the bank branch - to provide him with a service.

These tasks - identify, learn better, find out why came, offer, perform - can be performed by different IT systems. But ideally, all these functions should be consolidated into a single information and operational ecosystem that feeds the bank employee who interacts with the client in real time. This system should prompt ready-made proposals, allow them to be executed immediately. Such a multimodal single workplace can be called differently. Someone calls it a single front office, someone calls it an expanded CRM system. We have moved far on the way to such an expanded CRM, I think that next year we will complete its creation, synchronously with the bank's strategy to build a new generation network.

Sergey Polyakov: Two main ones, one of which is related to CRM, with demography and personal direct and enriched information, and the other is operational. More and more functions of the operational application migrate to the demographic, in CRM++, our United Front. Why can't all these functions also be transferred to other channels, such as ATMs? I don't know. For me, for example, the mystery why the ATM screen is what it is. This is some relic of the past. Why doesn't it look like a screen on your mobile app? After all, all functions are the same. I think it should change.

Sergey Polyakov: Where possible, we use ready-made technologies and ready-made applications. And we do it with pleasure. We know how to integrate them and will continue to do so. I do not have a tough position on what should be done only by external forces, and what - only by internal ones.

Sergey Polyakov: You know, the market of Russian technological workers is so tight that you can come with any principles, but reality will immediately sober you. And when you say: "I want to hire 100 programmers in Java, on Pega, on Camunda, on SAS, on Scala," the market will laugh and answer: "there is no one and there will be no such thing in the coming year - either teach people yourself, or here is a contractor who is ready to offer you these specialists."

Sergey Polyakov: In my opinion, such a thing can be done once. Next time, either you will have something written in the contract about it, or the contractor will no longer work with you. It's impossible to do business like that.

Now we freely interfere with teams of our employees and specialists from contractors, but the general principle is: if this is a target platform, then we would prefer to hire people in the staff. If this is a non-target platform, we would prefer to have an external contractor that supports it. Moreover, it does not matter to us whether the mission critical platform is. We have unearmarked things that are nonetheless mission critical.

Sergey Polyakov: For example, one of the platforms used now in the departments. In the end, we will leave it, so it is inappropriate. We also have one of the mobile banks, which is quite widely used, but which is not targeted. He is good, he works perfectly, and if he does not work, then there will be discontent among a large number of people. But in the end, we will transfer its functions to our standard mobile platform.

Sergey Polyakov: Yes - if there is an examination, if the contractors know their business, why not.

Sergey Polyakov: The Alpha Laboratory worked on the principle of "client paths" (or customer journey), this is a certain form of development organization. Now there is no Alfa-Laba, but the approach to building a new functionality for the end client and for business remained. Most of the business functionality will be done using this approach, this is part of the bank's strategy, and this approach is probably today the de facto standard for advanced organizations. But there is also a danger on this path - the organization of IT "from the client" and not "from the technological platform" can lead to the fragmentation of technological platforms.

Usually, each client path is an agglomerate of several ejail teams of 8-9 people who work on a wide topic, for example, a mortgage or salary projects. If these teams do not look at each other and do not follow some general architectural drawing, then the technological stacks can easily spread.

One of the reasons for criticizing Alfa Laboratory was that it often introduced the technologies that were required at the moment to fulfill specific tasks. As a result, this led to an unusually rapid increase in functionality from the point of view of the client, but left a whole field of miracles from technological solutions.

At the beginning of the conversation, we talked about the fact that in the first phase of digitalization, relatively simple functionality is implemented, associated with fast one-step transactions and communications between customers and the bank. But in the second phase it is already necessary to integrate complex processes, and this is already happening in middle- and backfires. At this stage, the kunstkamera of technologies, prototypes, MVP becomes not only expensive entertainment, but also begins to break what we went to the edgail - Time-to-market.

With such difficulties, I assume, almost all organizations are dealing. Many of my colleagues who manage technology departments have a similar impression - a breakthrough using flexible development methods left us with a lot of technological half-solutions, MVPs, which now have to be somehow integrated and forced to interact, which is long, expensive, and most importantly, completely unexpected for the customer.

The textbook proposal to solve this problem, which involves the involvement of a strong architect, does not work very well, because no architect can tell the customer: "Sorry, the release of your service will be delayed for six months, because this violates my architectural principles." We need a specific contract between the needs of IT, the long-term needs of the business and what is needed in the moment.

Of course, you need to have a good architectural drawing, but not dogmatic, but practical. In addition, it must be understood that the problem of technology sprawl is also a problem of project management. If you hand out a drawing to all the teams at the construction site or in the workshop, and they will work on it, then each of these teams interprets the drawing in its own way. Therefore, in addition to the architect, there is a foreman at the construction site, and there is a master in the workshop who make sure that the interpretation of the drawing is the same.

Sergey Polyakov: Yes, they understand. Digitalization of the 1.0 went from about 2006 to 2012-2013 years. Quite quickly, technological artifacts appeared in the Agile mode, mobile banks and Internet applications proliferated. But then suddenly everything slowed down, and IT managers began to say: "oh, you know, there is work for two years, and here for two million dollars, and here you need to buy licenses...." But what about? It was so good just recently! What happened? And what happened was that they poured ingredients, technological stacks, and the next class of digitalization 2.0 solutions already requires internal integration. Integration is a long, unpleasant and mutter thing.

Sergey Polyakov: Naturally, we will continue to work on the Agile model and with client paths. This is really a very effective way to deliver functionality to end customers. But at the same time, we are returning the idea of ​ ​ platform. We identify the targeted platforms and technologies with which we will live. We reorganize IT, creating functions and processes that in many cases will be grouped not around the business process, and not even the business customer, but around the technological artifact itself - the technology stack, the platform. Development driven by the interests of product owners will be balanced by long-term requirements for the health and efficiency of the IT infrastructure. This may seem old-fashioned to someone, but, in my opinion, it is a good and sober approach, which today will allow us to continue to quickly create business value, maintaining a compact, coherent technological design and a rational economy.

Sergey Polyakov: Suppose I now have at least three technological platforms for building mobile banks. And several mobile banks operate on different technology platforms.

Sergey Polyakov: Yes, different teams worked on them, they created this or that functionality for different business units at a fast pace, sometimes for three months. The financial service may have asked why there are so many of you, and why are you so expensive? This question could be answered as follows: "You know, this is inexpensive compared to how much money we earn using these applications," and until a certain time this answer satisfied everyone.

But then more difficult tasks arose - say, to combine the salary projects of legal entities with individuals who work for these legal entities. The same business units are counting on quick solutions, but the IT block cannot do this quickly, it is necessary to cross technologies that have grown in isolation from each other.

If we do not want to fall into such traps, we need to combine applications on a single platform, on a single architectural concept. Then I can move people from one project to another, from one team to another. I will be able to effectively manage my resources, I will not need to train 100 people in 100 technologies, and then we will return to high performance.

And therefore, in the IT strategy, we are talking about platform, and the fact that in addition to client paths as a method of creating user functionality, we will grow and expand platforms. We will ensure that our solutions, which we will make on client paths, stand on large supported target platforms, which will become a number of fewer. Well, we will refuse some platforms that we do not need.

To implement this strategy, we need an architectural picture and the professionalization of project management. Architecture already exists, I inherited it from the previous IT management, and I like it, by the way, I don't see a reason to change something much.

Sergey Polyakov: When I say that Alfa-Bank IT needs professionalization, I don't mean that unprofessional people work here. The level of competence and talent is running high here. I'm not kidding, I've seen a lot of things. But if, for example, you are well-trained fighters, and you will be put in a car, and ordered not to go out of place, there will be no sense from your skills and talents. I want to put people in this way, and manage them in such a way as to extract the maximum potential that is laid in them

IT at Alfa Bank has accelerated in terms of delivery of final functionality, has achieved extraordinary flexibility in terms of delivery of this functionality, in particular, due to the dispersion of design control and mitigation of architectural requirements. IT has also grown a lot, and now you need to work on management - this is always a cyclical process, now is the time to focus. This approach is congruent with the overall strategy of the bank - to do less, but most importantly. We will see the first results this year, and systemic changes will take root within a couple of years.

Sergey Polyakov: I will not call abbreviations, because the names are not very important. In fact, we will have a single target platform for all mobile applications. It has already been selected, it is completely modern, there are all the necessary words - microservices, containers, dockers, container management. The task is to transfer all applications to it and not build applications on other platforms.

We have a single platform for branch employees, which should be transmodal, combine both CRM and operations, we have already talked about this a little - in our work with a single application, the client manager should be able to identify the client, and understand him, and sell him the product, and fulfill his request.

Everything that the client does in his mobile application, in theory, should appear both in the operator and in the contact center. The running term for this is "omnichanality." This is a difficult task, not because all functions must be represented and generally identical in all channels of interaction with the client, but because the process that began in one channel can then move to another. You started doing something in the mobile bank yourself, and finished with the help of an operator. Or, on the contrary, the operator began to do something, and he asked you to confirm something in your mobile application.

Ensuring omnichannality is not easy, under all channels there should be a single middle office infrastructure, which remembers what the client did there, there, and there. This leads to the tasks of building a common CRM, a common layer of state storage, common directories, and these are expensive tasks.

Sergey Polyakov: The general resource base on which we rely is about 3,000 people. Some of them work in the state, some - with contractors. Detailing is not very important. Something goes out, something goes back in, and it's not very significant to me.

Sergey Polyakov: She has already slipped back to other structural units. There are, of course, IT enclaves that are located inside business divisions - in an investment bank, in a processing center. But basically IT is consolidating. The total number of 3,000 people is approximately divided in half between escort and development. In the direction of development, I think we will come to the fact that about half of the people will work in "client ways," and the other half will be associated with platform, deeper developments. This is probably some version of two-speed IT (bimodality or two-speed IT model, - approx. TAdviser). There are organizations that say that two-speed IT is dead and so it is not necessary to work, that the whole organization should be Agile. I don't believe that.

Sergey Polyakov: Agile-organization is the one that uses the Agile-approach to the very depth of the technological stack. The results, in my opinion, are ambiguous. In particular, the spread and reproduction of technological solutions. I want IT platform back. I want fewer platforms. I want them to be enlarged. I want their development to go a little differently. And I want IT artifacts to have IT owners, not business, to have a person on the part of IT who would be responsible for the fate of a particular platform.

This is the same relationship as between the construction architect and the customer. He builds a house, puts a floor, puts pipes, and you are at the end of it: "and I want so, so and so." At this moment, someone should say: "Yes, but here's what will happen." As a technologist, I certainly have responsibility to the customer in the first place. But there is also a certain metaphysical responsibility to the product. I can't do an engineering thing.

Sergey Polyakov: The house may not collapse, but the customer will ultimately be dissatisfied. You yourself will not be happy with your decision, you simply do not yet understand all its consequences. Therefore, it is important to find a balance and understanding. A person in a restaurant may ask: "give me an omelette, I want in a minute." He can answer: "Please, either eat a raw dish or have to wait." I, as a good cook, refuse to give out an untrusted dish even if the client demands, I have a responsibility to my product.

With omelette, it is clear that everyone has personal experience. But with microservice infrastructures, the customer usually does not have such experience. Therefore, I have to explain why sometimes it is better to spend time, money, efforts on platform development in order not to be poisoned by this thing, continuing the omelet analogy.

Sergey Polyakov: The cloud is a fashionable word, it came to us through the efforts of many, the most famous is probably, and Amazon it has a place. But you need to understand this. The goal of the cloud is an endless stepless scaling of the computing infrastructure, following the growth of a fairly simple, homogeneous business service, such as social networks an online store, etc. Businesses and IT models of such organizations are now closely studied, they are afraid, they say, now they finance will rush, their methods are taken as an example. Colleagues from some banks travel to Silicon Valley, watch how it works or Facebook , Google admire infrastructure. This is great, but at the same time you need to understand that a universal bank is a much more complicated thing than Facebook, Google or. "" Yandex The complexity of the processes is incomparable. In the end, the same Facebook is basically one very advanced digital service, solving, from an IT point of view, the task of scaling by a billion users. The tasks of universal banks are completely different, the structure of the service and product is incommensurably more complex, and simply our increase in cloud capacity does not solve our problems.

Sergey Polyakov: In particular. There is no reliability task on Facebook, by our standards. And in Google there is no - well, you will not receive a message from some of your friend or you will not see him in the tape - and what will happen to you? Or will you see different tape content from different devices? Or you will receive a message twice in the mail - and what next? What's gonna happen to you? But if your account balance is different in the phone and ATM, or your salary has come twice - here you will get together...

The cloud scaling approach is used by Internet companies that grow and collapse rapidly. The bank rarely has the task of quickly scaling some monotonous service. We have heterogeneous services, and we have complex integration tasks. I am not sure that in the cloud this is solved well, quickly and conveniently. Testing hypotheses, testing applications, experimenting - this is please.

The second difficulty with clouds is the rules for storing personal information. As an industrial solution for processing external customer data, it is also unacceptable under the law.

This does not mean that we reject cloud technology as such. In reality, if you dig in, many cloud organizations are actually just using cloud styling, a cloud paradigm to manage their own infrastructure. This is a useful activity, it helps smooth out the function of infrastructure growth, use it more efficiently, but calling it "we are in the cloud" is not entirely honest. We widely use cloud-type solutions for managing internal infrastructure, but we do not trumpet about cloud, we are quite on the ground.

Sergey Polyakov: Everything is driven by the economy. If the data center consolidation project makes sense, then we consolidate. Unlike, for example, exchange technologies, where the entire external infrastructure of market participants is tied to the location of the data center, and it is very difficult to move the data centers, it is easier with banking data centers - none of the customers puts their high-frequency trading robot in our data center. We do not have specific plans when necessary - we consolidate.