Chapter 3: Managing Software Delivery Platform Evolution

Chapter 3: Managing Software Delivery Platform Evolution

The Modern Mainframe ·
Send Us Feedback

Listen on Itunes

Listen to Stitcher

Matt: Hey everyone, welcome to the Modern Mainframe, I’m Matt DeLaere. Thank rejoining us for the third installment in our series, Building a Better Software Delivery Platform,” in which Compuware Executive DevOps Solution Architect Rick Slade shares insights he’s gained through years of helping companies modernize and maximize the efficiency of their software platforms.

Speaking of which, let’s say hi to Rick. Hi, Rick.

Rick: Hey Matt, how are you, man?

Matt: Good, good, thank you, how are you?

Rick: I am doing well.

Matt: So, today we’re talking about managing the evolution of the software delivery platform. Can you give us a quick overview of what that means, of what’s involved?

Rick: Well, a mainframe software delivery platform, it starts with understanding what that software delivery platform is. And, as I’ve talked about, in my mind, it’s a system, it’s an application, it’s a business application critical to the success of most organizations. It’s a platform that’s been around in some cases for large enterprises for years and years and years. I was writing code back in the late ’70s, early ’80s. So, it’s been around.

And those processes and those technologies have been there. It’s constantly evolving, Matt. We’re constantly learning how to do things better, where using new processes where you’re leveraging new technologies and we’ve got to get better, we’ve got to get faster at what we do. But that software delivery platform is the means by which you deliver code within your organization to a production state. And today I kind of want to focus on three major activities that are involved in managing the software delivery platform, or as I’ll try to refer to it more often, the software delivery system.

Again, three things I want to focus on. First of all, getting started, what’s getting started look like? I think it’s one of the biggest obstacles for a lot of organizations, especially on the mainframe moving away from processes, and even tooling, that has served our mainframe software development community well, for many years, can be challenging. It’s tough to change the way we do things, especially when it has worked so well. A lot of people talk about evolving, changing, and modernizing software develop on the mainframe.

And in my mind, and I want to make sure everybody is aware of this, my feelings on this; it’s not because we are not or have not produced quality software with the approaches and with the techniques that we’ve used. They have worked well and the evidence in that is the length of service that some of these applications have been providing capabilities to our organizations. Some 30-40 years.

The problem that we’re facing is speed, we’ve got to deliver these changes to these systems, new capabilities, new features within these back office or mainframe systems at a faster pace in order to more effectively compete.

So, speed is the issue, and so you start to look at what can we do to accomplish that? So, I want to spend a few minutes talking about just getting started, getting going. That is the key to beginning that evolution or that transformational journey.

The second thing that I want to spend some time today talking about is actually executing the plan. There’s work to be done to define what your expectations and what the architecture of that software delivery system should look like, and what its requirements will be. But then there’s a process of actually executing the plan. And I want to spend a few minutes today talking about that.

And then finally, once you’ve got a software delivery system that is in place and there are dedicated resources associated with managing the effectiveness and the efficiency of that software delivery system, what are the things that we need to do to monitor and to manage that software delivery system just like we would any other critical business application within the organization?

Defining the Software Delivery System

So, I want to review from last week, something that again is important to me, and it’s… Again, defining what that software delivery system is. As I’ve stated, it’s the ecosystem, it’s the platform, it’s the processes and the tooling that developers and testers and operations people leverage to build or design to build, to test, deploy, manage, software. And that to me is critical, especially in today’s times, where the production of software, the use of software for most organizations is critical to their success.

And looking at that software delivery platform as a business system comes with some additional requirements from the organization. If you think about how you manage your existing business systems, your critical business systems, typically there is accountability somewhere within the executive ranks, certainly within the management ranks to ensure that that system is operating at peak efficiency, especially those systems that are mission critical to the organization.

