Chapter 15: SDS Overview

Chapter 15: SDS Overview

Send Us Feedback

Listen on Itunes

Listen to Stitcher

Matt: Hey everyone, welcome to The Modern Mainframe.

Thanks for joining us for Chapter 15 of our series, Building a Better Software Delivery Platform, in which Compuware Executive DevOps Solution Architect Rick Slade draws from his years of experience to help you create a modern software delivery system. So, let’s say hi to Rick. Hey, Rick.

Rick: Hey, Matt. How are you? I’m doing well. Hope you are.

Matt: I am, thanks. Well, we’ve spent 14 episodes discussing different aspects of the modern SDS from IDEs and SCMs to test data management and the collection of meaningful metrics. So, we thought that now would be a good time to bring it back around for an overview of the entire SDS, and talk about why modernization is so critical, as well as how our listeners can leverage DevOps and Agile methodologies to create a world class software delivery system.

So, with that in mind, right from the start, Rick, you’ve talked about the software delivery environment being another critical business system for an organization and how it should be treated like one. So, can you expand on what you mean by that? And maybe talk about the key characteristics of a modern software delivery system?

Key Characteristics

Rick: Yeah, Matt, and I’m glad… it warmed my heart to hear you refer to the software delivery ecosystem as the SDS, the software delivery system. That’s been a real theme throughout this summer, and I have thoroughly enjoyed doing these podcasts with you this summer. The software delivery system to me is no more than that ecosystem that we use to deliver software to a production state regardless of what you do as an organization. We in the software business, we have different products, software products, that we deliver to market, and we have systems that we have built to support the delivery of that code to a production state so it can be delivered to our customers. But other organizations—if you’re in financial services or manufacturing or retail—you have software delivery ecosystems as well. And I think it’s important to start managing those ecosystems as a critical business application or system for your organization. I think in today’s world, it may be the most critical business system within your group. Your ability to deliver software to support your customers and your partners, your employees, it’s more critical today than than ever, and I think we’re seeing that.

You think about all the ways that we interact with vendors and with suppliers, with organizations that we’re buying goods and services from, and just how critical software is to those relationships. And I think that it’s just something that we’ve got to become world class in, regardless of whether you’re a software provider or not. I think that, again, if you’re in any of these organizations, your ability to deliver software services will determine your future, your survival, your ability to compete with other organizations.

As Chris O’Malley says multiple times, “fast beats big.” And so, we’ve got to provide the same type of support and management around our software delivery systems that we provide other critical business systems within the organization.

As far as key characteristics of the modern software delivery environment, I love to talk about these things. I think that there are multiple things, and some are going to be more important than others based on the needs of your particular organization. But there’s a few things that I think are critical with any group.

I think it begins with a modern user interface to software development, and that can take form of many different technologies, Eclipse is kind of a standard right now for developing software, but there will be others, there are others that are starting to become available. And I don’t have preferences over which is better. I do believe that that interface to software development should be standardized. And what I mean by that should be a tool that can be leveraged across multiple platforms. I think that the future of software is about software development where the target platform is, I don’t want to say irrelevant, but not a concern of the software developer, I think technology is going to… and automation will be key to delivering working code to those platforms. And so, the idiosyncrasies of particular platform and the knowledge required to deliver code to a certain platform is going to be less important in the future. So, building a user interface or a modern IDE that can span multiple platforms, I think, should be a goal. I think that’s a critical characteristic of a modern software development system

I think the use of Agile, Matt, is critical with regard to managing software development. And there are some other things. I don’t know how far you want me to go into that. I’ll stop right there in case you’ve got other questions, but I think there’s some other characteristics that are critical as well.

The Most Critical Characteristics

Matt: Okay. How about you name a couple more? Which ones do you think are most critical?

Rick: Great question. I think there’s two things that are most critical. adopting Agile, I think, that I just talked about is critical. I think that it provides the ability to produce quality software at a faster pace. I think it minimizes rework, so I think from a business standpoint, time to market can be achieved though the leveraging of Agile. I think that quality is greatly enhanced through the use of Agile. I’ve told this in other forums where I’ve had the opportunity to present; I think that being able to leverage the best of what an organization does and to codify those processes, will have a significant impact on quality.

The other, as far as most important, and again, we can have religious discussions about this, but the other one’s going to be automation. I think I referred back to this in the earlier discussion around the future, but automation is going to be critical—it already is. In forward thinking organizations, they’re already leveraging automation to handle a lot of the work that in the past has been done by developers. But a lot of that work is labor-intensive, I don’t want to say mundane, but a lot of sitting and watching and monitoring by high-priced developers, on the execution of test and deployment, it’s not wasted time, but it’s time consumed that could be leveraged in generating new capabilities, new features that users can leverage. And, automating a lot of that work within that software delivery process is another critical, I think, component.

