Geekly Articles each Day
📜 ⬆️ ⬇️

How we created Raiffeisen Online ...


Internet banking has long been transformed from luxury into a must have for any self-respecting bank. Needless to say, the application should not just be, but should be reliable, convenient and enjoyable to use. In one article it will not be possible to talk about all aspects of our Internet bank Raiffeisen Online, but I will tell you about our experience in creating a new version, its architecture and the difficulties that the team has encountered. Perhaps someone our experience will help save time and effort.

about the author


Let me introduce myself. My name is Sergey, and now I work as a release-manager in a team for the development of remote banking channels. In 2014, I came to the position of the team leader for the development of a group dealing with Internet banking. In the same year, we launched a project for a radical update of the Internet bank, in which I was lucky to participate in all stages and in different positions.

Summary of the previous series: R-Connect v1, v2


I, fortunately or unfortunately, did not witness the formation of previous versions of the Internet bank, so this part of the article plays the role of only a small historical excursion for readers.

Here I will not touch the first version. It was just an Internet bank, which several times became the best Internet bank for individuals. Java, Struts, Amen.
')
The second version appeared as an evolutionary development of R-Connect v1 as a result of the development of a mobile application.

It was here that it turned out that business logic and channel specificity can live well together when there is only one channel of interaction with the user. But when there are at least two channels, it is necessary either to switch to more convenient interaction protocols, or to take the general logic to a separate place. And, surprisingly, both decisions were made: for the mobile application, web services were made on SOAP, and the business logic was carried out in a separate layer. EJB, Websphere, the gloom.

Best Internet Bank 2009


The path to creating a new version of a product, nurtured in a corporate environment, usually runs through pain and humiliation, a desire to increase functionality and a disproportionate increase in the complexity and timing of its development.

The experience of development and support of the Internet bank version 2.0 has shown that we cannot implement the simplest requests from the business in adequate time. For example, change the term of validity or the conditions for opening a bank deposit. The pain occurred in different places: a strong connection between the server-side code and Javascript-logic, hard-coded descriptions of banking products, the logic of forms written in the client-side, tied to specific products, problems in integration with the master systems. The implementation of more complex tasks caused horror not only on the faces of the developers, but also in the minds of the business, which was beginning to realize what kind of monster we had grown up. But, as they say, awareness of the problem is half the way to solve it.

The main requirement for the next version of the product was the speed of development of new functionality in the future, ease of support, configurability of everything and everything.

But since we wanted not only to develop a new system, but to make the best Internet bank in the world, besides the substantial processing of the server part, we also wanted to seriously improve the user interface.

The key ideas of the new Internet bank around which the project was being formed were:


With these requirements, we launched R & D.

Rnn


Under R & D, a part of the team that was freed from production-tasks was allocated. She was tasked with finding a stack of technologies on which the new Internet bank will be based.

We considered different options:


A bank is an organization that likes to count money. Both strangers and their own. Therefore, the first thing the team went in search of a ready-made boxed solution, which could now be exploited, and tomorrow it will be profit. But the proposals considered by us did not suit for various reasons related to the possibility of improvements for us and the privacy of these improvements, the cost of development and support, and so on.

“If you cannot buy a finished product, then let's look for semi-finished products,” the team decided. And she went in search of some mythical platform, on the basis of which you can develop a unique product for the market. Analysis of the market and implementations showed that the most suitable solution for us is the portal technology and the so-called web portals. Although there were examples on the market of developing an Internet bank on Adobe CQ5, a large corporate CMS.

“Own development is so expensive and untimely! Why do we need to reinvent the wheel if the progressive community has already done it for us? ” - the team thought and started creating a prototype on the portal.

Prototype 1: Liferay Platform


Hey! Anyone Is anyone here able to work with Liferay?

I can not remember why we chose Liferay as a pilot solution, and not any other portal. But, nevertheless, we chose him and began to consider from all sides.

Since the Java developer, who understood Liferay, did not have enough knowledge in client technologies, they were given only one help at the time in the entire frontend team of developers. As a result, our first prototype was written on a wild mixture of custom JSF components. An attempt to bring the appearance of the resulting interface to the concept that our business was expecting was successful, however, a survey of the R & D team showed that opinions about the process and the result differ.

The client-side developer acknowledged that this was his first experience with the difficult and inconvenient world of Java-enterprise and JSF in particular, and, in the future, the resulting result will not be easy to develop and maintain, taking into account the requirements put forward by the business. And the server-side developer, on the contrary, was pleased with the result. Because he loves using ready-made solutions and used to work with JSF.

While they were developing our first prototype, swearing and cursing, an opposition movement emerged on the Internet banking team — for their own development. There were many meetings, discussions, drawing the attention of management to the choice of technology. The main theses against portals and Liferay, in particular, were:


And as the development of the prototype of these theses were confirmed.

We looked for examples of successful implementations of Liferay with vendors working with the bank, and could not find anything similar to our product. The results of our own test runs of load testing on the prototype showed that the proposed solution withstands the implemented functionality. Ambiguous. Go ahead.