Well, it’s my contention that software delivery has reached a point, if not several years ago, to where it is absolutely critical to the success of our companies, and our organizations, private or public. And so, thinking about all of those components and requirements, of a mission critical system, it begins with accountability, it begins with ownership, and then there is a method by which we can manage that system. So, that software delivery system, starting think of it as a business application for your organization and managing it as such, I think, will lead to more successful, higher, faster, higher quality, faster producing IT organizations.

Getting Started

Matt: Well, getting started—it’s a big thing for any job, especially a big one and one that’s going to require a lot of change. So, how does an organization go about getting started? What are the first steps?

Rick: Matt, I think it’s just so critical. I have been in this business for a long, long time. I was helping organizations evolve software delivery back in the ’80s. And the first step is just doing something. There’s a lot of… I don’t want to use the word apathy, but maybe it’s the right word, but resistance to change. And again, maybe for valid reasons, sometimes. Because you think about the successes that we’ve had, especially on the mainframe in delivering software, it’s hard to walk away or to believe that there is a need to change. But because of the speed requirements now that are on our businesses and our government organizations, we’ve got to start looking at different ways to deliver software.

It Starts at the Top

From a getting started standpoint, to me, it begins with organizational structure, a belief, first of all. A belief that we’ve got to improve the methods and the software that we’re producing and that requires accountability, it requires a commitment, it requires dedication to that objective and I think that begins at the top. I think that an initiative to modernize, to evolve, to transform, to transition your software delivery environment, begins with an executive sponsor, who can communicate the needs of the IT organization to executive leadership, executive management. And be able to find the value for the organization and to be that sponsor, to be that person that can make things happen at an executive level and provide the leadership that’s needed for the IT organization to drive this type of change. If it’s not coming as a directive from the top, then sometimes it’s hard to get people to change because we’re all uncomfortable with it at some level. So, having an executive sponsor, who is going to be responsible, at an executive level, for the effectiveness of software delivery within your organization, I think is critical.

Name a Product Owner

The next thing from an organizational standpoint is if you think about Agile software delivery and you think about Agile teams and their mission, they’re based on the fulfillment of new capabilities, features for a particular business product, what we’ve already expressed, that the software delivery system should be looked upon and managed as a business product, so if it’s going to be a full-fledged participating business product within the organization, it needs a product owner, someone who is responsible for the SDS, someone that’s going to be accountable for its effectiveness and its efficiency. And so, I think that those two positions are a great starting point. If an organization is serious about becoming better at delivering systems that are going to transform your organization, and give it the means to compete effectively in our world today.

Matt: Who might that product owner be? Who might it come from? A member of management, or one of the developers? Who does that role usually fall to?

Rick: I think it, typically, it’s going to be an IT resource. I think in most organizations that product owner is going to be mid-management to upper-management. It’s someone who has a deep understanding of the processes, have an understanding of the importance of software, someone who understands the relationship between the software being produced and the business, and the needs of the business. It’s got to be what I would consider a business resource who loves technology.

I think that those resources make great product owners because they’ve got to communicate. You think about what a product owner does in support of a typical business product. They’re responsible for making decisions about what work gets done with regard to that product. And so, the same would be true in a software delivery system: someone who can work with the needs of the business executives and make good decisions about the management of that software delivery system. So, what I’ve seen work real well are IT people with a strong, a good technical background, but also who have an understanding of the business and its needs. Again, that person is going to have the same role with regard to software delivery as another product owner would have to the management of those other business applications.

If you’re a manager, you’re a product owner a for retail banking system or retail banking product, you’re deeply involved in the decision making with regard to what gets worked on, what gets added, prioritizing the backlog of demand for that particular product. The same is absolutely true for the software delivery system.

Start With Focus

Matt: Okay, so once you have the organization set up where do you go from there?

I think the next thing is, when you’re beginning that evolutionary process, it’s one of the things that I tell folks is that if you’re making a significant difference and change in how you deliver software,  then leveraging an incremental method using Agile to implement that is key. And so, what I believe, what I have seen work, is starting, I don’t want to say small because I don’t want to create the wrong impression, but starting in a very focused manner in defining what that software delivery system is going look like at a team level.

