Matt: Hello everyone. Welcome to the Modern Mainframe. I’m your host, Matt DeLaere. Joining me today is Compuware Executive DevOps Solution Architect Rick Slade. Hi Rick.
Rick: Hey Matt, how are you?
Matt: I’m good, good, thanks. So, you’re here to talk about a new program we’re launching, Building a Better Software Delivery Platform. We’ll have a series of podcasts and Q&A sessions that help people chart a course to start modernizing their software delivery systems. Now, you’ve been helping organizations modernize their software platforms to maximize efficiency without sacrificing quality. You’ll be going through similar disciplines and methods by which organizations around the world are doing that. We’ll have a podcast posted each Monday with a follow-up Q&A session that Friday at 11:00 AM Eastern time. The title of that is Office Hour with Rick Slade. And then the following week we will have a recap blog post about the podcast and the Q&A. So, the idea here is to take Agile and DevOps techniques that are used to deliver high quality software and apply them to the software delivery system. So, can you tell us a little bit more about yourself, your experience, and how you’ve helped companies implement these systems?
Rick: Yeah, glad to Matt. I hope I don’t bore people with that, my background, but I’ve been doing this for, gosh, this is my 40th year in doing this type of work or working in IT, developing software, designing software. It’s something I truly have a passion about. I started in 1980, as an operations guy at university I was at. And then my first work was building or coding assembler, some COBOL. I worked for a company called MSA back in the early eighties, where we built large mainframe systems, business systems, general ledger, accounts receivable, manufacturing systems. So, a lot of background in software development. My formative years, first 10 years, were as a developer supporting multiple languages, multiple databases, multiple telecommunications processors, back in the early days. And so, I had a good background in building software and supporting all of those different platforms and different software subsystems.
I got real good training in the proper development of software. MSA was a great place to start your career. So, I did that for, like I said, about 10 years. The company decided to move to Minneapolis, and of course with this accent, I had no intentions of moving to the cold North, although as beautiful as it is. So, I went to work for Hanes Corporation in Winston-Salem. There I had probably one of the most fun jobs I’ve ever had. I was in charge of new technologies to support software development—a great opportunity to learn because my responsibilities were looking at new tools and new capabilities to expedite, to help developers, be more efficient, to be able to produce faster without sacrificing quality. It was a great place to play with different technologies, play with different toys and software to help developers.
And so, I did that for a couple of years. I left there, to help Micro Focus. Back in, oh, gosh, the early nineties I began a consulting organization for them, helping to take those technologies and skills to their customers, helping to be more productive. I did that for a few years and, long story short, I started a company with some friends back in the early nineties—or actually, create an addition to an existing company. We sold that company to Hewlett Packard back in 2003. I worked at HP for a few years, leading their efforts with regard to software modernization, where we weren’t necessarily modernizing how software was developed, but we were modernizing the existing software stacks, business stacks, that organizations were leveraging. So, a great, great experience there in the reengineering, modernization of software effort.
From there, I went to IBM, spent some time with IBM, about 10 years. A great time, a great experience doing essentially what I have been doing for Compuware the last three years. And that was helping organizations “evolve” is the term I like to use, their software delivery efforts for companies around the world. Traveled quite a bit over the last 20 years again, helping organizations find better ways to build software. And so, we’ve done a lot of different things leveraging process changes as in Agile and better ways to manage software. We’ll be talking about that in this series of podcast series, talking about helping organizations leverage new technologies to expedite the delivery of software. And we’ll talk about some of those today and in a lot more detail as we move into the new episodes of this podcast. I’m looking forward to it, Matt.
Matt: That’s great, so am I. It sounds like you have a lot of experience to draw on, on the subject and a lot of good insights into how best companies can put this forward.
Rick: I think so and I appreciate that. It’s something I really actually have a very strong passion for. I grew up on a farm and so my first experiences with regard to efficiency were helping my dad figure out better ways to take our farm harvest products back to the barns where subsequent work was done and helping to figure out, you know, better ways to expedite that process. And so, my love for finding inefficiency and resolving those problems started at a very early age.
Matt: Right. It’s great that you can take other experiences and apply them.
Rick: It’s been a fun ride. It’s been a fun 40 years. Growing up like I did made adulthood very easy. I have absolutely loved working in software, developing software and now helping clients do a better job of producing high-quality software, hopefully in a more efficient manner.
Matt: Our topic today is “Key Characteristics of a Modern Enterprise Software Delivery Platform. So, how would you define a modern platform versus what organizations may have had in the past or, what they have in place now?
Rick: Well, in doing this for the last few years. I think what I have determined and what I believe is there are certain characteristics, Matt, that are key to effective software delivery and a lot of those characteristics have evolved over different platforms. If you think about the use of Agile and iterative techniques, automation and integration with technologies, a lot of this is the evolution of software development over a 30-year period. And we’ve learned some things. Unfortunately, on the mainframe we are just beginning, I think, to start to leverage a lot of the techniques that have been used outside the mainframe for 10-15 years. People have seen the benefits of those techniques, those methods, those disciplines, those technologies. And we’re starting to see those become available.
Actually, it’s why I came to Compuware. I thought Compuware, when I came here, had the best vision, the best strategy for helping organizations to take advantage of these technologies and these processes. And it’s worked out well. But there’s some key things that I think just define what I want to call good software, not necessarily modern software development, just good software development. I think that I’ve told this to many clients in the past, that a lot of these characteristics that are being leveraged today as the best way to do things; good developers have been doing these things for a long, long time. We just didn’t label them with the labels that are assigned to them today. But key characteristics that I see, and I won’t go into a lot of detail on these today—we’re going to touch on these in our subsequent episodes to talk about each of these in more detail. But I wanted to mention them today to get people thinking about what is prevalent in an organization that’s effective in software delivery?
A Modern IDE
First, I think, and these are in no specific order, but the first thing is that I think a modern IDE is absolutely critical and it’s not for the reasons that many people might think. Yeah, I do believe it’s a more productive environment in which to develop code and test code. I think that you can, when you think about all the work that’s required to develop software, there’s a lot of moving components to that. There’s the editing management of the code. There’s manipulation of test data. There’s the build process, there’s the deploy process, there’s a lot of things that are going on in that software delivery process.
And I think the modern graphical IDE gives you the ability to execute on all of those things simultaneously more effectively. And so I think a modern IDE is certainly more productive. But you know, I like to think of myself as a business guy, Matt, who loves technology and the reasons that I believe a modern IDE is critical is more business oriented than it is for any other reason. If you think about developers, you know, there’s certainly a lot of developers with the same color hair as mine that are still maintaining a lot of mainframe system code. That code we’re leveraging typically in a lot of shops, we’re still managing, editing, making changes to that code. And the same way that I did it back in the eighties and nineties, and what’s changing or what’s happening is that we’re starting to see some erosion of skills on the mainframe as people are starting or beginning to retire or thinking about retirement.
And the folks that are going to be responsible for maintaining those systems typically did not learn how to write test code in a 3270 green screen environment. They grew up on Eclipse-based or graphical environments in the development of their code. And so from a business standpoint, being able to transition responsibility for the maintenance of existing code and that code is not going away in the short term. Even if people think about moving away from the platform, which I would advise against, even if they’re thinking about that, that’s going to be a long process due to the complexity and scalability of the systems that are in place. So if you think about who’s going to manage, maintain that code, make changes to that code as business dictates or as compliance reasons dictate, you want to be able to leverage resources that may not have a 3270 or green screen background.
And so, by leveraging or using a modern IDE similar, or just like [what] developers today are using on non-mainframe code development it just makes for an easier transition—not only easier, but it’s more cost-effective. You can reduce the learning curve required to become proficient in that environment and that lowers your cost. So from a business standpoint, it makes all the sense in the world for organizations to start looking at modern IDEs as they begin to transition responsibility and accountability for these existing code bases to people that are more familiar with the modern IDEs that are available in the market today. I think that’s the primary reason people or organizations need to be looking at that, at transferring to more modern graphical IDEs. Yeah, it’s more productive, but it’s also going to reduce your cost and reduce your onboarding time for bringing in new resources who can maintain this code base that’s so critical to the organization.
Agile and Iterative Techniques
So, I think that’s one thing, the modern IDE and we’ll get into more details on that in subsequent episodes. I think another key characteristic is Agile and being able to leverage iterative techniques, lean techniques—managing software development projects using Agile is absolutely key. You know, 20 years ago, if you would have asked me if—Agile wasn’t really, you didn’t see that much of it—but if it were used, then most people, especially people like myself who were involved in large enterprise software developments, would look at Agile as a way to experiment or to support the development of non-mission critical or non-enterprise class applications. Well, my mind is certainly changed over that. Ten years ago I would tell you that, that yeah, there’s opportunities to leverage Agile and there are opportunities to leverage Waterfall and both have their place. You ask me that today, Matt and I am clearly in the Agile camp. It’s just a better way to build software—to build quality software. And again, the reasons for me are more business-oriented than they are technical.
I think from a time management standpoint, Agile is just a more efficient, effective way to build code, to make changes to code, because I think you can minimize significantly time and rework, and certainly time in defining requirements early in the process. So, I think there are tremendous time savings to be gained leveraging Agile techniques. More than just time, I think we can produce a higher-quality product. I know that in many projects you’re leveraging traditional Waterfall approaches. There’s a significant amount of rework and, unfortunately, typically that rework is done under very tight time constraints at the end of a project where we’re having to patch and we’re having to add fixes that may not be ideal from an architectural standpoint, but we’re caught on time because of some time constraint that’s been defined based on that Waterfall project approach. So, I think that that leveraging Agile, building software in smaller increments, smaller batches, actually has a significant impact on the quality of what code we produce.
Continuous Integration/Continuous Delivery
Another characteristic: Continuous Integration/Continuous Delivery. A lot of talk about what that is and we’ll get into details on that again, in future episodes. But I think that’s critical. Developers being able to apply their changes on a periodic basis, whether it’s hourly or daily or whatever makes sense for your organization. Having an infrastructure to support the addition of code on a frequent basis is absolutely critical to improve efficiency, improve velocity, and improve quality of software development these days. And I think that’s absolutely critical.
Automation may be the most important modern software or evolved software development characteristics. For years we have delivered software leveraging manual techniques. These manual techniques quite often have worked very well. But you’re typically dependent upon the skills of the staff and of the best and brightest within your organization. One of the things that I like to tell folks about automation is that yes, it’s going to be faster, but the real benefit it provides to an organization is its ability to take the best of what you do from a process standpoint and to codify that so that you can exercise or execute that process every time change or additions are applied. And that has a tremendous impact on the quality of what you’re producing. And automation, it’s not just about testing and deployment, which is where most of the work is these days, but it’s about looking at all of the processes and all of the activities within that software development lifecycle and determining where there are opportunities for automation.
Again, it’s not just in testing and deployment. There are opportunities within that process, within an SDLC, around impact analysis. There are opportunities around coding and there are certainly opportunities around gating and monitoring those existing systems. So, automation, if not the most important, is certainly one of the top.
There’s this term being leveraged today called “shift left”. I think that that is another key characteristic or method, discipline that we’re seeing that makes a difference and is critical, I think, to modern effective software delivery. Shift left is no more than building a development infrastructure that allows you to identify problems as soon as possible and to resolve those problems as quick as possible. Shift left just comes from looking at the software development life cycle in a linear fashion and doing the work necessary to identify problems as early in that process or on the left side of that linear line as possible. And the reasons are, again, more business than they are technical. Your ability or the ability to control cost and to control risk is much more favorable if you can find and resolve problems early in the process. Too many times, we hasten to get software out the door and then problems are identified and resolved in production, which is absolutely the most costly place to manage their change. And it certainly introduces risk into your organization as well.
Test Data Management
Test data management. I think this may, it ranks up there with automation. If we’re going to leverage Agile and if we’re going to leverage automation, test data management is absolutely critical to support the automation of your software delivery pipeline activities. If you think about the provisioning of the testing environment and your test data, doing that manually is very time consuming and quite honestly wrought with the opportunities for failure. I think organizations, as they start to leverage automation, are going to be dependent upon test data that can be easily and quickly provisioned to support the automation of testing. And so, test data management, I think, will become one of the key requirements for high-velocity software delivery.
Another key characteristic is collaboration. And you know, we spend way too much time or in the past we spent way too much time in this industry in status meetings and preparing status reports to effectively communicate the work of one group or one individual to others. So, to support a smooth rollout, we’ve got to embrace technologies like JIRA and others that provide real-time information to all invested stakeholders in that software delivery process—in real time. Those technologies are critical to providing the information needed by designers, by testers, by developers, by operations staff. If everyone who’s involved and is a stakeholder in that software delivery process has available information to them during or as that process is being executed, the better prepared they can be with regard to the execution of their work when the time arrives. So, improving collaboration, minimizing time in status meetings and time developing status reports that aren’t directly impacting the software delivery effort is absolutely key.
A couple more characteristics that I’ll talk about briefly… Security is one. You cannot talk about modern software development without talking about security. And I won’t spend a lot of time today in this, but with regards to the mainframe, it has the same security constraints that any other platform has. Although as we all know, it’s probably the most secure platform for delivering software that we have. But the ability to ensure that code changes or code additions that are applied to existing systems or to new systems—we want to make sure that the capabilities that we have to assess that code are a part of that software delivery process. And there are methods, there are technologies that can be leveraged in today’s software delivery architecture that can be executed automatically and we need to make sure that the means, the technologies that we’re using today to assess and to secure our code can be leveraged in an automated fashion.
Measurement & Monitoring
And then finally, I want to talk briefly about measurement and monitoring. One of the key characteristics of good software development, modern software development, is the ability to constantly evaluate the means and the methods by which you’re delivering code; the technologies, the processes, they all need to be constantly evaluated. The one thing that I do know after doing this for 40 years is that methods will change; technologies will get better. And so we want to make sure that we are collecting the information within that software delivery lifecycle that will allow managers, that will allow organizations, to make the best decisions regarding the processes and the technologies used to deliver software. And the only way to do that is through constant or continuous measurement and monitoring. And I think that if we can do that, we have certainly a better way of constantly or continuously improving the software that we deliver.
One other key thing that I think is incredibly important with regard to measurement and monitoring is that we’ve got to look for capabilities that will allow us to automatically capture that information. I remember, you know, as a developer years ago then I spent a lot of time tracking different activities of work that I was doing and of course that time is taken away from actual coding and testing. And so, one of the things that I encourage my clients to do is to look for technologies that are going to produce the metrics that are critical to your organization and your goals and objectives from a software delivery standpoint, and being able to capture that information automatically. Being able to present that information to the appropriate people or appropriate stakeholders in a timely fashion is absolutely critical. And it’ll give your organization the ability to make adjustments within your pipelines, within your processes to, again, keep you operating as efficiently and as effectively as you can.
So, just to review from a characteristic standpoint, if you’re looking to build a modern, effective software delivery environment, there’s some things I think are absolutely critical:
– A modern IDE
– Leveraging iterative and Agile lean techniques.
– Being able to provide for a continuous integration and a continuous delivery architecture to support constant additions to your baselines.
– Automation. You know, where there is opportunity within that software delivery process to automate work, we should be taking advantage of it.
– Shifting left, building an infrastructure that allows organizations to find problems early and to resolve problems early.
– Having an effective test data management system that will allow you to stand up your testing environment and provision your test data per release will save your organization tremendous time. But it will cross some time and effort.
– Better collaboration tools; being able to communicate real time with all stakeholders within that software development process.
– Building security into your processes, automated or manual.
– And then effectively measuring and monitoring those metrics, those key performance indicators in your organization that will allow you to produce software as effectively as possible.
So those are my key characteristics. Again, Matt, we’re going to talk about each of these in detail in subsequent episodes. But those are what I think are key to the modern or effective or good software development.
Matt: Most of these ideas, they’re not only interesting, they make a lot of sense to me and I’ve seen them in previous jobs where things like Agile and things like shift left methodology would really help in other industries. So, it all makes a lot of sense. It seems to me that there would be a large cultural change needed as well. How can companies go about achieving that?
Rick: That’s a good question, Matt. And you’re exactly right. It will require cultural change. Changing the way people work will be difficult, especially for the old gray-hairs like myself who’ve been doing this for a long, long time. And quite honestly, we’ve been successful at it. It’s one of the problems that we’ve got in this business is that if you think about mainframe software developers, we’ve got systems that have been running 30, 40 years. So, telling us that we’re doing it wrong is going to be a hard thing to overcome. And to some extent, they’re right. It’s not about that the processes that we’ve leveraged in the past were wrong. It’s just that we’ve got to get faster at delivering the same type and same quality of output. And I think that the techniques that we’ve talked about, technologies that we’ve talked about, give us the best shot at doing that.
Now, with regard to cultural change, I have a longstanding saying that I tell my customers that that cultural change is not, um, an action to be taken, but the result of actions taken. And what I mean by that is I think the best way to, to cause cultural change to occur is through incremental evolution or projects to begin changing the way we work; looking at the existing methods, understanding where the bottlenecks are, understanding where the gaps are, understanding where the work is being slowed down and leveraging some of the techniques that we talked about today and we’ll talk about in the future to improve upon those areas of weakness within our software delivery cycle. And so, cultural change will occur as we get wins and as we start to implement change in how we get work done. And I think that, you know, I’ve never believed that there is a JIRA story or an Epic to change culture. Again, I think culture is the result of actions taken. And so we can start by looking at, you know, the current methods means by which we deliver software and start to think about how we can improve upon that process. Again, it’s an evolutionary-type change, I think that’s going to occur and I think that’s been most effective in my experiences. And so we can start to work on incorporating some of these changes in an incremental fashion. I think that that will create the cultural change that modern, effective software delivery organizations are seeing.
Matt: So, it’s funny that you brought that up because that’s what I was thinking, as well, as you were explaining it – that it’s not a Waterfall thing. It’s more through sprints and through incremental progress.
Rick: Yeah, that’s going to be an episode we’re going to do, Matt, in the future. One of the things that I believe in strongly is the method by which we incorporate these changes. We can leverage Agile and we can actually leverage DevOps-type techniques in the management of that software delivery lifecycle. And we’ll get into that in detail because I think that is absolutely critical. You know, we have leveraged Waterfall techniques for the incorporation of new tools ever since I’ve been in the business. I’ve been in Agile shops and they are looking to implement a new IDE or to implement a new build or deploy tool or automate a particular work activity and they’re leveraging Waterfall techniques to implement these changes to the SDLC. And what I’m telling folks is, no, let’s start to leverage the same techniques that organizations truly believe are producing higher benefit, better software. Why not incorporate those same methods into the evolution or modernization project for the software delivery life cycle?
We’ll spend a whole episode, assuredly, on managing the software delivery life cycle as a critical business system. I wrote an article about this not long ago about treating the software delivery system or the software delivery lifecycle, platform some would say, as you would any other critical business system, with a dedicated product owner. If that software delivery system, you see that as a business application or a business system, then you want to manage it the same way that you’re managing your other critical business systems: with accountability, a product owner, maybe resources or a resource that’s dedicated to the effectiveness of that system just like you would a commercial banking system or retail banking system. Whatever’s critical within your organization.
We’re all learning, and I think most of us know now that software delivery is a critical component to software development within any organization, regardless of your business. You’re a Finserv, or you’re a manufacturer or you’re a retailer, your ability to produce software for your customers, for your employees, for your partners is absolutely critical to the success of your business. And again, you don’t have to be a software organization to understand those benefits. And so, if you believe that and you believe that Agile and DevOps, and leveraging a lot of these techniques that we’ve talked about is a better way to deliver software, why is it not a better way to deliver software development? But we’ll get into that in future episodes.
Matt: Well, that’s a great way to think about it. So I think we’ve got a good start here for our series. I want to thank you for joining us today and as you said, we’ll go through a lot of this in greater detail as the weeks go by.
Rick: Hey Matt, I’m excited, man. I think it’s going to be a lot of fun. I love getting in front of clients and talking about software delivery; it can be a little different, doing it digitally. But I’m looking forward to the opportunity and hoping people will join us.
Matt: Great, thanks. So again, we’ll be having a podcast posted each Monday; the following Friday we’ll have the Office Hour with Rick Slade Q&A where you can ask questions and find out more about the ideas that we talk about in these podcasts. Our first one will be this Friday, May 8th, at 11 AM EDT so you can join us and ask Rick some questions. If you need to find links to any of the podcasts, to the Q&A sessions, or for more information, you can go to https://www.compuware.com/goodcoding. So, thanks for joining us today and we’ll talk to you Friday and next Monday. Thanks.
Rick: Thanks, Matt. Good coding, guys.