Since it was decided not to distract the existing team from the development of R-Connect v2, we began to recruit a new team for a new project. The search for specialists with experience in developing on Liferay in Moscow has shown that this is not the most popular platform, and we cannot find such specialists in the right amount for the next “never” years.

With great difficulty, we found a developer who, lo and behold, had experience developing under Liferay. His experience turned out to be useful for us to prove the last point - in the previous company they actually wrote their custom solution, bypassing the limitations of Liferay and the JSR-186 standard.

Thus, over the past six months, we had a working prototype on Liferay, two camps in a team and an ambiguous future. By an effort of effort, it was decided to try his hand at creating a lightweight prototype in the “in-house development” concept, which was to confirm or refute the difficulty of developing the key customer requirements on its own.

Prototype 2: Own development


On the development of the second prototype, we could not afford to spend as much time as we spent on the first. I had to close my eyes, hold my breath and cut off the excess from our requirements.



As a result, we have left:


The development of the second prototype began with a stack that was familiar to the team:


In fairness, it is worth noting that the same frontend developer who participated in the development of the first prototype acted as the client-side developer, and the same Java developer who came to us with the development experience on Liferay acted as the server-side developer.

The resulting prototype dispelled the team’s concerns about its own development, and we, once again weighing all the pros and cons, made the final decision to take the path of independent development.





Of course, portal technology and Liferay in particular, already out of the box, have great functionality: CMS, widgets, role model and much more.

However, without major improvements, all this wealth cannot be used to create public services with a claim to uniqueness. All the advantages of such multifunctional technologies are trickyly crafted from the limitations that generations of programmers attacked in an attempt to create an abstract combine, and they can be used only in private corporate solutions with standard UI / UX schemes. Alas, but this is not our way.

Technology stack


- Do you have technology fresh? Send me a kilogram

Not everyone in life has the opportunity to start something from scratch. Even when you do it once every few years, you still feel this pleasant shiver of choosing "all the best in the world" when it turns out that there is a huge variety of technologies and frameworks in the world.

We have relied on new technologies, but which have already been tested in the corporate segment. Below there will be no lines about reactive programming, microservices, etc. - at that moment we were not ready to accept such cardinal changes. Here we will talk about technology, quite fresh compared to Struts, which was built R-Connect v2.

On the client side, we wanted to see HTML5, CSS3, and a cool JS framework. As the latter, Angular was selected in the first generation. React was still in deep beta and did not fit the role of the main framework in production-use for a serious product. ExtJS was not considered as a candidate at all, since the experience of its use by the team as part of the pilot and other projects showed that it is a library with a strong corporate component, and it will be more difficult and more expensive to remake it for us than to wind up what is needed in a modern MVC framework. Another candidate turned out to be EmberJS. It was not taken due to a slightly lower popularity than Angular. A lot of articles have been written about the difficulties of using Angular in serious projects, so it is here that the “goodies” will be missed. But if there is enough interest among the audience to our “Angular-flour walkings”, we will try to arrange it in a separate article.

In pursuit of the page loading speed, obfuscators and code minimizers were registered and, accordingly, the Javascript'a Gulp build system. For their work in the server of the bank, a Javascript enclave was developed - NodeJs. Nobody in the bank allowed such a thing to himself. We expected that now crowds of thirsting innovations of senior engineers will line up in front of our office. However, life has shown that crowds wanting to get a job in the bank did not arise, even despite the modern technologies.

Since we took new technologies without having significant experience in working with them, the frontend-team did not entertain themselves with the illusions that they could cope with the development without the help of the Angular-ninja. The cry was made about finding a cool developer, but after six months of searching for frontend-specialists of the required qualifications, we decided to continue the development with available forces, which during that time had acquired knowledge and experience.

Updates for the server part were chosen a little less reverently, since everything was already known for a long time and corresponded to the beaten track of the Java world: the latest version of Java 8 and Spring 4. Collect all this wealth with the help of Gradle, throwing the previously used Maven away.

There are also problems with a set of developers here, despite the popularity of selected technologies on the market. The problem is the same - lack of qualification.

Architecture development


The attentive reader probably remembers that at the beginning of the article I wrote that the version of R-Connect v2 appeared by highlighting the new architectural layers on EJB. Where are we sharing these same EJBs and why wasn’t there any more about them?

In short, the R-Connect v2 architecture presents the following picture:

  1. Client requests assumes front-line balancer. It distributes requests between nodes with channel logic.
  2. The banal Java web application running on Tomcat lives on the channel logic node.
  3. Channel logic nodes access through a separate balancer to business logic nodes, to those notorious EJB applications. We use IBM Websphere as application servers for business logic. In the business logic layer, the entire integration component is already hidden with our database and banking master systems.


I will not discuss the features of our technical solution in more detail; I will only say that in addition to the channel logic logic nodes that are public, we still have a number of internal services provided by our team to the rest of the bank, which also use common business logic and add fun to our zoo application.