And so what I like to do when helping people with this evolution is identifying a team, a project, that is going to give you the ability to build and tweak that software delivery system initially MVP (Minimum Viable Product) so that it’s operating effectively for that particular group. Now selecting that group is important. You want something that’s going to be representative of the organization. But I don’t believe… a lot of people think that you go find the hardest and the toughest to ensure that it’s going to support the needs of the work that has to be done. It’s my belief that it’s critical to start with something that’s going to give you some flexibility because you’re going to have some stops and starts with that software delivery system, and the use of it, especially if you’re making fairly dramatic changes, like for instance, moving from a 3270 green screen development environment to a more graphical environment, there are going to be some learnings that will need to occur. Now, some people are going to pick up with it and fly with it. People who are used to working in your target environment are going to move fast. But I think it’s important that you pick a product or an application or project that’s going to give you the opportunity to build a very viable software delivery system and give you the opportunity to make tweaks to that, changes to that software delivery system, without impacting the business.

The beauty of doing it this way is that you can stabilize, you can build that software delivery system and you can stabilize it and manage the growth or the deployment of that system to more people in the organization. And the more stable it is, the more effective it’s going to be, and the more likely that people will adopt and leverage it. And if we don’t produce a system, a set of processes and supporting technology to make it easier, to make it faster, for developers to do their work and then we’re fighting an uphill battle. And so, I believe finding the right project that will allow you to get your software delivery system as effective as possible is the right starting place.

Building the SDS Implementation Team

I think that another key in getting started is building that software delivery system implementation team. Now, what I mean by that, if you think about other business products there are Agile, there’s an Agile team or teams that are responsible for the maintenance, for the addition of these new features and capabilities for that product team, and typically there are dedicated resources to that particular product because they’ve got expertise with that particular business application or business product. There will also be other resources that you can draw upon, but there will be dedicated people who stay with that particular product because of their knowledge and because of their skills and their ability to make changes faster. Again, probably because of experience. With regard to the next activity once that team is developed, again, let me speak to that a little bit more. That team may be one, may be four or five people. And again, it’s a typical Agile team; it’s responsible for software delivery, initially the MVP and subsequently the capability and features that you want to add to that system over time. Getting started with that begins with an analysis from that team, from resources on that team, of the target state delivery architecture of that group that you’re focusing on initially.

Current State Analysis

Understanding the current state processes and tooling used to support that process is critical in defining your transition strategy or your transition plan to moving to your target state software delivery system architecture. So, current state analysis is very critical. One of the things that I’ve spent a lot of time in the last 15-20 years doing and gathering that information is leveraging value stream mapping as a technique to capture the information regarding existing processes. And just as importantly, capturing metrics to determine where the gaps are and where the initial target, or SDS, features and capabilities should be. If we’re looking at an existing process, and we see significant waste in a process or significant latency in moving from one process to another, that value stream mapping exercise will highlight those areas and then they become opportunities for features, capabilities, changes within that software delivery system. So, one of the things that I like to do is to start with a current state analysis, and I like to use value stream mapping as a way to capture that information.

Matt: Would this need to be done—we talk about iterative implementation, starting small—so, if you start with, say one team that’s working on one application. Would the SDS implementation team need to—probably there would be a lot of similarities. But they would probably need to go through this with each team?

Rick: That’s a great question, Matt. And yes, the answer is yes, because there will be, there will be differences from team to team. Now, in a very smooth-running organization, they will be minimal, but there will always be differences from team to team based on, number one, application architecture. The products or applications that one or multiple teams are supporting, the architecture may very well be different from the architecture of other applications. That architecture will dictate software delivery requirements within your SDS. And so, yeah, there should be some planning, or some investigation that occurs as you move from team to team. That’s actually another reason why the identification of that first team is so important because you want to select a product or a team that I think, as I said earlier, does a fairly good job of representing the organization as a whole.

