In today’s episode of the “I Am A Mainframer” podcast, Steven Dickens sits down with Derek Britton, Director of Communications and Brand Strategy at Micro Focus. On this podcast, they discuss their journey with the mainframe, advice for those just starting their journey with the Mainframe, and where they see the Mainframe going in the future.
Steven Dickens: Hello and welcome. My name is Steven Dickens, and you’ve joined the I’m A Mainframer Podcast brought to you by the Linux Foundation’s Open Mainframe Project, a collaborative-focused project focusing on how we make the Mainframe an open platform for the modern enterprise. And today we’re joined by a dear friend of mine so we’re going to have a fantastic show. We’re joined by Derek Britton from Micro Focus. Welcome to the show, Derek.
Derek Britton: Great to be here Steven, thanks for having me on.
Steven Dickens: I’m looking forward to this one. Two Brits, a Bristolian and a guy from Birmingham, this should be interesting for those people from around the world to listen to the accent. So just to get our listeners orientated, obviously I’ve known for a long time, but let’s just position you to the listeners here. Tell us a little bit about your role, what you do, and we’ll use that as a jumping off point.
Derek Britton: Okay, let’s do that. It should be an easier answer than it is actually because I’ve had a fairly colorful career mainly at Micro Focus, the software company who among many other things sell a bunch of mainframe tools. So my connection with the mainframe goes back to goodness me in 1989, when I first was sat down and plugged in as an intern at Micro Focus. The first thing I connected to of course, was our mainframe system running an email app called Profs, I think it was something like that anyway. And it’s gone on from there and we’ll probably dip back into some of what Micro Focus does later on, but I’m currently helping out on the marketing side at Micro Focus.
So you’ll see me at places like SHARE, at the GSE conferences, and I’m a member of the Open Mainframe Project COBOL Working Group. Which I think if you were to characterize my career in one word Steven, well at least a technical word, one that I’m prepared to repeat would be COBOL. Because my career has been in and around the mainframe world, but actually looking after one of the mainframes best buddies, the COBOL computer language. So I think to a certain extent everything I’ve done has been never more than a few paces away from the COBOL technology, the COBOL programming language.
Steven Dickens: I think that’s going to become a question now, if you were to sum up your experience in one word what would it be? So Mr. COBOL? Okay, that makes sense.
Derek Britton: Well, and I’m happy with Mr. COBOL and you can go with Lord if you’d like, I don’t mind.
Steven Dickens: Lord COBOL, okay.
Derek Britton: Tom Ross is Captain COBOL, Tom Ross at IBM is Captain COBOL and I think Sudharsana at IBM I think she’s Queen of COBOL now. I think we’re going around giving each other titles and I think that’s good for them so if there’s any spare ones, Duke I don’t know.
Steven Dickens: I was going to say Duke, the Duke of COBOL has got a better ring to it I think. I mean, there’s a lot in what you said there, Micro Focus we’ll talk about that in a bit more detail. There’s the Open Mainframe Project obviously, we’re on the Open Mainframe Project podcast so I want to understand that in a bit more detail, but maybe let’s start with that COBOL journey. So you mentioned that you came onto Profs, you logged on to the mainframe as your first exposure to the technology. So to give us a bit of a story arc, where you’ve seen the platform and COBOL go over that time. That’s probably a great place to start.
Derek Britton: Yeah, and I think it would be. It goes right to the heart of actual value, but also one of the ongoing challenges that a language of that age and that level of usage will still struggle with regardless of its success. Which is simply that those who dreamt up the idea of COBOL, they’ve long since gone on to do other things. 1959 the idea was devised, and just for your listeners’ sake that predates me as well. So I joined the party relatively late in the 1980s. It had already been going some time already by that stage.
Very, very well established enterprise-scale and a robust language of choice for business, that’s what the B stands for. And so COBOL’s own story which I was fortunate enough to be involved in writing a white paper in celebration of its 60th anniversary a couple of years ago. We delve into its enduring value and depending on who you ask, there are a number of reasons why COBOL has stood the test of time, but even back in 1989 I said I was connecting to a mainframe to use the apps there, COBOL was still highly regarded, but mainly regarded as a mainframe language.
And that remains true today, it was true then, it remains just as true today, and most of the largest world’s consumers of COBOL language are all mainframe shops. But actually part of COBOL’s design meant it had to be portable, so COBOL was also available even back in the ’80s on what was then to become AIX on something that was then being devised, something called OS/2 you may remember and something that was later to be called Linux and many other open platforms.
Its portability, which wasn’t important for the mainframe community per se at the time, became more and more important as more people were looking at what are the other options were available to them in terms of where did the applications need to run? How did their business model work? And Micro Focus came into helping do just that, but what was really, really critical is that we maintained it, because remember COBOL was built as part of a committee process. And it was an open standard and managed by the International Standards Body.
Which meant that anything COBOL was doing on the mainframe, in order for it to retain its portability we needed to ensure it could do the same thing elsewhere. And actually that process of collaboration, and I’m going back as far as the days of AD/Cycle. Micro Focus and IBM had to be in cahoots on not only the COBOL standard, the COBOL language and some of the new capabilities that we were considering at the time, including things that were later to become pretty standard issues like object orientation.
But not just COBOL itself, but also the connectivity into other key subsystems that ran on the mainframe at the time, such as CICS, such as JCL, such as IMS. So my journey with COBOL came through an important point of its evolution, which was to retain its dominance on the mainframe world, but also then to be available in these other nodes on the network, if you like, that were starting to get more and more connected back to the mainframe mothership. And to a greater extent I think we’ve seen over the last couple of decades that continued evolution towards what’s now termed a hybrid model.
And any of these nodes on the network might not even be in your network anymore, they might be in someone else’s network and we call that the cloud. That level of interconnectedness and hybrid IT if you like, is de facto in many of the largest organizations that are served by both of our organizations. So either that’s the way COBOL has evolved because it had to, and that’s the journey that I’ve been on. So I know I spend quite a lot of time talking to organizations who primarily use mainframes, but also have a bunch of other stuff. And it’s really the challenge, or the opportunity is how to get the best out of their technology investments to deliver business value.
Steven Dickens: I mean, when you look at that history arc that you’re probably as good as anybody in the industry are talking about, I think there’s been a lot of negative talked about COBOL and it hit the press, and I know the Open Mainframe Project lead the charge reframing that, but I think the way you talk about it it’s really interesting for me. I don’t get into whether this one language is better than another language debate, really I don’t understand it and I know you’ve got an opinion and that’s where I’m going with this, but why is one language considered cooler, better, more vogue of the time than any other language?
They serve a purpose, they serve a developer community. Maybe, and this is a long rambling question Derek, but I’d be keen to understand your perspective there because we hear a lot of, “Oh, we should do this in Java,” or “Oh, we should do this in Python,” or “Oh, we should do this Ruby on Rails.” And there’s something in that that I’d want to maybe spend a couple of minutes on, so maybe give me your perspective.
Derek Britton: Yeah, okay. And it is interesting, you do have to be very careful in well in every industry, but certainly technology is no stranger to this, that you don’t take a personal preference and then try to wrap that up as some pseudo logic in terms of here’s my decision system, here is a belief that is always going to be true. And you have to be very careful even about COBOL, there are going to be some situations where it’s probably not the right choice, and I would imagine that that’s going to be true for no matter what technology you might be a big fan of.
So even in the Micro Focus labs COBOL as a development language has a level of appropriateness that we’re very comfortable defining where it’s useful. And of course, we have a wide range of use cases where we believe that’s true, but we’re equally clear that if you want to design an exciting new user interface, I wouldn’t start with COBOL. I would connect to COBOL, to do the data handling and the number crunching that actually provides the service, but the way it’s presented to the user, yeah, you’d probably be using something else.
And so it is a, what us Brits would say, “horses for courses” approach – you use the right tool for the right task at the right time, and you make those decisions based on the resources you have available. So do you have the people with the skills? Do you have the technology that is connected to the right other pieces of technology? Is it working on the right platforms? Does it provide the right throughput and robustness and reliability? And of course, COBOL ticks many, many of those boxes, so it’s a fair candidate for many, many what I would call systems of record, business systems, the grown up stuff that if they fail it matters. COBOL isn’t used to build Angry Birds, but it does run pretty much half the banking system if not more.
Steven Dickens: I like that one Derek, it’s not the language for Angry Birds, but it is for the banking system. I think that nets it down perfectly. I mean, I think so much of what we hear of the rhetoric, and I know there was a lot of focus on this 18 months ago as we went into the pandemic, I think it comes from the situation you describe of “Oh I like this, therefore it’s the answer for everything. And anybody who doesn’t like this, whatever that this is from a language point of view, has not got the right opinion.”
And I like the pragmatism that you’ve got, and I use this analogy around just because I own a car doesn’t mean I think planes or trains are bad. That level of pragmatism, certainly in the mainframe space, doesn’t exist. It’s like the public cloud and Python is the only answer, and if you don’t like public cloud and Python then you’re not thinking about the situation in the right way. Those dogmas exist I think, and I think it’s really interesting to hear your perspective of it’s horses for courses.
Derek Britton: Yeah. No, I think you just have to be careful, the person who ultimately presides over the decision and the strategy should ultimately be someone who has the business’s best interest at heart, that understands the business strategy and how best to get there. And so even though these technical decisions they will have obviously, you’ll need some smart technical people in the room to help make those decisions, it is still a business decision. And you still ultimately have to say, “Why is this the right thing for a business purpose?” If you can’t answer that question very, very quickly and very readily about your technology choice, there’s a good chance you need to look at it again.
Steven Dickens: Yeah, that’s a good way of thinking about it. So I led us to how the industry thought about COBOL 18 months ago. I know you and I are close to that and that thought process, maybe just unpack that for the listeners who maybe aren’t as close to the rhetoric that existed in the marketplace, and what the Open Mainframe Project has done to respond.
Derek Britton: Okay. Well, I’m just going to go a tiny bit further back than that and just go to 2019 and just talk about the anniversary of COBOL because I don’t think many people could, certainly not in 1959 when they designed the stuff, not many people could have sensibly projected a Diamond Jubilee party albeit a virtual one, but that we threw on behalf of COBOL’s 60th birthday. And that was 2019, September 2019 to coincide with… And I know it was a gentleman from IBM who dreamt up the name COBOL, so we got that pinned in September 1959 according to the records.
So we wrote a lot of commentary, we being Micro Focus, but I know the rest of the COBOL community, if you like, shared with that and a lot of outpouring of very positive vibes about COBOL. About it stood the test of time, and here’s why, there’s really good attributes for the language, its readability, its portability, its robustness and quite a lot of commentary around that. And then to most people’s surprise, it fizzled out a little bit the next news item was some ill conceived, senior leader, some state government or another who can remain nameless for the purposes of this call and any legal case thrown against me, who miss-represented COBOL as being to blame for some challenge processing.
I think it was unemployment benefit payments or whatever it was and it doesn’t matter, but it was in the public domain. And within moments of them saying, “Well, yes, we need more COBOL programmers that you can’t find anywhere and we think COBOL was playing because we can’t process things quickly enough.” It turns out that not a lot of that was particularly true, but the cat was out of the bag, the point had been made. And then a few rather simplistic journals later, a few articles later on, COBOL has now got a bad reputation in the marketplace for being out of date, moribund, dusty, with a skills crisis.
And I remember speaking to you and I spoke to Reg Harbeck as well, and I spoke to a couple of people in the mainframe world and I was lucky enough to get an audience with John Mertic as well who was already talking to Micro Focus about the Open Mainframe Project. And it sealed the deal and I thought. “We’ve got to do something here,” and John said. “Look, there’s an open forum here, and the whole point is this is where the mainframe community comes together to talk about and solve key issues of the day.”
And we felt that this was a key issue of the day, so I was lucky enough to team up with a couple of very energetic people in the cohort and we formed this thing called the COBOL Working Group. And simply to put the record straight Steven, nothing more than that initially, to fundamentally restate the story about COBOL and say, “Well this is why it survived, but thrives. These are the people who still use it, these are the organizations that still use it.” And very sensibly we said what we need to do is measure how much there still is, so that we can actually point at it to everyone else and say, “Look there’s COBOL, that’s what it’s doing for you.”
And so that’s what the germination of that group was all about, and set up just over a year ago and I’m very pleased to say that we’ve already embarked on the quantification exercise so we’ve got the results of the survey that we’ve done just back in recently. And it’s as we thought, COBOL is alive and kicking, it’s not barely surviving, it’s thriving. So there’s a lot of positives to say, and our job is to act as effectively the lobby group on behalf of the mainframe community, but the COBOL community at large, which is sizable.
By another measurement by the way and just go off topic slightly, there’s a COBOL programmers group on Facebook, of all places would you believe. And you’d think, “Well, it doesn’t sound like the right place for your average COBOL programmer to go.” But what’s interesting is A, it’s quite busy, it’s over 20,000 membership and B, the demographic breakdown of that COBOL group is mainly 20 to 30s. Rather than well, what you might typically expect shall we say, which is a slightly older generation. It’s not true, so there’s people coming into the COBOL world either looking for their first job or in their first job, are looking to skill up and to understand the wider community. So it’s pretty exciting stuff.
Steven Dickens: You mentioned the point in time and the response. Where do you see that COBOL Working Group going forward? There was the, “We need to mobilize, we need to address the perception gap that existed from some of those comments.” And I remember back to some of the conversations and the team mobilizing, which for me natural competitors finding a way to collaborate on a topic is the genesis of opensource.
Derek Britton: Yes.
Steven Dickens: I know you take an active role in the leadership of that Working Group, so where do you see that going forward? You had a reason to mobilize, but what’s next?
Derek Britton: Okay, coming together as like-minded individuals is the danger always if you talk to each other about things that you all agree on. You’re all nodding frantically and everyone goes away, and no net good has come of it because no one else found out the power of the conversation. So the job as much as it is anything else, it’s one of communication. You and I can have a cozy chat about this, but as this podcast testifies it’s no good that you and I understand this, it’s making sure that everyone else who may be in a decision making situation about COBOL gets to understand the truth ahead of that decision.
Now, for many people already in the COBOL community we’re preaching to the choir, they already understand it, they already get it, they’re already likely to make an informed decision. But whether it’s a technical decision, a technical choice, a technical strategy, CTO type, architecture type question mark, whether it’s a business investment decision, there are some stakeholders that we need to reach in the wider community that are not really part of the COBOL community per se. They need to understand the story as well, so there’s a very long, multi-multifaceted, multi-tentacled communications requirement here for us to be truly successful.
Because of course, each decision to do away with COBOL is a decision we should have to go in front of, and of course some of those things that are happening every day. So the initial and immediate task is a body of evidence that we can use to share with the wider community. And that’s what this survey was going to be, it was going to be the rallying cry if you like to say, “Look, here it all is, here’s some solid evidence that points at the value of COBOL and some of the challenges.” We did ask about skills, we did ask about how headcount is sourced, we did ask about some of the challenges that they may face.
But nonetheless, the survey results will be very, very important, and we hope to go back out to the press later on this year with those results, and it’d be a pleasure to come back on the podcast and talk about what we’ve found. So that’s the first thing. I think the second thing is to realize that as much as we can have these individual conversations one to one, stakeholder by stakeholder, or even through the press, as much as I’d love to think so only a certain number are going to listen to this podcast, only a certain number of people will read TechChannel, only a certain number of people will read any other particular IT publication. What we need to do is probably raise it up a bit further.
One of the interesting things that’s come about and these details are a little bit sketchy because it’s only just started happening. In the U.S. Congress there are legislators looking at potential acts of Parliament or whatever they’re called over there that talk about the necessity to protect and continue to invest in so-called legacy systems because of the endemic inherent risks that a lack of investment has caused over the last couple of decades. They’re trying to protect not just the government institutions, but I think it is primarily focused on those, from the lack of funding that has caused risks to these IT systems which is part of the reason why they are easily tarnished with a bad reputation.
“Oh, look at this dusty and broken old system.” It’s not dusty and broken and old, it’s just under invested, it’s just been left a little bit to die on the vine because of the lack of ongoing investment. You need to feed and water these systems on an ongoing basis in order to maintain them and to keep them current and that’s what that legislative discussion… It’s basically a discussion topic at the moment, I don’t think it’s been proposed yet, but we’re trying to galvanize input from a variety of sources to help with that. And that raises the bar I think, and that raises everyone’s awareness.
I think COBOL then becomes more of a mainstream conversation all over again, and I think the more mainstream it is the more people realize how profoundly foundational to the economy that technology is. Very much like a mainframe Steven, once people understand the profound importance of that technology on the economy at large, they’ll realize that actually we can’t just ignore it and pretend it’s not there, we can’t just make derogatory comments about it. You’ve got to invest sensibly, and you’ve got to consider the future. I’m very excited about that potential, but we’ll be doing plenty more.
It’s getting around, it’s doing the show tour and getting around to the right community meetings. So going to GSE, going to SHARE, going to… I think hopefully we’ll get on Z Council as well, we went to the ECC Marist Conference earlier this year. So it’s just telling the story, engaging in the community, and getting everyone comfortable and confident to tell the story themselves so that they can act as our cheerleaders as well.
Steven Dickens: So there’s a couple of things in what you’ve just mentioned, I’m going to start first with just trying to position. Obviously the COBOL community needed to come together, tell me a little bit about what role the OMP, the Open Mainframe Project played in allowing you to get together. Because I think you and I know how that happened, but I think that’d be interesting for the listeners, and then I’m going to come on to the COBOL story and give you a chance to talk about Micro Focus afterwards. But just first off, tell me how the OMP enabled you and the wider COBOL community to come together because I think that’s going to be interesting for listeners who maybe don’t know how the sausage was made.
Derek Britton: And you know what? It was a moment of, and it was one of those wow moments where you realize the potential that we have at our disposal that was only possible because of what the OMP was able to do. And they didn’t sprinkle magic dust in the situation, what they did though is there’s a place you can go where you leave your role at the door, you bring your passion in the room. And then literally you are talking like a support group to say, “Hi, I’m Derek I love COBOL.” And you go around the table and you will introduce yourself, and then you talk about what matters to you and why you want to get something out of it.
Now, what you have to remember is, and it was a good mix actually in all fairness, but what it did include, the room included organizations who would ordinarily never sit in the same room, barely stand in the same building because we compete on things, we sell rival technologies. And once the honest broker, which is what John was able to do, John Mertic was able to do, he said, “This is the way this is going to work.” He also very sensibly said, “Look, let’s not just have vendors, let’s have practitioners, let’s have consultants, let’s have trainers.”
We have Dr. Cameron, Seay from North Carolina, and a number of other people who are, shall we say, enthusiastic, hobbyists or practitioners who happen to work somewhere, but that’s not why they’re there. They’re all in the room, and everyone got an equal vote, and it was then just a case of all right between us. What do we think we need to do about COBOL? Pretty much it brought widespread agreement, and that could only have happened if there was a safe place to go to have that conversation. Where you could leave your day job at the door, and that’s what we were able to achieve.
And you know what? On the back of that decision my employer Micro Focus said. “This OMP thing is much more powerful than we’ve really considered before.” And that was to a great extent one of the key points where we decided to join up as a paid up member. So I think that was the special moment where we realized the potential, but all that does is get people in a room, what then happened was quite magical that we all saw eye to eye on it. I think you were in the first couple Steven, you’ll remember just how powerful the meetings were and then it was just then a case of right well, we’re just going to come together and figure out the right way to get this done. And we’ve accomplished quite a lot in a very short space of time.
Steven Dickens: And I think it’s really interesting that first bristly, well, I normally sell my stuff against your stuff. I don’t like you as a person because my salary is… It’s that classic zero sum game, I win, you lose, we win the deal, you lose the deal mentality as you say gets left at the door, and it’s like, “Well, in order for either of us to be successful, we need COBOL to be successful.” And I know John’s a master at orchestrating those initial difficult conversations, so I mean, I think that’s really interesting.
The second piece you talked about, and I’m going to give you the opportunity to get into Micro Focus here in a little bit more detail, is those interactions with some of those clients, and where COBOL is going when you’re talking to clients. So maybe just this is the opportunity to position Micro Focus a little and what you guys do, maybe just unpack that a little for me and for the listeners.
Derek Britton: Okay. Well, I’ll look at it from a COBOL-centric perspective, and that’s not the full story of Micro Focus. We do a whole ton of other stuff, we are a security and an operations and analysis company and all those other business units that are fantastic in their own right. But from a COBOL perspective, well, what’s interesting is when you talk to the client base, and you know this as well as I do Steven, when you talk to organizations about what their future aspirations are, especially in the last couple of years where the world has turned pretty much upside down.
And what your customers now want are completely different to what they wanted two years ago, and what your supply chain looks like has changed beyond comprehension. All of those things have a huge impact on the IT that underpins the business that you’re trying to support both today and aspiration. Well, that’s equally true for the stuff that’s at the heart of those IT systems, which obviously for our clients it’s COBOL applications, no matter where they happen to be right, but typically mainframe based.
What has happened and what Micro Focus has spent a lot of time worrying about, and I know we’re not alone, is the fact that unlike what was the case in 1969 and 1979 even when COBOL was probably at its heyday, because it had a near monopoly hold on the business marketplace. These applications are not islands anymore, the platforms they run on are not islands anymore, and I think it was as far back as four or five years ago. I think Peter Rutten in IDC referred to the mainframe ecosystem as the connected mainframe.
And a successful mainframe ecosystem is only going to be successful if it is connected, and in fact even at Micro Focus we sell a bunch of mainframe security software, and our tagline for it is protected and connected, because both of those things have to work for your mainframe ecosystem to remain viable.
Steven Dickens: We like the phrase open mainframe on this podcast. You can say connected, we say open.
Derek Britton: I’d rather like that, I’d like that too.
Steven Dickens: I mean, I was the one who was fortunate enough to come up with the name so I’m going to show my bias, but I mean, I think they both speak to the same point and it’s really interesting the way you described it, and the words you use there of the platform’s not an island. Whether it’s open, whether it’s connected, whether it’s hybrid, whatever the marketing people get to, using the taglines, I think that’s the key point. If you’re writing a COBOL program, I know I’m speaking to the developers who have listened to the show here, you’re not writing it to sit on a mainframe and only be interacted by on a mainframe anymore.
It’s going to be part of a journey, the system of engagement could be sitting on AWS, it could be a mobile phone, that connectivity layer to get in, it could be a mobile banking app, it’s going to be multitier. Yes, the system of record may be on the mainframe, but I think as the COBOL development community we’ve got to think of that broader lens. And I know a lot of them don’t, they look at their IDE screen and they’re doing what they’re doing, but we’ve got to think on that broadest lens.
Derek Britton: Oh, I think we do. I think we do and what’s good, and what’s encouraging, and what’s really exciting actually when you see the stuff for yourself is everything you’ve just described as being potentially necessary is a use case. That’s out of the box today, that happens on a regular basis, and I know many people at the IBM labs who’ve built many really smart pieces of kit to enable a much more agile and much more connected method of delivering COBOL systems no matter where they need to be, no matter what they need to do.
Honestly, COBOL is part of your most contemporary toolchain using whatever other contemporary tools, potentially open-source tools, of course, that’s all happening right now plug and play, no problem. Can you disentangle monolithic COBOL applications to deliver them as discrete microservices? You bet you can, of course, you can. Straight out of the box? No problem at all. Now, is it a problem to identify the right microservices to deliver it in the right way? Of course, microservices isn’t Child’s Play, you still have to think about it, but the technology is able to help you disentangle things that haven’t been touched for years.
So all of that is already available and already possible, I think that the trick is to get some of that art of the possible in the hands of those who might otherwise not realize it, and to give them that as a potential option for the future. My biggest fear is that the wider COBOL programmer community out there in government and industry are not being given the opportunity to bid to use COBOL in these new ways to solve the challenges of today. And that there’s default acceptance that in order to do something new, you have to use a new piece of technology.
And that’s just patently not true because as I’ve said in other podcasts and in other articles, COBOL it’s a 1959 idea, but it’s a 2021 technology. So when someone says, “We might need some new technology for that.” We say, “Great, well, why don’t you use COBOL?” Because that’s exactly what it is. And of course, the same is true for the mainframe itself.
Steven Dickens: Yeah, I like the way you phrase that. I mean, I’ve long used this analogy, I’m a car guy, and people naturally understand cars as an analogy and it’s if you’re in the U.S. audience, the Corvette, if you’re in a European or global organization context, people understand the Porsche 911.
Derek Britton: Right.
Steven Dickens: Both of those cars were launched at the same time, the same year as the mainframe. We were out driving yesterday and I saw the new Corvette, not one thought went through my whole mind of, “Oh that’s an old car.” But it was a mid ’60s idea that’s been reimagined, and it’s mid engine now, not front engine, this thing looks like a Ferrari or a Lamborghini. It looks as modern as a car could look, but it’s a mid ’60s idea.
Derek Britton: Yes.
Steven Dickens: Nobody looks at the brand new Porsche 911 and goes, “Oh, that’s a vintage car.” So I think that you’re certainly thinking about it in the right way, you’re looking at that car to go, “That’s a way to have a fantastic journey,” and that puts a big smile on my face, and I enjoy the experience of driving a sports car. You’re not thinking, “Oh, that’s a 1960s sports car.” So it’s that same mindset.
Derek Britton: It absolutely is, you’re absolutely right.
Steven Dickens: I mean, I could talk to you about this topic for hours as you know and we do on a regular basis, but maybe we need to think about how we start to bring this home for the listeners here. One of the questions I always ask is that you talked about it when we were doing the introduction, you’ve been a mainframer since the late ’80s. We get a lot of younger listeners and we talked about it, some of the things you mentioned from the Facebook demographics, there’s a lot of new users coming to this platform, and particularly to COBOL from the development community. As one of those luminaries in the COBOL space, the Duke of COBOL as you’re now going to be known-
Derek Britton: Thank you Steven.
Steven Dickens: What advice would you give to your younger self? So you can go back and speak to Derek Britton age 21, 22 coming out of college with the benefit of hindsight here. What would you say to your younger self?
Derek Britton: I mean, it’s actually probably the hardest question you’ve posed to me today, but I think there’s probably a couple of things and it’s just dawned on me based on the conversation we’ve had, and so ask me again tomorrow and I’ll come up with three other things. But I think if you were to say what didn’t I know back then that I know now that really matters to my career and my place in the world if you like, I think the most important one is context. Even a graduate will take a job because that’s the job that they think they want, but their end game was getting the job. Their end game wasn’t why the job was good for them in their career path.
And in fact, I mean, I don’t know how many people I’ve spoken to who don’t use their college degree at all in their professional life, the goal of the college degree was because they thought they had to go to college and that was pretty much the end of it. And then they found a job and that was a different objective. So it’s setting the context for who you are in the world as early as you possibly can, and if that sounds rather patronizing, well maybe it is, but I think today’s organization is a lot more transparent about who it is and why it exists, and what purpose it serves the world around it.
In a way that certainly when I started my career there was no corporate culture to speak of in quite the same way. And I think the internet society, the digital era, we’re a lot more switched on about our place in the world and why things matter, and perhaps even why some things shouldn’t matter. I think your average 21 year old might not spend that much time thinking about that, however, I think understanding your context and why your career is going to matter in the future, I think is a great place to start.
And the second and third things are actually just purely tactics Steven, there’s no way you’re ever going to get on in your career if you singularly focus on just yourself. You’re only ever going to achieve great things with a team of great people around you, and so the ultimate ingredient for success is teamwork. And the second tactic, a bedfellow of this is just your own work ethic. If you’re not working at least as hard as the other members of the team, you have to ask yourself why am I on this team?
Steven Dickens: The interesting thing and I’ll pick on the second thing you mentioned, I agree with both the first and third things, particularly the hard work piece. But in the context of this being an open source podcast, I think the teamwork concept is don’t think of that teamwork just within the confines of your organization.
Derek Britton: Absolutely.
Steven Dickens: If you look at our relationship specifically, we’ve made a point of working with each other before we needed to work with each other across those lines, then when the COBOL Working Group came together we had that existing relationship. So you and I by dumb accident and by being two of the Brits at chair, whatever there was the confluence of events that got us there, I think the key thing is thinking of that network and that teamwork. The team isn’t Team Micro Focus, for us it was team mainframe and we were just going to work together, we’re going to find a way to work together as a team before the need to work together as a team came about.
Derek Britton: Yeah, well give forward if you possibly can because it might turn up useful. And also there’s an enjoyment thing there as well, just gravitate to the people you like to spend some time with. And I suppose I have to confess that I like spending time with you Steven, that’s why I have to pay to get on the podcast.
Steven Dickens: That’s a revelation that I don’t think we need to expand on. I mean, the final question I tend to ask is, and I’m really interested in your answer on this topic. Where do you see the mainframe platform three to five years out? I think getting your perspective particularly on that is going to be really interesting for our listeners.
Derek Britton: I mean, it’s a constant fascination to me just there and there are so many technology futurists, self-appointed-
Steven Dickens: Me included now that we’ve even got the word future in mind, a company with future research so I’m guilty of being a self-proclaimed futurist, but yeah, I get your point.
Derek Britton: It is one of the toughest gigs, I mean, there’s not a lot that many people foresaw about the last couple of years and we can all agree with that, but I mean, I read a lot of these reports and I don’t disagree with many of them when they say that it’s the classic conundrum the IT world faces. You add a lot into the top, a lot of water comes into the lake but not a lot of water flows out of it. By which I mean a lot of new technology gets introduced into the top of the funnel, and not a lot of it retires. A lot of it carries on, not necessarily widely used, but it carries on regardless.
We’re not very good at getting rid of things because actually if it adds value it stays because it’s technology and it automates processes, so it’s never necessarily a bad thing. And as a result of that, as a natural byproduct of greater levels of complexity on an ongoing basis, more languages, more technology options, more platforms, more means of delivery, a burgeoning open source communities while having even greater opportunities. Then there are the requirements for all of those new dots in the picture that need to be joined up.
So I don’t want to plagiarize Peter Rutten’s words, but that word connected I keep coming back to. That interconnectedness of things in today’s digital era, it’s almost impossible to conceive a future world where things are more neatly ordered, less complex, and therefore the necessity to simplify and improve the connection. And obviously, the secure connection of all of those various elements is going to remain absolutely foundational to anyone’s success. And as that pertains to things like COBOL, well, it’s going to need to carry on playing nicely with whatever evolves, whether it’s the containers world in terms of delivery model, whether it’s connecting with new languages, whether it’s supporting new front ends, whether it’s plugging into new open source options, and all of these things are going to have to happen.
And it’s going to go faster than any standards body can keep up with, and so the market is really shaping the evolution of that language, it is also shaping the evolution of the platforms on which those languages sit as well. We know that IBM is going to spend continued sums of money on ensuring that the mainframe continues to innovate, we’re absolutely sure that the cloud vendors are going to carry on doing the same for their own platforms. Those worlds will continue to collide, and they’ll continue to require mashups and connections that they’re either working today and need to be better, or we haven’t yet conceived other ways where they’ll also have to work together.
It’s not going to get any easier for any of these organizations to figure all of this out, but actually, in some of that complexity arrives a heck of a lot of new opportunities as well. So it just becomes another exciting five years to look forward to. The other thing is I’m quite looking forward to in just over five years’ time, we could start planning COBOL’s 70th-anniversary party. And I know we’ve got Reg Harbeck to commit to lay the drinks on, so you just have to bring cake.
Steven Dickens: Fantastic. So I’ve asked that question with multiple guests on the show over the years now, I think that’s probably one of the best off-the-cuff answers I’ve got. So I’ve got nothing else to add to that apart from to thank you for your time on the show and start to wrap up. So Derek, fantastic time on the show really appreciate it. You’ve been listening to the I’m A Mainframer Podcast, brought to you by the Linux Foundation’s Open Mainframe Project. If you like the conversation you’ve heard today, please click and subscribe and give us five stars in your various podcast platforms, that helps. We’ll put up some details to Micro Focus and where to find Derek in the show notes, but thanks again and join us next time for the Open Mainframe Projects I’m A Mainframer podcast. Thanks very much.