When this whole layered cake was developed and implemented, the team was inspired by examples of academic architecture on the Java Enterprise model. What results did we get from this decision? Not the most positive. This is the complexity of debugging code on multiple servers at the same time (Tomcat + Websphere), the complexity of deploying applications to a production environment without interrupting services. One of the advantages of this multi-layer cake was to be the convenience of updating the layers separately from each other. But while the application lived and developed, the business logic API also developed and changed with each release. This means that in order for Java client code to interact with an EJB that implements business logic and resides on a different server, the developer needs to generate special stub classes, stubs for IIOP / RMI. That in the case of corporate solutions like Websphere or Weblogic can be quite a non-trivial task. Java developers dealing with similar server combines will understand me. After regenerating the stubs for each change in the business layer API, it was necessary to rebuild and test all applications that are tied to work with this API, because the changes are not backwards compatible at the level of the interaction protocol with EJB. We had four kinds of such applications, and not every release had any new functionality. But at the same time, each release caused pain to the entire team: from developers who had to make changes to all applications, and testers who tested “extra” applications, to AppSupport, which had to install these applications on a bunch of servers.

When we started writing a new version of our Internet bank, we reconsidered our approach to architecture and deployment in order to keep the best and remove the worst. As a result, we abandoned Websphere and dedicated servers with business logic. We wrapped it in a regular library and placed it with the other libraries in a channel web application.



The web application itself has also undergone a change. We turned away from Struts and similar approaches to building an interface “from the server side” and turned to a REST approach. This is a step towards unified services for Internet and mobile banking, as well as a start on the current theme with OpenAPI.

Difficulties and uncertainties


The most difficult thing in development was not just to rewrite, but to redo business integration, because the system we were redoing has been developing since 2003. Many decisions were made by different teams, and not in the best way, because as the bank grew, some systems died, others appeared, integrations wedged into one another, overlaid. However, this is a completely ordinary picture of the development of corporate systems. And in fact, we rewrote the Internet bank for a long time, including because we had to redo a lot of integrations, coordinate with all other systems, and wait for their modifications. Great work has been done. Also in the course of work, we were faced with the fact that not everything can be done beautifully, well and comfortably from the point of view of business logic.

The development was carried out for a very long time without any final prototypes and models, which also did not make life easier for us. Prototypes were constantly changing, we were looking for something that would suit us completely: we conducted research, piloted employees, discussed inside the team. And even when such prototypes were created, it solved only half of the problem - we still did not have ready-made designs. The final design appeared just a month before launch. We sat at night, copied, caught all the small bugs.

As I already mentioned, it was difficult to find suitable specialists, because it was impossible to immediately build up a team that could quickly and efficiently implement the project at the right pace. In general, there were very few specialists of the required level on the market, because good specialists usually do not look for work. And hiring insufficiently qualified people is costly, because they have to distract other team members to help them, which can reduce the speed of work altogether. So we looked for talents at the same time, and raised them.

Conclusion


In about a year and a half, we completely rewrote the Internet Bank, while adding new functionality. The new Internet Bank was piloted for six months by the bank employees, and during this time we were able to check not only the users' reaction to the updated interface, but also the speed of the implementation of everyday tasks from the business. What previously required a couple of days of development, testing and installation as part of a planned release, we have now learned how to do through CMS and reference books in the database. Significantly increased the speed of developing more complex tasks due to a more suitable architecture and smaller technological problems.

But this is understandable. Projects that imply serious refactoring are usually implemented with an eye to increasing the speed of delivery of functionality to the final client and reducing its cost. What else can draw conclusions from the above?

The first conclusion - do not be afraid to experiment and spend time on research. It is not always that which at first glance seems ideally suited to your tasks, such is.

Conclusion two - listen to the opinion of colleagues. Common thoughts can come from any team member. It is very easy for a manager to leave unnoticed that which forces him to roll back a few steps from his intended goal. It is very difficult to recognize that the work done was done in the wrong direction, and time and money was wasted. It is important to remember that not everyone in the team can have enough strength to defend their point of view and not retreat from the pressure of management and more experienced colleagues.

Third conclusion - the popularity of technology does not guarantee the availability of the necessary number of specialists of a good level in the market. As I already mentioned, it was difficult to find suitable specialists, so it was impossible to immediately build up a team that could quickly and efficiently implement the project at the right pace. In general, there were very few specialists of the required level on the market, because good specialists usually do not look for work. And hiring insufficiently qualified people is costly, because you have to distract other members of the team to help them, which can generally reduce the speed of work.

The fourth conclusion - an academic approach to architecture is not always useful. Excessive number of links in the architectural chain only adds problems in the development and support of the solution.

It is important to understand that no system can be fixed in time. If the system does not develop, it dies. Our Internet bank continues to live and develop, so we have new technical compromises between the speed of implementation of functionality and convenience of further maintenance, we gradually pick up the pace and pay attention to advanced development technologies. In one of the following articles we will explain what and how we have changed in terms of technologies and approaches as our Internet bank is developing.

Source: https://habr.com/ru/post/340510/

More articles:


All Articles