And so, but yes, there is going to be some differences. If you think about a traditional business application, if you’re making changes to one part of it and you’re working with one team, their needs may be different from another team that is supporting another part of that sister or another component of that system. So, there are going to be some differences as you move from team to team.

Defining a Minimum Viable Product

Once you’ve got that information, then the first step and again you… It’s not like you’re beginning with an SDS product from scratch. You’ve got something to build on, you’ve got existing processes, you’ve got resources, you’ve got tools that are being leveraged. And so, when I talk about looking at that current state analysis, looking at your goals and objectives as an organization, or as a team, starting to formulate a plan with regards to what you want your software delivery system to look like, with the desired goal of X—probably improving velocity or improving efficiency for that software development—the identification of what’s release zero or release one going to look like? And it’s probably going to look a lot like, maybe some of the tools and processes that you have in place, maybe not. That will be a decision that you’ll make with that target team in determining what their needs are. But there will be in that initial release a minimum viable solution for the developers who are going to be using this new system to do their work.

So, defining, being able to assess the information to determine what that MVP is critical. Coming up with an MVP, just like coming up with an MVP for any other product is critical. Defining what what is critical to the needs of those developers is so important in that first step.

Now, the next thing that occurs is, once you define those things, actually building a plan that can be used to support the goals of that objective. And one of the things that I strongly believe in and have seen work is the use of Agile methods as a way to manage the work in building that software delivery system, building that MVP.

Agile Implementation

Matt: Ok, you have an MVP defined, you’ve got value stream mapping, you’ve got a plan. What are the next steps?

Rick: Now, once you’ve got a plan, and again, that plan if you think about an Agile plan, I’ll refer to the planning work that we do at Compuware—plans don’t go into infinity. We’ll put together a quarterly plan. And then I think… And I’m sure someone correct me if I’m wrong, on this, maybe two quarters out as far as backlog activities that we want to work on. And I believe the same techniques should be applied to the delivery of a software delivery system, and I think executing that plan becomes that next step. And again, I think Agile and an incremental method is the best way to implement or to build that software delivery system, if we believe that Agile is a better way to build software. And what are the key reasons we do that? In my mind, it’s to minimize rework.

If you think about traditional waterfall software development projects, there’s significant work that’s done, that may be associated with what I call misunderstood or mis-identified requirements or unidentified requirements. And so, we’ve got to be very careful about the work that we actually spend time on. In Agile, working in a shorter in increments, in time-blocked activities, typically over a two-week period of time, minimizes the amount of unnecessary work that is done. So, I think the same approach is very applicable to the implementation of your evolved software delivery system. Being able to put together a sprint or a set of sprints to do initial work. And again, that work is going to vary from organization to organization, sometimes from group to group within an organization. Starting points will be different. And so, with that understanding, conducting a planning session with that group and with the SDS team is absolutely critical.

We do the same thing, and most organizations do the same thing; they start a project, or set of sprints with a planning session to determine what work needs to be done and the priority of that work, along with understanding of the dependencies within that work to build out a sprint that’s providing the work that has to be done. Matt, I believe the same thing is true in building that SDS MVP and deploying that SDS. And then subsequently, the addition of new capabilities and new features.

But again, I want to get that MVP out to the hands of my users, the developers, and have them have it to be something that they can use but to learn as much as I can about its effectiveness and a great way to do that again is through incremental implementation. I’ve been on projects and quite honestly, a lot of organizations are still leveraging Waterfall techniques, to implement changes in technology, changes in process, and you try to do that across the entire organization at one time, and your chances of success at least in my experience, have been minimal.

So, starting at smaller and implementing the changes incrementally, I believe, gives an organization the best chances of success. All of us have heard in order to make these types of changes, within an organization, it needs to be built on incremental successes or small successes. Well, Agile gives you the ability to do just that. And so, I think that’s important from a work management standpoint.