There’s a couple other, if I can take the time to talk about, because I think they’re important. Continuous integration/continuous delivery as a model for applying change, I think is important. I think organizations need to really think about how they can implement those disciplines within their software delivery systems, because I think that they give you again, the best chance of getting quality software to market fast.

The ability to shift left, meaning getting or building a software delivery system that gives you the opportunity to identify issues and problems and to resolve those issues and problems as quickly as possible within that overall software delivery life cycle. And that means providing better testing and to provide better testing, having test data management systems. Automating a lot of the unit testing and functional testing and integration testing and even regression testing that takes place so that you give yourself… You give your developers the ability to find problems fast, doing that’s going to save you money and certainly going to save you time.

I talked about a test data management system, I think that in a modern software delivery environment where Agile is being used to manage that work, test data management is critical, because we just don’t have the time to re-provision, set up test environment every time changes are made and we’ve been doing that for years in the software business. We’ve got to get much better and standing up our test environments and leveraging virtualized services to do a lot of the testing that we’re doing so that we minimize the time required to do that test. And again, a lot of that work is just repetitive, we do the same thing over and over and over again. We’ve got to minimize that.

And then collaboration is important. Obviously, building security into that software delivery system is critical. And then lastly, as far as a characteristic, the ability to measure and monitor your activity within that SDS, because that’s going to provide the support and the information needed to produce a continuous improvement structure around your system.

Things are going to change, your system is going to evolve, it’s one of the reasons I believe, against the grain of some others, that a dedicated software delivery system team is important. Technology is going to get better. New features, new capabilities for the developer are going to be made available through companies like ours, and so being able to consistently measure your progress, your productivity, your quality, time, all of those things that are important to the business should be a part of that software delivery system and part of a continuous improvement program.

So, I think those are some of the key characteristic that I see are critical to that software delivery system.

Matt: And a lot of those are interrelated, they’re not mutually exclusive. The automation helps create more time for developers to work and they can meet the deadlines within the sprints. And the automation helps with the testing and with CI/CD, so it all kind of… It all works together as one big unit.

Rick: It does, it does work together. They’re all dependent upon one another, but they will make a difference in the delivery of a production code.

Getting Started

Matt: So, now for the question that I’ve asked repeatedly, how do organizations get started with building a modern SDS?

Rick: I love that question. I think it’s important that we continue to harp on that. Getting started, it can be a difficult process. I tell developers, particularly mainframe developers, we’ve been doing this for a long time, most of us, and quite honestly, we do a pretty good job of it. If you think about mainframe systems, a lot of these systems have been working and have been effective for 30, 40 years. And so to tell someone that we need to change how we build those type of systems with that kind of success record can create conflict.

And so, yeah, I think that that people have to understand that it’s not that the procedures and the technologies that we’ve used in the past are bad, it’s just they don’t allow us to produce software at a speed, and with the quality required to effectively compete against those organizations that are leveraging these type of capabilities and techniques to produce software features and capabilities for their customers much faster and that puts an organization, certainly, at a competitive disadvantage if they’re unable to do that.

So, getting started, I think it begins with the commitment at the top. Organizations that have been successful in adopting or modernizing their software delivery infrastructure or system are those that have executive support. And so, having an executive sponsor who understands the value of a modern software delivery system and what it can and the impact it can have on your organization, and to provide the support to make it happen is the first step. And that requires education, it requires an understanding by those executives to know what the potential return on an investment in modernization will be.

I think that the next thing is defining ownership for that software delivery system. As I mentioned earlier, I think that the best way to manage a modernization project and to effectively implement a modern software delivery system is managing it like you would any other critical business system. And what I mean by that is assigning product ownership. There should be a product owner. There should be a team or teams that to comprise or that provide support for that software delivery system, people who are going to be responsible for installation, configuration and testing of software delivery system capabilities before they get rolled out to specific teams.

I think that you leverage Agile in the management of that work. I think that working in traditional two-week or smaller sprints, smaller segments of work to produce that SDS will enhance the quality and make it easier for your developers to embrace and to leverage that technology once it’s given to them. I see way too many organizations who try to use a traditional waterfall approach to implement a modern Agile software delivery system. It’s kind of crazy if you think about it.

