The bank has dubbed it the 'post-SOA architecture'.

When Greg Steel first investigated what the architecture for Xinja was going to look like just over four years ago, a few options were considered.

One of those, according to Steel, now CIO of the Australian neobank, was to purchase an off-the-shelf bank-in-a-box solution, such as Temenos or Celeriti, that could have easily offered them everything they needed: core banking platform, customer management platform, integration layers, channel layers, and the opportunity to customize those layers.

But as Steel puts it, it would have been "quite a conservative approach and it would have limited what we could have done".

"We would've built a great new credit union just like existing banks, but we couldn't have differentiated and done our own things and added in our testability at each layer of that stack," he told ZDNet.

At the same time, Xinja wanted to avoid going down the path of building an enterprise service bus (ESB) service-orientated architecture (SOA), mainly because it came with "approaches of really having a centralized type platform and centralized skillsets to be able to do those integrations that were the bottlenecks for everything"; it was also a typical approach for most financial services organizations.

What they opted for in the end was an event sourcing-based microservices architecture made up of a mix of best-of-breed banking platforms -- including an SAP digital banking platform for its core banking platform -- and building their own integration layers without an ESB.

"We needed to give ourselves the flexibility and freedom so we can innovate at every layer of our technology stack," Steel said.

"We're architects, we believe in the principles that came out of that service-orientated architecture, so it's kind of what we call a post-SOA architecture where you're dividing your banking landscape across the different technical capabilities cleanly.

"Rather than buy an out-of-the-box platform and all those integration capabilities, and hooking into all sorts of legacy platforms and integration platforms, we decided to choose modern banking platforms, mostly born in the cloud platforms, all integrated with great web services.

"Therefore, we could build our own microservices architecture to do that integration, which meant more handcrafting of code than you would do with an ESB where you might use patterns, frameworks, or templates."

The right call

Steel conceded that while it was not the cheapest option nor was it the easiest at times, the pay-off has been much higher.

"Building software is difficult to do but we found that it did mean that we were able to achieve outcomes in integrating new capabilities so much more quickly than we've ever experienced," he said.

He pointed to Xinja's integration of Apply Pay as one example of where the decision to build its integration stack with microservices was the right call.

"Most banks that have done Apple Pay in the last five years take about a year to do it. It is a very big and very complex project. You have a number of different suppliers involved, a number of integration points, and Apple is also really anal with you about how things are going to be done," Steel said.  

"We were under great time pressure to get funding and we couldn't go out to potential funding sources and say, 'We're a neobank but we can't do Apple Pay or Google Pay'. So, we put ourselves under great pressure, but we delivered from our first conversation with Apple to customers in five weeks.

"The biggest reason we were able to do that was because we built this microservices integration architecture. If we had not, and were dependent on suppliers to do the integration, and had to get suppliers working with each other to jump through their hoops, it would've taken us months and months."

Despite Xinja's own successes, Steel believes it will take time for others in the financial sector to warm up to building an integration stack with microservices.

"There's skepticism about building software. Everyone has been burnt on software build. We have been burnt. Software development is always a bit of a bottomless pit. I think it will always be the case and there's always going to be a move towards pattern-based, code generation-based, software development delivery," he said.

Steel added that unlike others, Xinja's advantage is that it has been built in the cloud and is not weighed down by legacy infrastructure.

"The cloud is hard for existing financial services … taking existing legacy platforms and bringing them into the cloud is a lot harder," he said.

"You wouldn't try to build this architecture outside of the cloud…it's not something you can go 50-50. You really must embrace those patterns and embrace them properly. If you try and do a hybrid thing, such as a customer mastering over here and Kafka for securing and messaging, you're not really embracing the pattern and it's not really going to work."

But whether the existing model is sustainable to maintain in the long run, Steel is optimistic that emerging tools and platforms will help ensure it is.

"Microservices is quite fine grain. You've got many smaller components, each of which is relatively simple in their own right…when you've got a lot of fine-grain microservices, that can become a nightmare where you start needing registries and keeping track of who's talking to what, what the dependencies are -- that's always a problem, that's the flip side of having something highly monolithic," he said.

"If you are going to have something that's fine grain distributed, there's great tools evolving to deal with that. We do an awful lot of automated testing which keeps us in check and makes maintenance and managing finer grain components a lot easier.

"The other thing is when you've written code to do something like integrate with some third-party systems … it probably takes you longer to get it working in the first place, but what you have at the end of the day is java code, so you've actually removed a few potential layers of complexity and loss of knowledge and understanding. Instead, you've got code that's quite well understood."