Executing the Plan

And then there are other components of executing that plan that software delivery system should be treated, again, like any other application. And what I mean by that, from an execution standpoint, is that there’s installation work to be done maybe instead of software or code development work, but there’s installation work that may need to be done. There may be some coding that needs to occur, probably will, but that work, that installation, that code needs to be tested properly, just like you would test any other business application before you deploy that to its users. And so, I think it’s the responsibility of that SDS team to ensure that the SDS is working properly, works well—at least what they’re deploying at that time—and then manage it accordingly. So, you building test cases, building test plans for the SDS, I think, is a critical component because the last thing we want to do is to roll that software out and it’s not working as it’s intended. And so, making sure it works properly, making sure the components work together, is critical and then also training to make sure people understand how to leverage that.

And again, I think the key to doing that successfully is through smaller batches—incremental implementation. From a deployment standpoint, again, I don’t think it’s any different from any other application or system that you roll out to business users. As much as possible, we need to be looking at how we can automate that deployment to get it out as quickly as possible. And especially in an Agile world, where you’re going to be delivering new capabilities, new features as fast as the users can accept them, having an automated deployment system is critical.

Testing the System

And then one last thing with regards to this execution part of our discussion is having the ability to test that software delivery system. And quite honestly, if we can automate the testing of that system, those capabilities and features that developers are going to be using, the better. I think that in organizations that have really taken this to heart and are really being successful, they’ve got a dedicated software delivery system team that’s taking on changes from the vendors, they are automating the deployment of that code to a sandbox or to a test environment, and then they’re making sure that change or that new software works as intended, before deploying that to their software delivery system in a production state where your developers are going to be using it. So, the use of automation, I think, is just as important with regards to testing and deploying the software delivery system as it is in any other mission critical business applications.

Matt: That makes sense. Deploying the deployment, kind of.

Rick: Yeah, that’s exactly… You’re deploying the deployment technologies.

Measurement & Analysis

Matt: Right. So, once it is deployed, what does the upkeep look like? As you said, the plans don’t go to infinity. How can the product manager keep things going in the right direction and improve on the process as they go?

Rick: Yeah, and again, I hate to keep, as we say down south, beating a dead horse. But again, you’re using the same techniques and the same management principles that you would use in managing a retail banking system or a manufacturing system. In most organizations, especially today, I go into a lot of large financial institutions and the first thing they want to show me are the dashboards and the tools that they’re using to monitor their business applications and they’re wonderful and they provide the information needed to identify issues early. You see a lot of artificial intelligence in a lot of these systems now where they’re better able to predict where the problems might be. It’s that type of reporting, that type of information, that is critical to maximizing the efficiency of any software system.

And so, again, I think it’s just as applicable in the management of our software delivery systems. Understanding, as a software delivery system product owner, what’s critical, what’s important in maintaining effectiveness for your developers and your testers, your users of your software delivery system, in producing the code that they produce. And so, metrics like the mean time to resolution, mean time to delivery, average number stories per sprint, and there’s tons more, and they should be appropriate for your particular organization, your particular group—metrics that make sense for you. They should be business-oriented metrics.

I think it’s futile to measure things like lines of code and measurements that I’ve seen used in the past by organizations. Those things don’t mean anything. What organizations care about is the delivery of software to support business objectives and business goals effectively. And so we’ve got to start using, I think, what I would call business metrics that are important with regard to software delivery and typically those are centered around time and quality—velocity and the quality of work that’s being done. Having dashboards that can provide that information, where are our bottlenecks in our software delivery system, where are there potential problems, where are things getting stopped. Being able to see that information and react to it in a timely manner is critical to your success.

Managing the Backlog