And so, I think that that leveraging Agile, having ownership, doing or implementing changes in increments is the best way to get started with this.

Waterfall vs. Agile Implementation

Matt: So, you’re a solution architect. How rigid does a blueprint have to be before a company gets started with this? Do they have to really lay out what’s going to happen when, how? How much play is there within the plan as they go forward?

Rick: It’s a great question, and again, if you listen to the question, that’s… It’s a waterfall question, if you think about it. Because if you’re leveraging Agile to make modifications and you’ve got a large project that you want to make to a retail banking system, and what Agile is about is not trying to get all of your requirements nailed down and perfect before you start work. There are basic tenets of architecture that you want to adhere to in building any type of solution, but I think that trying to get all the requirements nailed down, trying to get every feature and capability that might ever be used within an organization solidified prior to rolling this out, will just elongate your process. You’re never going to get it right.

I’ve talked to developers after developers—and I’ve been doing this for 40 years—and using waterfall techniques, I’ve never been in a waterfall project where we were able to successfully define every requirement and get every T crossed and I dotted before we started the development work. And so, I don’t think that that works either for the implementation or development of a software delivery system.

So, no, I think that there are basic tenets. I think you have to work hard to understand what your minimum viable product is going to be, or your minimum viable SDS solution is going to be. You work on that, you solidify that, you roll it out, you get feedback, and then you’re going… That feedback is going to be a blessing because you’re going to get direction on what’s needed and what to work on versus trying to do all that on the front end. So, again, I’m a big believer in leveraging Agile techniques. I don’t think that you take the time to solidify and capture every requirement before getting started.

Testing and Automation

Matt: Right. So, throughout the series, you focused a lot on testing and on automation. Why are those two so important?

Rick: Well, first of all, testing. Being in this business for as long as I have, I spent a lot of years in software development. I spent several years at Hewlett-Packard, leading their application modernization business, where we’d go in and work with clients to re-engineer, restructure existing applications, add new capabilities, new feature sometimes. But the intent was to try to build an application on to an architecture that would allow faster change. We typically did this with a lot of applications that we considered to be dynamic in nature, meaning that they were constantly evolving, constantly changing based on compliance or development or market requirements. And they needed to be built on an architecture that allowed for quick change.

When doing a lot of that software development work, there were two activities that consumed most of the time in the software delivery lifecycle. One was impact analysis on the front end. I mean, you’ve got an existing system and you’re looking to make major architectural changes or quite honestly, any changes to that system, depending on the scope or complexity of that system and depending upon the resources who are actually charged with determining what changes were required and how, it took a significant amount of time to do that work. And that’s another story for another day.

But the other thing and or the other activity within that software delivery lifecycle that consumed so much time was testing. And again, for a lot of the reasons that we talked about in prior podcasts. It takes significant time to do testing the way that we traditionally have done testing, particularly on the mainframe. We do a lot of what I call black box testing where we make our changes to our code, compile, link edit that code, and then we run that program or programs, and then we evaluate the results. results being either change screen or change report or change file against some benchmark.

And it’s a very labor-intensive manual process to ensure that everything’s working properly, and it may require multiple executions, multiple runs to ensure that proper expectations have been met with the changes made. And so, it’s very time consuming, it’s very repetitive. A lot of that test data and test environment provisioning consumes time, but it’s time that’s consumed every time we want to run a test. Now, a lot of… most developers, they try to get smart about how we’re doing it, but it’s still very time-consuming. So, that testing activity is consuming so much time.

Well, automation is, I think, the perfect fit in trying to resolve some of that. Especially, Matt, from a provisioning standpoint with regard to the environment and the data. If we can start to leverage the computer, the machines to do a lot of that work for us automatically, at the time of execution, there’s going to be significant time saved with regard to just the manual work required to stand up a test environment and to provision it with a test, the right test data. Leveraging automation to do a lot of that work for us is so important to reducing that overall cycle time for software development and testing is important, it’s one of the things we talked about, but automation spans that entire software development lifecycle.

I think that there are technologies available to us—we offer a tool, Program Analysis under Topaz—that can help the developer significantly with that impact analysis time that I talked about. Being able to use that technology and that information to minimize the time required to do impact analysis, nd to create your punch list for work that needs to be done. It can also be used… We talked about testing, but it could be used for that, and I’m not talking about just unit testing, but unit testing, integration testing, regression testing even some UAT. And so, automation will have a huge impact on the time required to execute those tasks.

So, I think those two will have the biggest impact from a business standpoint with regard to software development from a timing standpoint, but again, also from a quality standpoint.

