“It broadens your view once you know that there are others dealing with similar problems and possible solutions” says Marc Schumacher, Senior Software Engineer at Zalando Payments, after attending JAX Finance 2016. In this article he shares his insights and lessons learned from the conference. Thank you Marc, see you soon in London!

There are only a few developer conferences focusing on payment topics, and JAX Finance is one of them.

The conference was held from 27-29 April at the Park Plaza Victoria in the center of London. As a member of the Zaster team (Zaster is German slang for “money”), responsible for developing payment processing components at Zalando, my mission was to get in contact with other developers, companies, and speakers dealing with payment related topics. As finance itself is a quite rare field concerning development, the conference was a mix of both finance and DevOps topics.

Presentations and learnings

Eric Horesnyi from streamdata.io was the first keynote speaker of the conference, stating that what had previously happened with Netflix & Co. is now happening in Fintech.

According to Horesnyi, the most important aspects to consider for being successful are:

Be pragmatic and fast
Collect user feedback and iterate
Have lean approaches
Go for cloud
Use DevOps
Be transparent and share

He continued talking about why the creation of an API is so important. It is used to monetize, accelerate roadmaps, disrupt through transparency, and interconnect in real time.

Following the keynote, a panel discussion was held between Stefan Weiß from Fidor, Pierce Crosby from StockTwits, Joost van de Wijgerd from Bux, and Simon Redfern from Tesobe. They touched on the importance of culture and noted that communication was a key aspect in the sector. Getting closer to customers and connecting to them was thought of as vital.

The main statements shared by the panel were that startups get cherry-picked and reintegrated by bigger companies. They focus on solving problems for the customer, mainly those that are frontend related. The technical platform for this is simple APIs.

Development-wise, lean teams are important. We were urged to use these teams to create APIs, especially for startups, making it easy to get in touch with banks. Create a transparent environment and open up the infrastructure to be accessible for implementers and customers, as required of PSD/2.

Neat! For me, as a developer from the payment department, seeing a sophisticated API for bank transfers using SEPA was quite interesting.

Following the panel, I attended an interesting talk about a German banking company called Fidor held by Stefan Weiß. He talked about what is possible when you open up your banking interfaces using APIs which account owners and developers can use. Compared to traditional banks, which might have a web interface for the customer, this bank allows users to do all they could do in the traditional web interface setup by using an API.

Seeing that it is possible to transfer money using a small curl call on the command line, you also could use the API to create web interfaces or backend services such as automating tasks, writing GUIs, etc. What is also possible for developers is the ability to integrate their software into the banking web interface as a third party extension. Neat! For me, as a developer from the payment department, seeing a sophisticated API for bank transfers using SEPA was quite interesting.

Going a step further, a project called the Open Bank Project aims to give you a platform to set up your own bank. As a lot of banks still use really old software in the backend, so this might be a starting point to update their software.

Simon Redfern, the founder of the project, talked about all the modern technologies they use in the project: Scala, RESTful APIs, OAuth, flexible connectors, making use of freely customizable metadata, Kafka, plus a huge amount of SDKs for Python, Scala, Java, and others. The project already has notable supporters like RBS, ING, Rabobank, and Ulster Bank showing that traditional banks have noticed the need to modernize.

“Security is not a product, but a process”. It can be so hard to have a high level of security in your products: You need to make security part of your daily work, not just a project that has a start and an end. Security is an ongoing process.

An important factor to consider when talking about payment processing is security. Due in part to the requirements of the credit card industry (PCI) and legal regulations, this has been, and still is, an important topic for the payment team I am working in. With this in mind, I attended a presentation from Eoin Woods about Secure System Fundamentals. He stressed the fact that security is hard to achieve, as its focus is not always as big as it should be.

Eoin quoted Bruce Schneier: “Security is not a product, but a process”. It can be so hard to have a high level of security in your products: You need to make security part of your daily work, not just a project that has a start and an end. Security is an ongoing process.

To move to a highly secured system, it is important that the whole development is risk driven. The design of software needs to have security built in, as it is hard to attach security processes to an existing piece of software. Besides this, people and process are just as critical: What is the point of having a highly secured system while people write passwords on Post-It’s?

JAX Finance also featured presentations about DevOps, with the first talk I attended about Java SE 8 best practices. As our team adopted Java 8 specifically a few months ago, I was able to find out more about issues, learnings, and best practices. Stephen Colebourne gave the talk, on top of having a blog that is quite well known in the Java community.

The bottom line about Java 8 is that it improves readability if used properly. With Java 8 already being more than two years old, a lot of developers do not feel comfortable in using the additional functionality you get. Perhaps Stephen’s conclusion will encourage others to try it out.

Continuous Delivery

Continuous delivery and integration was another hot topic of the conference, as it is one of the important approaches required to achieve a short time to market. Stefanos Zachariadis is Team Lead at LMAX Exchange in London, which co-invented continuous delivery. In his talk about continuous delivery in a regulated environment, he stated that many people think deploying to a regulated environment is risky due to the high cost of failure, and should therefore be done as rarely as possible.

The opposite is actually the case: You will always make mistakes and have bugs in your code. Therefore, it makes more sense to deploy frequently to be able to identify bugs fast. As Stefanos said: “Eat your own dogfood and eat it early and often”.

By implementing continuous delivery, you reduce the effort of deployments, the pain and impact of failed deployments, as well as the time it takes to deploy in the first place. In a regulated environment you obviously won’t be able to access production directly, so it makes sense to have a staging environment which is quite close to the setup of production: The topology should match production.

The idea is to set up a fully automated deployment pipeline for staging that is almost identical for production, with some slight differences in configuration. An often forgotten point is to have (sanitized) production data in the staging environment, in order to have a proper testing environment. Having only a very limited dataset of test entries in your staging environment will not help when testing. This is done not only for performance, but also to have a multitude of different records on the system which help find bugs.

For example, when introducing a new validation or calculation. Having this data on your staging machine enables you to see problems early, rather than when it is too late. Move sanitized live data continuously to staging to be up to date. Moving data rarely, or only after a long period of time, does not help in a continuously changing environment. When doing so, the updating of sanitation scripts might have to be adjusted on release where necessary.

Continuous integration is always a challenge. Quite interestingly Eduards Sizovs, in his entertaining talk about eight things that make continuous delivery go nuts, pointed out that the real reasons might come from a different source. Trying to implement continuous integration often reveals problems you always had in the way you were developing and deploying, such as having a lot of manual steps to complete during deployment.

Purely technical problems are only one part of the story. We must also consider the human component in the process of introducing CI: Get people and different departments on board, get them aligned, compromise, and if everything else fails, try what Eduards called “beer driven diplomacy”. Involve people who will use CI instead of just confronting them with a fully evolved solution that they cannot contribute to.

You can find all the keynotes plus some interviews from the conference here.

Conclusion

There were a lot of valuable talks which helped me get an insight into the rest of the FinTech community. It broadens your view once you know that there are others dealing with similar problems and possible solutions.

Besides finance topics, the DevOps part of the conference was really helpful! Getting more insights about what problems other teams have, as well as and their learnings, guides us in not making the same mistake. The focus on continuous delivery topics underlines its importance and shows that Zalando are on the right path with the way we work.

I really enjoyed JAX Finance in London and establishing better connections to the Fintech community. If you have any questions about my learnings, you can get in touch via Twitter @jackeroo_marc.

This blog is a republished post from the Zalando Payments SE & Co. KG Blog.