By Jeremy Brown, Regional Head of Middleware, Red Hat
Banks in the Middle East are not only performing strongly in regional markets, they are now looking to expanding overseas and growth their footprints across the globe. According to Deloitte’s latest report , ‘rising world trade flows, increased gross domestic product (GDP), a growing middle class and new technologies are expected to help banks based in emerging markets expand into developed markets in the coming year’. The growing ambitions of the region’s banking sector are driving up demand for effective IT. However, most (if not all) banks and financial institutions these days have cost reduction programmes in place.
Enabling rapid growth and agility with creaking IT systems poses a major challenge to financial services companies in the Middle East where the IT infrastructure, like in many other industries, has evolved over time and features a wide variety of solutions. More often than not, IT architectures are a complex mix of different proprietary systems, different databases and file systems, and standard and tailor-made applications. Business processes and rules are often hidden inside the software with changes being complex and tightly coupled across multiple applications, which have to be carefully coordinated and released which slows down the business’ ability to respond rapidly to changing market conditions.
In the automotive world, a Volkswagen and a Skoda can be built using the same chassis; sometimes the two car types are built in the same factory. But the German gets to charge a premium since its reputation for elegant design and enviable engineering outstrips that of its Czech-born sibling. CIOs at banks have started to realize a lot of what they manage is not the secret sauce that enables them to charge a premium and the bank’s IT chassis can be standardised. While a fiercely guarded trading algorithm can provide competitive advantage infrastructure management is not core to the business.
Banks have historically spent vast amounts of money on proprietary software or writing and maintaining their own but now there are credible open source alternatives to the proprietary software and the standardised open source solutions offer considerable cost benefits and the ability to tap into rapidly innovating open source communities.
In addition to the cost benefits that can be realized by embracing open source, financial institutions are also able to enjoy greater levels of software innovation. For example, in areas such as cloud computing and big data, innovation is being driven by open source – in these areas of innovation it is no longer about whether to choose between a proprietary or an open source vendor, it is more about which of the open source vendors you choose.
A dual vendor approach
Deciding to embrace open source is one thing, but implementing the migration is far easier said than done. Often banks are unwilling to lose the proprietary solutions entirely but will hedge their bets and choose a second OS vendor and develop a dual vendor strategy. Taking Java EE containers as an example: Java EE is a standard which banks are used to spending a lot of money on using – for example, Oracle Weblogic or IBM Webshere. Increasingly, banks are unwilling to deploy on proprietary systems because the costs keep rising, so why not use an open source JBoss JEE container and save a lot of money?
We’re seeing that this dual vendor strategy is not just in financial services but in a wide variety of verticals. Businesses are migrating hundreds and sometimes thousands of applications because they can realize significant cost savings and get exactly the same functionality, often they even get better performance by migrating.
One argument proprietary vendors often give for customers to choose their products is that they are more fully featured than the open source alternatives but this is often disputed by the open source vendors. Anecdotal evidence from those that have made the switch is that they might have lost one or two features that they never used or found other more elegant and modern ways to achieve the same effect.
In addition to migrating applications, if the hardware platform is out of date, banks can enjoy incredible returns on investment by updating the hardware to commodity x86 at the same time as switching the software stack on top. Traditionally, banks that have selected high-end, big budget Unix platforms, find themselves spending a lot on maintenance on ageing hardware that is actually slower. So, if they purchase new x86 commodity based hardware and migrate to a Linux operating system with an open source software stack on top, the ROI can be less than a year. This means they could invest in a migration immediately, because they will save more than their initial investment within the year.
In-Memory Data Grids
Memory is another area where we’re seeing open source make in-roads. Financial institutions are using in-memory data grids in order to accelerate the way their applications work. Rather than storing data on a discs or in a database that can be a bit slow, or even on solid-state drive (SSD ) which is fast but not as fast as in-memory. Memory is now so cheap that you can store huge amounts of information in-memory and data grids take care of making sure that data is never lost even though the data is maintained in memory through various clever strategies.
There are a couple particular proprietary vendors who lead the market for in-memory data, however, they are eye-wateringly expensive. Increasingly, we’re seeing banks run a dual in-memory data vendor approach, they maintain a proprietary presence, but they are also starting to offer an alternative for users based on open source. So, we’re seeing a trend whereby all new deployments are going to be on the open source solution, simply because it provides a significant cost saving as business continue to grow and new applications take advantage of modern software architectures.
Cloud and OpenStack
Financial institutions are reluctant to move towards public cloud for regulatory reasons as much as anything else. They have built their own internal clouds on their own hand cranked proprietary kit. Most of the cost of software is not in the upfront development but in the long term maintenance, which is why open source makes sense when you talk about cloud.
If a bank is building its next generation internal cloud and writes it in-house, it will have to constantly have its own dedicated engineers working on it and it will be the sole contributor. Whereas if the bank uses an open source product, where there is a large community and a lot of people committed to it, they will be able to take advantage of all the innovation that others in the community are contributing. In Infrastructure as a Service (IaaS), all the major IT players such as IBM, HP, Rackspace, VMWare and Red Hat are centering on OpenStack, so if a vendor says it will support OpenStack, it means the service will have long term support. This is exactly the kind of assurance that financial services companies are looking for.
So for their next generation internal IaaS banks are using open source, but they are going to a vendor for that long term maintenance. They influence the roadmap for the open source community and the vendor drives changes on behalf of those customers in those communities. This is transformational; previously if a bank needed features they would have to write in those features and support it for the next ten years. Now, for a fraction of that development and maintenance cost, they can get something that has a huge community of users.
A final development we’re seeing is in staff resourcing. Large financial institutions struggle to hire talent in a very competitive market. If you’re a talented coder would you rather work for an exciting start-up or take a staff job at a bank?
Developers nowadays no longer only use CVs, they use a Github account (which is sort of like a Facebook for programmers) and everyone can see the code that they have written. To get the best developers organisations need to allow them to contribute to open source projects.
Banks are in a battle with start-ups from a hiring perspective. They need to attract the best talent and they need to say ‘yes, we allow you to contribute to open source projects as part of your day job’.
The realisation among progressive banking CIOs ties into the standardised chassis approach to infrastructure management. It isn’t core to the business, so banks are happy to share knowledge and projects within the open source community. The upside to this sharing is, people within the open source community get to see that working for a bank can be every bit as stimulating as working for a start-up.
Standards help avoid lock-in
The key thing when choosing software is not only open source or proprietary but also open standards. Take Microsoft Office; Word has become the world’s de facto word processing application, but it is far from an open standard. Microsoft wants to keep it that way, naturally, since that’s where the bulk of its on-going revenues originate. However, perfectly acceptable alternatives are freely available. But moving to say Google docs is a bold move when everyone else is still using Office. Java EE has done for containers what, so far, no one has quite managed with office apps.
Once there is a standard, open source becomes really powerful because it helps avoid the lock-in that exists with a particular vendor. With standards in place proprietary vendor solutions become commoditised and purchasing decisions come down to cost and functionality.
If all the vendors subscribe to that standard then you can move between vendors. Open source comes in at that point and you can move from proprietary to open source. Banks, increasingly, are very much aligned to that way of thinking throughout their IT environments.
Open source offers a number of advantages, but that is not to say IT directors at financial services companies have suddenly developed a gung-ho attitude towards its adoption; they don’t want to download something off the internet and put it into production. They are still risk averse and conservative in nature, furthermore they have a wide variety of compliance regulations which they must meet. If they want to embrace open source, that means working with a vendor who can provide support and enterprise-class open source software for the long lifetimes of their applications.
About the Author
Jeremy Brown is the regional head of Middleware for Red Hat and has over 10 years of experience as an IT professional. He has a diverse understanding of Enterprise Architecture, Open Source, Java, Middleware and Cloud technologies. He develops new product strategies for the Red Hat JBoss Middleware business by working closely with customers to determine the solutions that meet their unique needs. He works with product engineering, professional services, and product support teams to ensure a world-class customer experience from proof-of-concept and pilot implementations all the way through to enterprise class deployments of the Red Hat JBoss Middleware portfolio.