Matt: Right, and I’m sure that automating the testing is more thorough. I’ve seen in the past, and not on the mainframe, but I’ve seen with waterfall development, they wait to test until the end and they’re not really sure where the problem happened, or they don’t really have the time to check it against everything else that’s there, so problems pop up once you get into production. So, it probably helps with the thoroughness of it, too, right?

Rick: No doubt. Again, the beauty of automation is that you take the best processes and the best methods and the best technologies that developers, that your best developers are leveraging, and you’re able to codify that so that now the best of what you do can be spanned across the entire software delivery process across other teams, across other developers, and that’s going to have an impact on the quality of what you produce.

The Future of Software Delivery

Matt: So, finally, I’ll ask you to look into your crystal ball and tell us what the future of software delivery looks like.

Rick: Oh man, I wish I knew. I really wish I knew. There’s some things that I think are happening, that I see happening today. I mentioned one of them earlier, and it’s worth mentioning again. I think that in the future, developers will be less concerned with the idiosyncrasies of the platform itself. I think that technology is evolving—and we see it in front of our own eyes, we see it happening today—to where developers are working on systems, and within that system there will be mobile components, there may be web server components, they may be risk-based components, and certainly, there will be mainframe components for any large transaction processing system. These systems are made up of multiple technologies, multiple components that run on multiple platforms, and to ask developers to have knowledge about all of those, I think it’s futile, and I think it’s very time consuming, and that’s why automation is going to play such an important part because I think a lot of that work to deliver that code to its resting place from a run time perspective can be handled by the computer.

And so what I see happening, what I encourage people to start thinking about is the building of an ecosystem where developers are focused on logic and the code responsible or required to implement new features, new capabilities within these systems, so that once they make their changes, they commit those changes to some type of software delivery system that may begin with an SCM component. And then from there, all the work required to successfully build that application, to test that application and deploy that application can be handled by the machine.

With regard to how it’s delivered, it can be managed through release management automation capabilities that can be defined. I think that there will be individuals responsible for the delivery of software, maintaining those software delivery systems, keeping them tweaked and tuned to be as efficient as possible. I see a role for that in the future because again, as I’ve said earlier, that software delivery system is so critical to almost all organizations today that there be roles and dedicated people to ensure that it operates as effectively as possible.

So, I see that; I think that’s probably the biggest thing that I see with regard to the future of software development, which I think is a good thing. And it’s almost cyclical for a lot of us mainframe guys. When I started in the business everything was targeted to the mainframe; it was pretty much a single environment. But I didn’t have to worry about the specifics of the platform, itself. Pretty much all I had to worry about was the logic in my COBOL code, and then there were people who took care of adding my CICS entries or whatever, or doing a lot of the backend work. I just had to focus on code. I see us headed back to that direction, and I think that’s a good thing because that will allow developers to be focused on solving problems versus managing the nuances of the platform that they’re developing to.

Compuware’s Role

Matt: Okay, I have a bonus question. You meet with customers, you talk to people about how they can set up their own software delivery systems, or modernize them. Can you talk about that process a little bit and how if somebody out there wants to get to work on this, what they can do and what you do to help them.

Rick: I appreciate you asking that question. You can contact me directly. I’ve given my email ID out on the podcast several times, mailto:[email protected] You can please contact me directly with questions you might have. Through Compuware, you can work with your account manager. And so, if you’ve got questions or you’ve got interest in trying to leverage some of the techniques that we’ve talked about in the podcast or implement a modern software delivery environment, I’d love to talk to you about it. We’ve actually developed workshops to help organizations with understanding what they need to do to begin this effort.

When I was at IBM, when I first started with Compuware, we would do these one day, two-day workshops where we’d go in and we’d educate clients on what the possibilities are, and then we’d spend time value stream mapping the software delivery lifecycle or components of it, like testing, to determine where the opportunities for improvement are, where the low-hanging fruit was. And then once we completed that, and got agreement with a customer on what those things were, then we’d work with that customer to start building an implementation plan. And we did that in a two-day process.

Well, we divided that work up—being that travel is almost impossible for most clients today, and for us—broken that work up into three different workshops or sessions, and they each last about two hours; a little less, a little more, depending upon how much complexity and how much time you’re willing to give us to help you with that. But the first workshop, or session, is what I call an education session. Two hours, talking about what the benefits of DevOps are and how mainframe organizations across the globe are implementing or evolving their software delivery systems.

