The Many Meanings of Modernization, With IBM’s Amy Anderson
Modernization is a continuous process that goes beyond code re-writes, IBM's Amy Anderson tells Charlie Guarino on TechTalk SMB
Click here to listen to the audio-only version
The following transcript has been edited for clarity.
Charlie Guarino: Hi everybody, this is Charlie Guarino. Welcome to another edition of TechTalk SMB. As you can see, I’m very happy to be sitting with a good friend and somebody who has been in the IBM world for quite some time, Amy Anderson. Amy, so good to see you again. Thank you for joining the podcast today.
Anderson: It’s so good to see you and I’m so happy to be here.
Guarino: That’s great. Thank you very, very much. Amy, I know with IBM, you are the modernization lead for IBMI. What does that actually mean? What does somebody who was a modernization lead, I mean that’s kind of vague. What does that mean?
Anderson: Well, it’s intentionally vague because modernization means a lot of different things to a lot of different people and it’s a dynamic exercise in taking care of systems and applications. So we go to wherever we need to go in order to keep the business moving forward and also to make sure that we’re leveraging the appropriate technologies for the appropriate purposes. So on the IBMI, that can mean anything from leveraging Python and SQL services to improve a business process. It can mean rewriting something from scratch or it could mean just cleaning up some RPG code so that a young developer can read it and understand it and work with it.
Guarino: That’s an interesting, interesting point I should say because if I even looked at your LinkedIn profile, right under your name, the tagline says, I’m applying best practices to future proof, and that’s a term I hear all the time, future proof, IBM’s own systems. And that’s the part that really piqued my interest, IBM’s own systems and applications. So I want to break that down into a couple of questions. First of all, future proof. What does that mean? Because I think like the term modernization, I can ask 10 different people and get 10 different responses. What does future proof mean?
Anderson: Yes. So I’ve been in IBMI since 1997 and I’ve been doing modernization work, again, what does that mean, for 10 years going on 11 years. And so for me, future proof means that we have an eye toward making sure that these applications can be taken care of, that the systems can be managed efficiently going forward. But the other part of future proof for me is really about understanding that the modernization work is never done. We may this year convert some old CL scripts into Python. Yay, great. But five years from now, Python may be the old stodgy thing and there’s something newer and cooler out there. And we have to understand, and especially we have to make sure that our senior leadership understands that modernization is not a one-time exercise. It’s something that we build into our designs. It’s something that we assume we’re going to keep moving forward and we’re going to keep adapting.
Guarino: So is it a fair point then to say, for example, in the mid 1980s, even 1990s, we had to go through a Y2K exercise?
Anderson: Yes.
Guarino: And that in effect was future proofing, but that was years ago. So certainly that code, if we future proofed it 25 years ago, it’s certainly not ready for prime time today, I think if, nothing was done to it
Anderson: Well we future proofed it in that we changed a two-digit year code to a four-digit year code. So it’s future proofed for what, another 8,000 years.
Guarino: It’s not too early to start working for that, by the way.
Anderson: I hope to be retired by then. But what else is in that application that needs attention now? And also I know of at least one customer that they didn’t future proof in year 2000 because they said there’s no way we’re still going to be running this application in 2020, and they called IBM in 2020. So you have to make some safe assumptions and you have to make some business decisions based on the best information that you have. But there’s always more work to do.
Guarino: The other part of your tagline, and here is the key part, IBM’s own systems and applications. And that’s the part that I know that you do that. But for those who may not know what that means, people don’t normally associate IBM or think of IBM as a company that needs modernization, for example, with their applications.
Anderson: So true.
Guarino: So talk about that. IBM’s own systems, I mean surely they’re running, they’re a substantial company, they have some issues modernizing as well.
Anderson: Yeah, IBM is like any other large corporation that built applications over the years. It so happens that IBM’s manufacturing business and a big chunk of global financing is all running on IBM i. And in fact, more than half of IBM’s revenue flows through our IBM i systems. We have about 20 applications, anything from export controls, payroll, finance, just a hodgepodge of things, but they’re running on this platform and keeping IBM’s business flowing. So when I say we are taking care of the systems for IBM, it is very much we’re keeping the trains running. I always say we got to keep the trains running here—we don’t do trains. But it is a key part of the business. And to your point about, well, wouldn’t IBM always be doing the most cutting edge thing? Well, we’re like any other corporation, priorities change, things shift and all of a sudden you look and go, wait, this is a little out of date. As an example, my team spent the last year—we had a tool set that was originally developed for our platform around the time that the AS 400 came out, so call it 35, maybe some more years. And it was a hodgepodge of tools for systems administrators, anything from security health checks, something we call housekeeping where you just make sure you’re keeping your LPARs parse neat and tidy, getting rid of spool files, all of that sort of thing. Monitoring event management, user profile management, which is huge.
So this just collection of tools, and for a variety of reasons, we needed to get off of this tool set. We no longer maintain control of the source code. And so we needed to get off of this tool set and it was very much a modernization exercise. Some things we re-wrote, some things we bought a third party product for. We leveraged new technologies, for example, with the security health checks. We run security health checks every quarter. And the original tooling for that, which was written decades ago, was some kind of an RPG program that would go through. And it was also, by the way, referencing an out of date security specification. Alright, we fixed that pretty easily. But it’s just running against some spec and spitting out some really ugly output that said things like, you should go look at this.
Well, if you’ve got a new developer, if you’ve got a new administrator—we call them systems reliability engineers or SREs—you get a new SREA message that says, you should go look at this. Now what do I do? So these security checks were taking weeks to get done every quarter. It was a huge problem for our resources. So we went through and rewrote that using, guess what, SQL services. So we could easily replace lines and lines of RPG with SQL services, simple statements, and then provide additional automation through Ansible. So something that would take weeks can now take days and have a much better experience for the SRE, much better usability. And we were required to go do that exercise, but it was certainly worth our while.
Guarino: What’s coming to my mind while you’re describing this, I could easily remove the company named IBM from this discussion and plug in any large company and the conversation Would be nearly identical if not completely identical.
Anderson: Right. In the case of the health check, it’s easy to deprioritize that because sitting there going, “Hey, it’s not broke, it’s working. Let’s just keep using it. We’ve got these other more important things to do.” And all of a sudden 20 years goes by and you’re way out of date now. And you kind of go, how did that happen? Well, business priorities.
Guarino: And IBM is no different in any regard. Everybody, as big as they might be, limited resources, no matter how big any company is.
Anderson: Right.
Guarino: And resources, not just financial, it’s time resources and skill resources and things like that it all falls into. So let’s delve a little bit deeper into this then. So with all these different applications that have been modernized or are still on the plan to be modernized, how do you make the decision? What’s the number one reason why you need to modernize something or what’s the first set of questions that you ask somebody or metrics to decide, why are we doing this? How do you speak to that?
Anderson: That is the question. You have to start with, why do we need to do this at all? And I have given an example many times in the past. A few years ago, I was at a customer in Florida and they were telling that they got a new CIO and the CIO came down the hallway of the IT department and said, “If I see one more green screen, I’m going to put a bullet through it.” You don’t like the green screen. I get it. It feels old fashioned. You feel like, oh, we should be newer and hipper and cooler than that. But the real question is what is the point? Why are we doing this? Just because we want to look cooler or are we doing this because we can hire new people who may not have any affinity with that green screen, and we need people who can be productive with a GUI.
And supposedly sometimes if you have people who get real good at that green screen, they’re much faster if they’re not clicking on dropdowns. So you have to really do the analysis work. And a thing I have seen a lot as I’ve worked with large clients is they feel like I’ve done that analysis work a million times: “I have paid consultants to come in here and tell me what to do, and I just want to do the work. Can we just dig in and start doing the work?” And I am sorry, but you have to know why, and you have to know what you expect to get out of this. And if it’s just everybody else is doing Java, so I think I should do Java, that’s not a good answer. Nine times out of 10, it really gets down to a skills issue, but we can talk about that.
Guarino: I’m just wondering, when you say you challenge people and you ask them, why are we doing this? I think my immediate retort is, just like the modernization question, if I ask 10 different people, I’ll get 10 different definitions. So wouldn’t I get 10 different “why I need to do this,” or maybe worse, “why I shouldn’t be doing this”?
Anderson: Yeah. I think there’s always the, “I want to do this because it feels like the right thing to do,” but in the case of this tool set that I was explaining that we got rid of last year, we had a legal mandate to get out from under that tool set.
Guarino: Yeah, it’s non-negotiable.
Anderson: It’s non-negotiable. And so that’s a very compelling motive. In other cases, you may have situations where, and I know of situations like this where there is one person left who knows this RPG code, and if anything happens to that person, we’re in trouble. And I have seen that at some of the very largest companies. And so that’s a good motivator, where you say Charlie’s going to retire in three years or less, so how are we going to manage that? How are we going to take care of that issue? And that’s where you really get into then, well, what are the options?
And that to me is a skills issue. So how do you want to manage that skills issue? Do you want to replace the code base so that you can—it’s easier to find Java developers than it is RPG developers. Or, do you want to find a way to train newer developers in how to take care of these RPG systems? Can you figure out a way to incorporate more Python and PHP and newer languages so that there’s less interaction with the RPG and you’ve got developers who can work in code bases that they’re more familiar with.
Guarino: So beyond a whole rip and replace, which I’ve seen done several times, there must be some metrics that you follow. You’re talking about maybe going with the different languages perhaps. But in the end is a more normal path, and maybe normal is not the right word, but a more predictable path, perhaps, in the end you have something that’s more of a hybrid, so you’d have some of the old code remaining with some of the new technologies. Or is rip and replace really a completely viable option in many cases.
Anderson: I maybe shouldn’t be the person to answer this question because typically they don’t call us, IBM, until a rip and replace has failed. So often it’s, we’re going to SAP, I don’t mean to throw them under the bus, but we’re going to go to SAP and three years later and untold millions of dollars, they go, let’s go back to RPG. And so like I say, I am not on the successful side of rip and replace usually. So take this all with a grain of salt. But I think hybrid approaches are pretty effective. And for example, we had one customer in the financial services that they replaced just the payments part of their monolithic banking system. They replaced just payments with an off-the-shelf cloud solution. And the part that we helped them with was to figure out what were all of the integrations with payments from all the other components in this application. So you start by what are all those components? Then finding all of the programs that are touching this little piece, find the, identify the data model and start to really figure out how do I just surgically extract this thing and make sure that I didn’t break anything else and they did it successfully.
Guarino: You’re talking about modernizing IBM’s own systems, but there must be some concerns from people, leadership or whomever, a concern about the cost, for example, of modernization. How do you address some of those concerns? When we talk about, these are large scale projects, and with the cost that goes with that, how do you square that to say, this is the value, the cost we’re putting into it will return. There’s a significant ROI on this.
Anderson: Well, I think one of the things that I emphasize quite often, and I learned this phrase from a senior sales leader at IBM, he said, “Are you just moving the mess?” You’ve got this thing, you’re not happy with it for whatever reason, and you’re going to put it into a different code base. You’re going to migrate it over to the cloud. You’re going to name your technology. If all you’re doing is moving the mess, you’re still having the same level of functionality. What have you really achieved? And so what I learned from him is you really have to not just say, we’re going to do this project and it’s going to take three to five years and this many millions of dollars, but in the end, we’re going to have this capability that we didn’t have before. We’re going to have this level of maintainability that higher
Guarino: Higher value.
Anderson: Higher value. And the current focus of that higher value is of course AI.
Guarino: Sure.
Anderson: How do we leverage AI in a way that creates higher value for these applications and maybe do some modernization along the way? I know you’ve been all over this, Charlie, so.
Guarino: A couple of war stories I can probably share with you, but that’s another conversation. But surely you’re not working in a vacuum, you’re working in a situation, you have an ongoing concern. The company’s reliant on the applications. Things are getting through, millions and billions of dollars getting pushed me out. So to do a modernization could be somewhat disruptive or the environment itself can be disruptive. We talked about covid earlier. How do you manage the stability of the application while still bringing in these new features at the same time?
Anderson: Yeah, and I think Covid was a great example of that because it was so disruptive, especially to retail and distribution businesses, which we support thousands of them, because they saw their volumes go up, number of packages shipped per week, number of online orders, all of those things. And the secret sauce here, one of the reasons that our customers are on this platform is because it’s so reliable. And these older programming languages are so screaming fast. So you may not like that green screen, but I’ll tell you what, you can double the volume of online orders and we’re not even going to have a hiccup. So you really have to understand that the modernization task does not end in many ways. I resist when people kind of say, well, we’re going to go do this modernization thing and we’re going to do these business things. I’m like, no, it has to be of a piece. It has to be all of one thought. And so you really have to break down that modernization task and focus on the little bits going back to that payment system that was just one small part of this huge banking application, but they were able to kind of isolate at a granular enough level that they could start to pull these things apart while keeping the business running.
Guarino: Yeah, there’s an unfortunate situation here that needs to be broadcast. There’s a bigger message here, and you hit on it, and it was like you mentioned with Covid and the number of packages quadrupled, for example, going out—that message should be screamed from the rooftops. It really should be, because I know, for example, I know some companies when Black Friday first became a big thing and the very first time they had this big thing, it was all hands on deck. Everybody was working on the day of the Thanksgiving, Black Friday, and it was just another day of the office. The machine just, maybe it was a fractional increase in the machine being used, but the volume was there. It’s really an amazing message that needs to be told.
Anderson: And especially for when people say, oh, we just got to modernize because I don’t like this RPG code, or I don’t like this green screen interface, you really need to understand the performance and reliability that you’re getting out of these systems. And how much are you willing to give up in order to be on something that’s on the face of it cooler? And also, as has been documented many times, part of the total cost of ownership value of this platform is it’s a relatively low number of people taking care of it. The administrative costs are much lower than on other platforms. So you really have to be conscious of all of the factors of what you’re getting out of this system. But performance and reliability are huge. That’s really where people sometimes know it and sometimes don’t, like you say.
Guarino: Well, you take it for granted, it just becomes electricity or water. It’s just always there and you don’t realize it until it’s taken away. And then of course, that’s when you really notice it, right? So you touched on some, you mentioned RPG in particular, of course. You mentioned, I heard you say microservices, SQL. I heard you talk about SQL services, but where do these all fit in into a modernization effort? In other words, that’s part and parcel of a larger thing, meaning, I guess my question is what technologies are you looking at or have you used to bring something up to a modern code base or define a modern code base or modern processing, even?
Anderson: Honestly, for us on the IBM CIO organization, we got the most bang for the buck from SQL services. There was so much RPG code that we could replace with a single SQL statement, and it was as performant, it is as reliable. So that saved our bacon on so many things in terms of getting out from under this other tool set, even on user profile management, we had to completely revamp. And what we had for user profile management in the old tool set was pretty good. I mean, I would’ve kept it, but we didn’t have a choice. And then along the way, we’re able to leverage a lot of newer techniques in order to get the same levels of compliance and security and the usability that we had in the old one.
Guarino: Which goes right back to the original point of future proofing an application.
Anderson: Right.
Guarino: That’s a perfect example right there, I think.
Anderson: Yep. It sure is.
Guarino: So what about other newer languagse, for example, open source or even like Python, PHP or the whole gamut, that whole ilk, if you will?
Guarino: That has a place in this conversation?
Anderson: Absolutely, absolutely. Now, I’ve been a big open source fan. As you know, I worked for Zen for a while, and so I’ve been a big fan of open source really for 10 years. My team, and somewhat hilariously to me, PHP is more and more legacy. And so I’ve got people on my team that are just great Python programmers, developers, and they can crank out Python like nothing. And it runs great on the platform, and it integrates with all of our systems, and we can use SQL services with it, and it does well with Ansible. So that’s where I’m seeing a lot of the newer developers, early career developers are all about Python, and I’m fine with that.
Guarino: And we can’t dismiss it for AI. A lot of things are in AI point to Python as well, or vice versa I should say.
Anderson: Right. Yeah. The integration point there is pretty tight.
Guarino: How important is AI to you? And I don’t mean that it’s not important, but is that something that large companies are really looking at as a real viable thing, or is it still just, is it currently the next shiny object? Or are there companies who are really like, well, we need to really explore because we see, I read articles all the time, how companies are already employing it, getting value out of it.
Anderson: Yep.
Guarino:
I don’t know if it is being oversold or—
Anderson: There’s a hype cycle going on for sure, but also I think it really is a game-changing technology, and the area that where I see it having the most value to the IBM i community is—now I’ve been, both as an IBM partner and as an IBMer, I’ve been involved in projects where people want to transform a code base from say, RPG or COBOL into Java. These are companies that have applications that are 20 million lines of code and up. And if you start looking at the cost per line of code to do that conversion, nobody wants to spend that level of money. Also, spend that level of money and move the mess. Because what value are you adding as you do that? The game changer for that, in my opinion, is AI, and more specifically, and it’s not ready for primetime on our platform yet, but Watson Code Assist is going to be a really influential technology that allows us to help customers meet those objectives of, I need to do something with this code base for the following reasons, but I still need it to be performant and reliable and maintainable. And so I think, I believe we’re going to get there, but I want to be very clear, we’re just getting started.
Guarino: And that’s going to keep evolving as well. As far as what its capabilities will be, but how nice it will be ultimately to have something that we will refactor these legacy applications, legacy programs into completely flexible applications that are necessary.
Anderson: Even opportunity. The big code transformation thing, for me that’s still very much pie in the sky, but there are opportunities to use Watson Code Assist or similar technologies for helping an early career developer just understand what this thing does.
Guarino: Absolutely.
Anderson: Because guess what? There’s no documentation and the comments are pretty weak. And so if we can even use it for that, that’s amazing. And the other, in terms of managing the skills issue that is growing for our whole platform, one of the things that we have looked at with some of our clients is we’ve got a monolithic application, and at one customer, we were even just looking at a single program that was 20,000 lines of code. And I know you see this all the time, but are you going to take a brand new college grad and turn them loose on 20,000 lines of code? Wouldn’t you feel better if you could take that? And that program, by the way, had UI, it had database, it had business logic, it was all mixed in, because we were working with the guy that wrote that code 40 years ago, and he’s like, well, “Why would you break it apart? Because it’s all connected to each other. Of course I did it that way.”
Guarino: Well, that’s because that’s what the infrastructure had. That’s what it could do.
Anderson: And that was best practices. That was best practices,
Guarino: Correct.
Anderson: Now we have more of this model view controller kind of concept. So let’s take all the UI stuff out and let’s take all the database stuff out. And so even if we could use Watson Code Assist to help break down that 20,000 lines of code into 10 components, that would be a game changer for the skills issue. Because now you can say to a young developer, yeah, go fix that UI part of it or go fix that database part of it. That’s a lot less risk.
Guarino: It’s funny you mentioned that, that 20,000 line experience, because I once heard somebody, an expert in this area also—they estimated that large programs like that, these big monoliths, for example, 60 to 70% of it is just controlling the UI. The business logic, while it needs to be isolated, it was a small portion of what I think it actually was doing.
Anderson: And that’s what we discovered too. The actual business logic was pretty little, but super important. And also, the other thing I would add to that is that business logic was very specific to that customer. And guess what? SAP couldn’t do it.
Guarino: We talk about modifications very often, and that really is the secret sauce; that is any one company’s proprietary advantage, in my opinion. That’s what gives them each their unique edge in their industry. And that’s been my experience anyway.
Anderson: Yeah, no, very much so. It is how they do, for example, procurement is a really business specific thing, and in the case of this one customer, a competitive differentiator.
Guarino: Pick a function, pick any function.
Anderson: You could say, oh, procurement’s, procurement, how different could it be? It’s a competitive edge.
Guarino: Absolutely. And certain industries, it’s a real competitive edge how you do that. Absolutely. I totally agree with you. So another topic that always, I can bring this topic up in almost any conversation I have, and it has relevance, and that’s security, because that’s always front of mind, or needs to be, in many of these discussions. So when we are looking at a modernization project or things like that, what are some of the thoughts that go into security? Meaning, in other words, how is security going to be affected? Might we be compromising security here? In all cases, we want to embolden it, certainly. And now you have things, zero trust and things like that. So you’re trying to, you want to move, because you mentioned, you don’t want to just rewrite something into a different language and have the same issues. You want to add value, higher value. So that’s something you also strive to bring in more security and making something more stuff.
Anderson: And something I try to communicate to executives who may not be familiar with the platform is as a community, as an IBM i community, we have historically, I’m not saying still, but historically been a little bit behind in our understanding of security and its criticality, because people like me used to go around telling customers this platform can’t be hacked. And that’s when there was, I’m not saying it was before the internet, I am not older than the internet, but we had a sense of security that was well placed back in the day, and that was before the extensive use of the IFS that we see now. It’s before we had so many different ways to connect into a system. It used to be there was one or two ways to connect into an i and you’re good.
But one of the things that we’ve done with clients is when we first start doing some analysis work with them, we run some SQL scripts that will capture all the network connections into a system. And without fail, every time we have shown that to the executive at the client, they say, excuse me, what, I didn’t know we had that many connections into this system. There was a banking customer that had FTP and not SFTP didn’t know. So we have to have this heightened awareness. And really, as consultants, we really have to provide the guidance and to be able to say, here’s some things you need to be aware of. Culturally, we may not have the sense of, that heightened sense of criticality, but we all need to.
Guarino: The old adage that we’ve all been kicking around, and you’ve mentioned it also, oh, it’s the most secure system. And that’s been changed to the most secureable.
Anderson: And I try to get that point across, but it’s also people like me that used to say it a lot, that we kind of ingrained what is now a false sense of security, and we have to have that securable phrase. The other thing I see, again as a consultant is a real need to understand the larger corporations’ security culture. You really have to respect how they run their business from a security perspective and make sure that you are synced up with that. And so it’s, hey, if this is what you do, okay. We did have one customer, and this is a few years ago, that they gave us access into their systems. We were helping them with some data stuff, and they basically gave the IBM consultants almost qsec offer, and we went back to them and said, you need to lock us down. You should not be giving consultants this kind of access. And they were like, well, you’re nice people. And we’re like, yeah, we are. But still don’t do that.
Guarino: Well, at least maybe not to say not a production, certainly.
Anderson: Yeah. But still we’re like, no, no, we don’t want this level of access because A, it’s not right, and B, we don’t want to get blamed later.
Guarino: That’s a fair point. I want to revisit one of the points that you said earlier, and you talked about skills, and that’s something that I just want to bring this point home, and that is that there are some shops that I know you’ve worked with also that skills is lacking in many cases and people just keep doing what they’ve been doing all along status quo, status quo. How do you break that cycle to say, no, we are doing this now this way because we need to? How do you break that cycle when you have these habitual, that’s not fair term, but—
Anderson: Yeah, I feel kind of passionately about this one, and I have several drafts of an essay that I’m going to post on my LinkedIn newsletter one of these days. But part of the point is, I think the developers and the administrators on the platform get blamed for being stuck in the past. These guys don’t want to try anything new. They don’t want to learn anything new. And my experience has been, these are people that are now doing the jobs of two or three people because everybody else got laid off 10 years ago. And if you want them to learn new things, you have to make the time for them to learn new things. If you think that they can sit around and learn Python on the evenings and weekends after keeping your systems up and running seven days a week, that’s not a realistic expectation. So we have to create the space for people to, first of all, feel that learning new things is what the business wants. Because a lot of times they get this like, well, just keep the trains running. Don’t bug me unless it’s a problem. We have to give people the opportunity to learn new things. When is the last time they got to attend even a lunch and learn, much less COMMON, or one of these other, there’s opportunities out there. Regional user groups, do they get to go? Does anybody give them the time for that?
So we really have to stop blaming the victims here and make sure that if we want this to be a viable platform, we have to give everyone the opportunity to stay viable.
Guarino: I want to just make sure that—what you’re saying is very relatable, and it certainly is to any large customer who has the same experience. You mentioned that IBM is just another client in this, not just another client, but you get my point, but there’s got to be some message here too, for the SMBs out. There must be, this is not isolated or there’s no uniqueness that makes this large company a large enterprise issue. Is it?
Anderson: No, I don’t think so. I think in many ways the problem is harder because at those SMBs, there’s sometimes no backup. Sometimes one person is your backup. So if you’re the developer or you’re the systems administrator, if you take off for a day to go learn new things, who’s watching the store?
Guarino: Your access is really felt.
Anderson: Yeah. So I think the problem is a little bit harder. I think you have to get creative with how to manage that, but you definitely need to help people keep their skills current.
Guarino: Cool. What a conversation. What a conversation.
Anderson: We should do this more often.
Guarino: We should do this more often. Okay. How about I set my calendar, we’ll do a recurring podcast for the next—
Anderson: Like it.
Guarino: I do want to mention that you do have something on LinkedIn, your newsletter, Legacy Tech Life. You want to just give it a brief?
Anderson: Yeah, it’s an occasional newsletter, not a weekly or anything like that. And it’s really just my observations and experiences from working in this space that is legacy technologies. So much of what we see on LinkedIn or in other spaces is whatever’s new and cutting edge, and this year it’s cloud, and next year it’s ai and let’s go do microservices. And that’s all great. I enjoy following those things as well. But meanwhile, there’s a community of us that are just quietly keeping the banks and insurance companies and trucking companies up and running.
Guarino: Keeping the lights on. Keeping the lights on.
Anderson: Yeah, keeping the lights on.
Guarino: Good. Well, I encourage anybody listening to this to reach out to Amy, something on LinkedIn,
Anderson: Please follow me on LinkedIn.
Guarino: Love to chat with you. If you’re not one of her followers, I encourage you to do that. You always have some very interesting posts out there, so thank you for doing all that.
Anderson: I’m happy to do it.
Guarino: And you bring clearly a wealth of knowledge and experience on this platform and giving people information they need to make their own cases internally into their own customers to do the same thing you’ve done at IBM.
Anderson: Yep. Happy to help,
Guarino: Great. Amy, this has been a delight. That’s really fun. I’ve always enjoyed chatting with you. I truly do.
Anderson: Yep. Absolutely. Thank you so much for inviting me. I appreciate the time.
Guarino: Absolutely. My pleasure. It’s been a real delight. Thank you so much for your wisdom and again, for your time. Certainly everybody, we’re going to wrap up this little podcast, but thank you very much for joining us. Hope you enjoyed the conversation. Again, follow Amy on LinkedIn, Amy Anderson, it’s worth your time. And this is me checking out saying farewell for now. Not farewell, farewell for this podcast. We’ll see you again down the road. Thank you everybody. Take care now, bye bye.