Jim's Journal

Over the past 30 years selling technology solutions, the raw materials of the products I sell have changed many times. Shifts from centralized to decentralized processing and data models, optimization for the hardware we were operating on, business trends swinging from corporate consolidation to startup disruption. These are all contributing factors to the way we build our products. The latest shift is to microservices and API’s in the cloud. I’m going to primarily talk about Microservices in the business context – I’m not a developer but rather one who helps companies, primarily banks, adopt new technology. Let me first define Microservices: Sam Newman, back in 2015, defined Microservices as “Small Autonomous or independently releasable services that work together, modeled around a business domain.”

Since joining NCR last May, I have been working primarily with top 100 banks, selling payment solutions within that market. Most of the solutions that bank’s run today were developed across my 30 years in the industry – and I sold a lot of them; giving me a unique perspective vs some of my fellow salespeople and solution consultants. I understand that those of you who have lived in the programmer community have been building and deploying microservices since 2014 and that the widespread adoption took place back in 2015 particularly in the web-commerce worlds of Google and Amazon. For banking, however, its just getting here. To take that a step further – banks just don’t think of applications as “business domains” working as distinct services working across channels or departments. Every bank has silos of employees, departments, products, customer segments, etc. Shifting the mindset of the leadership of these banks – especially operations is probably going to be the biggest challenge going forward.

To me, the current move to microservices is a natural progression from the object oriented programming shift that happened while I was in school. While I was trudging through COBOL and BASIC, the kids back home were already learning SmallTalk and C++ in their basements. As I spent all day writing a novel on the terminal, the world was dividing and collaborating with libraries on these novel devices called a PC. The shift continued and C++ ruled the roost until everything changed as the internet and bandwidth became cheap. Back in 2015 Github’s list of the most popular programming languages showed the rapid rise of Java, and the decline of archaic tools like Pearl and C. Even Python use was dropping. Then The Cloud, AI and DevOps took over and today we are all looking to build powerful applications that operating in a software defined infrastructure to save money and meet customer demand. Here’s the thing, in 2018 Python is growing, JavaScript is on top and people are building with powerful tools like Go, TypeScript, Kotlin, Rust and Angular and but Java and C++ is hanging in there even as Ruby and PHP decline. Why – everything legacy is written in C, Java, and COBOL and they have to be dealt with. And you know what – you can containerize almost anything now can’t you?

A natural progression as companies like banks with traditional operating groups try and become more agile is to start exploring as they look to move from single monolithic applications to distributed systems. From departments to collaborative groups of employees developing products and services that can be reused in different ways. Five years ago it was all about SOA (Service Oriented Architecture) and the same challenges existed; but with the technology barriers associated with the fact that most of these were still based on monolithic three tier architecture. Today we have shifted to Microservices and I would say that its not that different, but without the technological platform barriers – with the exception of the biggest shift, getting banks to adopt cloud-based architecture. In fact in a talk Sam Newman gave back in 2015 he specifically stated that he felt that microservices were nothing more or nothing less than an “opinionated form of SOA.” The key is autonomy as well as the investment in options and re-usability that SOA always promised. With microservices, you get to make a lot more choices – and that is hard. It is even harder when you are brining in the need to adopt a complete computing shift to cloud based architecture – one that creates anxiety simply because its primarily associated with the internet – ooooh the scary internet.

My young friends are baffled that banks still run COBOL programs; not because they are ignorant of history but more because they don’t understand the business challenges in making the change. My older friends are struggling with the benefits of agile development and DevOps; not because they aren’t excited about it but they have the wisdom of “everything in its right place” behind them (sometimes to a fault). I find it all fascinating and my mind wanders to thinking what it would have been like 25 years ago to try and implement an agile development environment within an organization submerged in waterfall product management and monolithic programs operating on centralized mainframes. Or to see how these young turks would lose their minds having to build efficient programs with limited memory and processing power, right down to the kernel. Wait – that’s exactly what is happening now – the clash is palatable in almost every organization today. I sound like an old man, I know – and in some ways I am. But I’ve managed to keep up and am optimistic about where we can now go as the industry moves to a microservices architecture.

So where am I going with all of this? My job every day is to try and help people appreciate the opportunity to embrace change – because change is growth and without growth we begin to die. Cynical people will say – I’m just out to make a buck convincing banks to buy software but that’s just a small part of it, I truly feel responsible to help my colleagues who sell, product managers who define, managers who lead and customers who buy. And for me helping means educating and often convincing that they need to consider and then adopt a new way of thinking. Microservices are the manifestation of the decentralization of today’s economy – the shift from monolithic vertically integrated assembly lines into horizontal, distinct decentralized components and today people develop code the same way, a really interesting and amazing way. I relearn new technology every few years – I move between companies and talk to different people to do that – because I have no choice. Some customers come with, others walk away.

So now we get to the how – do we scrap and rewrite these legacy systems completely. Disruption happens all the time; and in banking this disruption is primarily happening in Fintech with entirely new financial institutions starting that resemble banks but come in the form of an App. These Fintechs are often called Challenger Banks (Monzo, Simple, Starling, Bank Mobile, Chime, Varo, etc.). Or do we refactor them – taking legacy applications from traditional three tier architecture or even SOA to microservices, containerized applications. For some companies refactoring can happen gradually – because they are SOA already, written in Java and can therefore transfer to a cloud based architecture by focusing on the database and operating system. But the reality is that won’t be as easy as it seems. Back to the choices that Microservices affords you – how do you decide on the specific business domains that you will refactor the application to address in the form of distinct microservices. This is hard work, difficult collaboration between engineering and product management – often two areas that are purposefully separate in traditional technology companies. The sad thing is, time flies and in a few years you will see most of the people in a large company simply ignore the opportunity and stick to their guns, expecting it all to pass. Until it doesn’t, and the senior leadership team spins off your division and buys another company. Or stops funding your group and suddenly another group gets the money. Or worse, the SLT doesn’t do this and the company slowly dies.

So this is an introductory post – I expect that I’ll be writing a lot about it as much as I can because a few of us are just now beginning to start the process of educating my colleagues and customers about the benefits of this technology and where we are finally at a really effective and expansive approach to OOP, SOA and now Microservices. And my next post about ESBs is also a launching point to how companies buy and implement enterprise applications. TCO, security, scale-ability and flexible deployment will drive the business value to the Cloud.