And we’ll talk about the technologies, we’ll talk about the process changes required to make this happen, but we’ll also talk about what an organization needs to do in order to prepare itself to begin planning their implementation. Because again, as I said earlier, I think there’s some key things that need to be in place prior to beginning this: executive commitment, sponsorship and ownership of the software delivery system, where a product owner or an SDS owner is identified and we start to identify team members. It may be one person. When I started doing this years and years and years ago, I was kind of a one-man team on that software delivery system. But that will depend on the scope and complexity of what you’re trying to implement; you’re not talking about a huge team. But getting those things done, I think is important. And so, that’s what the education workshop….

Second workshop is, we’ll call a value stream mapping workshop. And what we do is we look at that software delivery lifecycle in its current state; how are you doing things today. You leverage a system today, you just may not refer to it as that, but there are processes, there are tools that you use to deliver code to a production state on the mainframe today. So, we’ll work with the client to understand what those are. We’ll talk about where some of the issues are with regard to the time it takes to produce software, the quality of that software, and we’ll dig into those processes and those technologies. And then, with that information captured, we’ll produce a set of recommendations on things that based on our experience, that we think could be leveraged in that customer’s evolutionary journey. And that typically works real well. We do a lot of those.

And then the final workshop session is a planning session. And so it’s a traditional Agile planning session, just like you would with any other application we. We have a backlog of stories and tasks at that we store and manage in our own Jira environment here at Compuware. But we’re able to export that backlog into a CSV file and then we can import that backlog of stories into your project management system. And it could be… I love Jira, I think it works real well for this, but it could be other things, Trello or even Microsoft project, if you want to do it from a traditional standpoint, I’ve done it with Excel. But we’ll import those stories and then we’ll start to define sprints or a project plan to identify the work and start attaching names and times to that work to begin your transformational journey. And so, it’s a planning session.

So, to recap: three sessions, an education session to educate people in the organization on the how to do this, a value stream mapping session to understand current state delivery architecture and to produce a set of recommendations to move you forward, and then the last, planning session to actually build implementation plans for those recommendations, if it’s a journey that the organization is looking to move forward on.

Matt: That’s great. So, I think that about does it for today. Thank you to everyone listening. To listen to the entire series and watch recordings of Rick’s weekly Q&A session, you can visit www.compuware.com/goodcoding. And you can join us for Office Hour with Rick Slade, the previously mentioned Q&A session, this Friday at 11 AM Eastern Daylight Time.

Well, Rick, thanks for all the time and effort you’ve put in the last few months in explaining the modern SDS and helping our customers wrap their heads around it and learn what they can do to get the most out of their software delivery. I know you’ll be back in the future to create some new podcasts and share your expertise, so I’m looking forward to that. So, until we meet again, I’ll give you the last word.

Rick: I appreciate it, Matt. I appreciate working with you guys, This has been… I’m used to going out and talking to clients, that was my job for a long, long time on the road, and I love… I still love it. I still love talking about software development, I still love helping people produce better software faster. It’s just a passion that I’ve had for many, many years. So, this podcast gave me the opportunity to talk about some of the things that I’ve learned over the years and how organizations are successfully changing how they build and deliver software. And so, I appreciate the opportunity to do that. We’re going to continue to do more stuff. We’re going to take a couple of weeks break, but we’ve already got some other ideas of podcasts and live Q&As to hopefully help people take advantage of some of these new capabilities with regard to software delivery.

Big mainframe fan. I think that it’s a platform that will certainly withstand time. It’s the most modern… people—my closing comment, because I say this all the time, and this is important to me—people talk about mainframe modernization and use that term all the time, and it drives me crazy, Matt. The mainframe is the most modern, sophisticated software delivery, business software delivery platform in the world. Mainframe doesn’t need to be modernized, what needs to be modernized are the methods and the technologies used to deliver software to the platform. So, software delivery system modernization, software delivery ecosystem modernization is what we should be focused on.

And with that focus, we can deliver code to this platform; the best platform in the world for managing business transactions more effectively, more efficiently and with higher quality. And so, I’m passionate about that, and we’ll continue, like I said, we’ve got some other things we’re going to do, and I look forward to doing those as well.

I appreciate everybody who has downloaded these podcasts and I’ve gotten several notes of thanks regarding them. And so, I appreciate that. I appreciate all the feedback that we’ve gotten from it, and I look forward to continue doing these type or providing these type of services. And hopefully one day we’ll be back on the road again doing what we do, helping customers build better software faster.

Thanks to all. Take care everyone, have a great week. Stay safe, please. Good coding, all. Take care.