Re: Utter drivel
As a long time reader of TheReg, and being a bit of a BOFH, I never had the urge to reply to an article. But I was pleasantly surprised to see that "my Bank Tech Boss" actually got interviewed by TheReg. When reading the article I was a bit surprised by the actual quotes, which miss a bit of context. In my role as Chief Architect Infrastructure for ING I have an overview what happens in the datacenters and also what is happening in the application space.
First of all my "Bank Tech Boss" is a bit of a nerd. Within ING we like nerds, content driven skilled engineers. And believe it or not, Ron can write his own Java code and if we ever get to it he would be willing and able to learn to write a piece of cobol to run on the mainframe. But that's not the point. The reference to the mainframe in a real time environment needs some context. Traditionally banks, and also ING, have invested heavily in a variety of tools, technologies and platforms. The mainframe has been around for a very long time. Our mainframe environment is heavily optimized and we get great performance out of the platform. But it is all application and business logic which has it's foundation in a batch driven environment. Traditionally the whole payments area was based on batch processes. This was fine for the customer 10 years ago, and even great for banks to have nightly settlements. But those millions lines of code are all based on the principle of batch processing. Actually amazingly optimized to run those every growing volumes. In this day and age a lot of customers expect realtime updates, immediate processing and are refreshing their payment statements more often than their Facebook feed. And in all fairness the code from 10 years ago is structurally not able to be adopted to be fully realtime. The mainframe platform by itself obviously could support such processes, but actually it would require to rewrite an awful lot of code to accomplish that.
When we started the journey to become a true realtime bank, it was also a great opportunity to move to a more common hardware platform. Ofcourse Linux could run on a mainframe, and it would perform and it would scale. But with this challenge to rethink our application architecture we also had a great opportunity to not just adopt a common platform, but also introduce many other new technologies (for example in the NoSQL space).
That does not mean that we completely ignore the mainframe, it is still supporting a lot of (business) processes. Hence we also introduced the CD/CI approach for the mainframe teams. So in this batch orientated environment we also have deployment pipelines, integration frameworks and are getting benefits for those DevOps teams. Because the end-to-end process must fit in that some operation model; it's not just fancy cool updates in the mobile apps. It is also adopting our backend systems with new features and capabilities.
The quote in the article could have been "we want to be a realtime bank and we did rethink all of our internal processing and external interfaces. This resulted in a lot of changes on my platforms. This could be done on any hardware platform or many different hardware platforms, but we choose to standardize on commodity hardware.
Although not represented in the article, the PHB actually knows all of this but probably just not expressed in the interview.
And now I am back to my PDP11, for the fun of it ;-)
Biting the hand that feeds IT