And then there’s always going to be the process of managing the backlog. If you think again about another system, that product owner and people responsible for that product are always massaging, managing that backlog. Prioritizing stories and epics in that backlog to be able to most effectively support the needs of the business. The same thing has got to be true with the software delivery system. So, if there is a dedicated software delivery system team and a dedicated product owner and a dedicated executive sponsor who’s going to get you what you need in order to be successful, the management of that backlog becomes a critical part of managing the software delivery system. You’re constantly looking at a demand that’s coming in from the business to better address the needs that software provides. And so, managing that back log is critical.

Another important process or step in managing that SDS is using retrospectives. If your SDS team is executing sprints to deliver change or new features or new capabilities or removing technical debt, that’s in that software delivery system, the use of retrospectives on the process is used to deliver that work is just as important. And I think that all of this is about supporting or building a software delivery system or software delivery ecosystem that provides your organization, provides your SDS team, provides the users of software the ability to continuously get better. And without proper management of that SDS and without information, the proper information, that becomes a very hard thing to do.

The one thing that I do know over 40 years in this business is that it’s changing and it’s changing on a rapid pace, and so we need to be constantly evaluating the effectiveness of the work that we do, the effectiveness of the systems that support us in the work that we do, and to be able to make changes quickly to meet competition and to meet the needs of the business. And so, you want a management system and the information and the metrics that will allow you to continuously support the delivery of that SDS and give you the ability to continuously learn about how to make it better.

I think that managing the SDS is a critical step and we need tools, the same type of tools that other products, other business applications, and quite honestly, we work very hard in IT to produce those, that same type of information is just as viable in the work that we do as coders and testers.

Management Tools

Matt: What kind of tools can be used to help the product owner manage delivery effectiveness? Are there specific tools that will help and that will provide these metrics?

Rick: Matt, That’s a great question. There are lots of tools on the marketplace today to pull together information and to create these dashboards and gives you the ability to configure and define the metrics and the information that’s important to your organization. I think we’ve got one of the best that I’ve seen with regard to information about the software delivery system, in our zAdviser product and capabilities, and it’s free to our users and I think it’s just outstanding. It’s built on top of technology, dashboard technology that allows us to capture information from our clients with regard to that software delivery system. The beauty of it I think is the metrics, a lot of the metrics, are captured automatically—it’s not additional work placed on the developers or on management to produce those numbers, the numbers are actually captured through use of the products, and that’s amazing. And its ability to show how work is being done, where it’s being done, what capabilities and features within the SDS are being utilized, that’s very valuable information. So, there are lots of tools out there; zAdviser, I think, is just phenomenal.

Matt: Yeah, it was one of the first things I saw when I started at Compuware. I was really impressed… just the level of information.

Rick: Amazing technology. It grew out of our own needs in managing our and software delivery system.

Matt: Well, there’s, there’s been kind of a running theme here about iterative implementation. In that case, you’re going to have people working with different delivery systems at the same time. Overall, can an organization have multiple software delivery systems?

Rick: Yeah, they can… And what I tell folks is that there needs to be a core. And if you think about some of the major software applications out there, there are core components and then there are, there may be instances with variations in those instances to support the needs of the group that’s using it, and they may have specialized needs. So. what I encourage people to do is to architect that SDS, a common component to define what those common components are and then it should be architected in a way to where it can support the differences from user group to user group.

Matt: Well, I think this has been some great information for those looking to take the first steps on the journey toward modern efficient software delivery. So, Thanks Rick, for laying it out. Thank you to everyone listening.

Office Hour with Rick Slade will be taking this Friday, May 22, off. So, save your questions, listen to next week’s podcast, and bring all of your questions to the live Q&A session on May 29th. You can also submit questions via Twitter, using the hashtag #goodcoding, or send questions to Rick directly at [email protected] To listen to all of the podcasts and Q&A sessions in this series, visit So, Rick, thanks again, and I’ll talk to you next week.

Rick: Thank you, Matt. Man, it’s a blast. I love, as people who have worked with me in the past know, I love talking about this stuff. It’s something I’m very passionate about and I look forward to answering or addressing any questions you might have. So, please, take care. I appreciate the time, and good coding everybody.