IT Brief Australia - Technology news for CIOs & IT decision-makers
Story image
How digitisation will disrupt traditional banking practices
Thu, 1st Nov 2018
FYI, this story is more than a year old

In the age of digitisation, the banking and finance landscape has changed forever. Modernisation has brought sweeping operational change to the sector, with customers closer to their chosen service provider than ever before. Apps and online services are very much the go-to touchpoints for busy individuals, and banks must adapt to this change or be left behind.

The proposed Open Banking legislation coming to Australia will further disrupt traditional banking practices, with Consumer Data Right (CDR) giving open API access to what has, until now, been very much proprietary data ‘owned' by individual banks.

Along with the new demands for improved user experience, the power balance in the financial sector is shifting, and fundamental changes in attitude and practice are required. Consider the monumental impact that Google made on the world by opening its mapping API, and service providers such as Uber based their business on the newly accessible data.

Entire markets were affected, companies went under, and others had to adapt and improve in order to stay afloat. Look at 13-Cabs as an example. The company now has an app, also based on Google's open-API mapping data, which offers a very similar user experience to Uber, and microservices within that app such as requests for the driver to call the consumer, ratings for the driver, payment options, and selection of vehicle types.

There are many ways that an industry can adapt to change, however, and banking and finance companies, loaded with strong customer data sets and in the position to attract skilled and experienced staff, are well equipped to deal with this evolution.

Anecdotally, the financial sector in Australia is quicker to adopt new technology than in many other parts of the world.

As a company, NGINX talks to companies in many regions about their adoption of web-based technology and services, and the company has noticed that Australia has a distinct tendency to push the boundaries when it comes to adopting new tech. Banking and finance firms in the US tend to spend a lot of time – even years – evaluating new technology before putting it into production.

Australian companies are likely to evaluate it more quickly, decide that it is beneficial to their service offering, and deploy – getting new products to market much faster than other regions.

This may be a cultural thing, or possibly reflects the smaller, more agile nature of Australia's finance sector. Regardless of the motivation, it is evident that Australian companies are at the forefront of adopting microservices, which form an integral part of a company's digital future, and widely recognise the need for faster, more reliable and flexible web services.

This is causing cultural change within the sector, with a marked shift away from the standard practice of rolling DevOps into networking and broader IT services. Quicker response time from development teams means a faster go-to-market product and allows the organisation to respond quickly to customer demand and market forces.

New touch-points such as mobile banking apps, social media, and broader financial services require a high degree of customer interaction, backed by analytics and streamlined networking. Microservices adoption is already high in Australia, and growing as more and more companies realise that in order to interact better and more frequently with their customers, they need to have a more agile and scalable application.

Supporting the abundance of new features and services that consumers now expect calls for a significant amount of investment in backend products and solutions. In many cases, financial services companies find themselves caught between legacy hardware and lightweight cloud services. As the range of services provided by these companies continues to grow, scaling of hardware architecture proves to be limiting, providing neither the flexibility nor scope for additional services.

Adding new customer-facing web services requires a simplified, fast, and low-risk approach. At the network level, this has traditionally meant adding extra hardware in the form of application delivery controllers (ADCs).

These have been around for nearly two decades and fulfilled a very important role in the load balancing and delivery of applications. However, as so many functions of a modern IT environment move towards software-defined infrastructure and support tools, older hardware-based solutions are proving to be costly and less flexible.

Services take longer to add, speed can be compromised, and there is an element of risk involved each time a device needs to be added to the network, or an existing device reconfigured. All of these factors can have a downstream effect on user satisfaction.

Moving from legacy hardware to a full software environment for load balancing will allow financial services companies to respond to an ultra-competitive and consumer-driven market here in ANZ, offering faster services at a fraction of the cost and time.

Leaders in the DevOps field are starting to coin the phrase “bringing infrastructure closer to the app” – that is, rather than relying on the wider networking team to make changes to load balancing, which slows down time-to-market, moving to a virtual load-balancing model moves control closer to DevOps team members who are able to provide fast, efficient changes for a more flexible model. Adding microservices directly through the software saves time and money, and again, brings those services to consumers faster.

Further to this, hardware load-balancers are not well equipped to cope with the use of containers, so a software solution is required to facilitate the flow of east-west (container-to-container) traffic. In cases where it is not feasible to end-of-life existing hardware, deploying a cloud-based software solution for application delivery can enhance the existing hardware in a company's architecture.

This often makes hardware work more efficiently and allows DevOps staff to add and enhance services more effectively, while hardware ADCs perform a more standard network routing role.

Replacing a hardware ADC with a software-defined solution can save as much as 75% in Year One alone. There is a rule of thumb in networking circles: for every five hardware ADCs a company deploys, it needs to employ one staff member.

 As discussed, while in many cases a company will still require hardware for routing traffic, the number can be reduced from say, ten ADCs to two, if used in conjunction with a software solution. Staffing budgets can, therefore, be deployed on more high-level tasks or used to focus more time on direct contact with the organisation's most important asset – its customer base.   Above all, moving to a software-defined solution reduces risk. Suppose a company had ten hardware load balancers, each deploying 1000 apps. Making changes to that device comes with a fair degree of risk, from human error through to device and configuration failure. If the hardware fails, services will be suspended and customer trust will be compromised.

Moving to software load balancers reduces that risk, as a DevOps team can build, test, and deploy microservices within the software, thus making thoroughly sure that they will work before going to market. Again, this moves control closer to the developers.