Chapter 6: Source Control For Agile Software Delivery II (Migration) - Compuware - BMC

Chapter 6: Source Control For Agile Software Delivery II (Migration)

Chapter 6: Source Control For Agile Software Delivery II (Migration)

The Modern Mainframe ·
Send Us Feedback

Listen on Itunes

Listen to Stitcher

Matt: Greetings. Welcome to the latest installment of “Building a Better Software Delivery Platform.” I’m Matt DeLaere. Each week, Compuware Executive DevOps Solution Architect Rick Slade discusses a different aspect of the software delivery system and how you can leverage DevOps and Agile methodologies to create a world-class delivery system. We have a new podcast every Monday, followed by Office Hour with Rick Slade, a live online Q&A session each Friday. With that, let’s welcome Rick. Hey, Rick, how are you?

Rick: Hey, I’m good, Matt, how are you?

Matt: I’m good, thanks. Today is kind of a follow-up to last week’s discussion of source control for Agile delivery. In that episode Rick talked with Compuware Product Owner Mark Schettenhelm about the importance of the SCM in modern software delivery environments. This week, the Director of Compuware Migration Services Team Francois Dansereau joins us to discuss SCM migration. Welcome, Francois, thank you for joining us.

Francois: Thank you.

Matt: So, to start us off, Rick, can you give us a quick recap of why the SCM is so important to effective adoption of Agile?

Rick: That’s a critical piece, Matt, and I hope everyone had a chance to listen to Mark and I talk about that last week. You, if you think about a software control and configuration, it’s such a big part of so many of the steps within that software delivery life cycle. It’s involved from an assignment standpoint with regard to resources, to individuals, it’s part of the promotion process or a part of the branching process, or integral to that.

It’s part of the build effort, typically, today from a compile link/edit perspective, at least with regard to the mainframe, and then it’s a big part of the deployment effort. So, throughout that software delivery lifecycle, the SCM is playing multiple roles and it’s so critical. So, I was glad to have Mark on to talk about that and to talk about its support of frameworks and disciplines like continuous integration. So, important piece, that’s why I thought it was really important to have Francois on this week to discuss and talk about migrating from traditional legacy SCMs.

Matt: Great. So, you’ve worked with SCM migrations in the past, can you go into that a little bit?

Rick: I mean, they’re difficult—or at least they can be difficult. And what I was amazed at, when I joined Compuware, was the work that Francois and his team had put into not just the migration effort itself, but the entire process of determining what needs to happen, providing an order, providing a methodology, and then providing technology and tools to automate a lot of the work that has to be done.

And so, the work that he’s done has been incredible and I’m sure he’ll talk about that. But when I was at IBM, it was a big part of any transition effort and stopped a lot of organizations from moving because we didn’t have the resources available to us at that time to help with the migration. So, seeing the work that Francois did for a Compuware was quite helpful and very useful for our clients.

So, with that, I’d like people to hear Francois, so I’ll introduce him. Francois was in one of the first meetings when I joined Compuware and he and I both have, I learned in that meeting, that he and I both have this love affair with mind maps. It’s just, for me, it’s always been a useful tool in understanding process, and defining work that needs to be done and actually building frameworks and methodologies, processes for just about any type of work.

And of the things that Francois did an amazing job was, he had mind mapped his process for migrations, and so that was my first introduction to Francois. Really impressive stuff. So, when we started talking about things that we wanted to discuss with regard to modernizing a software delivery environment, migration is such a critical part of that, I was very happy when Francois said he would be able to do that.

Francois, I want to get us started by asking you some questions or having you maybe provide more introduction about yourself, also to understand how you got started in SCM migration and to tell us a little bit about your team

Francois: Again, it’s an honor for me to be with you this afternoon so thanks to you, Rick and Matt. This great for me to be there. To answer your question, Rick, the first SCM migration project that was done, it was in 1994. So, we’re talking about 26 years now that we’re doing SCM migrations. Since then, I’ve trained new members to join the migration team. We’ve done, we’ve accomplished over 300 migration projects to give you a round number. Mostly North America, and also in Europe.

I’m very lucky, I’m very fortunate that I’m still working with the same team members since the beginning. So, this is a key part for us to be successful, to keep the expertise within the team. And we were involved with all most the popular SCM legacy applications on the market. I’m talking about Broadcom CA Endevor, Broadcom CA Librarian, Broadcom CA Panvalet, ChangeMan solution from Micro Focus, LCM from ASG, IBM SCLM, IBM Rational and, of course, ISPW.

So, with the team, we bring the expertise, to, as you mentioned, to reduce the risk of the migration. As you know, they are huge projects. And for sure to enable the best practices—here, I am talking about the Agile development—to me, this is a key thing, a key objective while performing those type of migrations. Different types of CI/CD integrations and to bring new modern solutions like new IDEs, like Topaz, in this case.

Rick: It’s amazing stuff, and I’ve met a lot of your team members and they’re just incredible folks. A lot of experience, a lot of knowledge, a lot of good practical common sense in that group, and I’ve heard wonderful things about the work that they’ve done.

I’d like to ask you a little bit about—initially, I was going to ask you about tools right now, but I want to switch gears a little bit—and I want to ask about methodology, because I think that’s so important. To me, process is key with regard to any type of major initiation or transformation effort, and that includes the migration part of it. Is there a methodology? I know there’s methodology you use, but can you tell us a little bit about the methodology that you guys leverage to help your customers with their migration effort?

Francois: Yes, for sure. As you said, when you talk about mind map, yes, yes, yes, we have a methodology. Actually, I can talk about it for the remaining of the day, there is so much information. The purpose of this migration methodology is to make sure that everyone, every team member, is following the same step-by-step activities while doing the migration.

With this, I’m sure that every project will be done the same, with the same pattern, the same deliverable. So. this will guarantee to me, and enhance the quality of the projects, of the migration projects, and it brings, the methodology brings out-of-the-box templates for documentation, templates for skeletons, utilities, everything that we’ve developed while performing those projects.

The Five Gates

As you know, Rick, we’ve never done two SCM migrations that look the same. Everybody is different, there’s always new things. I’m surprised that over the 300 projects that we’ve done, that there’s no two projects that look the same. Talking again with this methodology, we’re using the gates idea. We have five different gates.

Gate 1: Assessment

The first gate is assessment. The assessment, this is where we sit down with the client and try to understand their current SCM solution. So, this is spread over a few weeks—one, two, or three weeks at the most­—and this is where we are not touching the keyboard, we are just there to have different meetings with different key players at the client site, and we want to know more about their current SCM solution. So, we want to know about their current application lifecycles, the translation parameters, the dataset naming convention, how they are performing emergency fixes,

we want to know about the application requirements. So, this is all security. There’s a bunch of things that we need to understand the deployment and all this to be effective and do a good project.

Rick: I was just going to say, I go through a similar process in helping organizations with their DevOps transformation. You’ve got to get a good understanding of their current state environment along with the goals and objectives that they’re trying to accomplish. And all of that information becomes critical as you move into the next step.

Francois: Yeah, exactly, so the worst thing that you can do it to start a migration without any assessment. Starting just to build something or do something without knowing what’s going on right now. So, this to me is, is the worst, this is a perfect recipe for failure.

Gate 2: Design & Architecture

So, after the assessment, which is gate one, we are going to gate two. Gate two is the design and architecture portion of this project. Again, with about the same people, the same application leader, security DBAs, SCM administrators, those are the main key players from the client side. We are talking about the blueprint of the future SCM environment. So, this is the section that, first of all, will be our first deliverable, that will be a solution document that reflect the blueprint of the implementation of ISPW.

So, we are going to talk about the best practices, we’re going to talk about, maybe we’re going to change the application lifecycles, maybe we can enable things to make the new SCM solution to provide more… an Agile framework for people. We’re going to talk about the integrations with any service desk solution, all the CI/CD integration that will be needed. So, this is the… maybe a new data set naming convention for the ISPW managed data sets.

So, this is the best time to put in place the things that they don’t have to do, that you would like to see with your new SCM solution. So, this is the gate number two, and this is our first deliverable, so this is the bible of how we’re going to do the implementation of ISPW.

Rick: It’s like a blueprint for building a house.

Gate 3: Solution Development

Francois: Exactly, this is exactly the same. The assessment is that I want to find a taste of my client, in gate two want to do the blueprint and gate three is the solution development. There’s two major activities in gate three on the solution development. There is the implementation of ISPW from the blueprint, from the design document that we created in gate two, and there’s the validation. The validation is the pilot team that’s going to be trained that will go through use cases, over a pilot application that will be migrated under a testing mindset of ISPW and they’re going to go through those use cases to make sure that they’re going to check the box. to make sure that everything is working as design, that there’s no surprises that we put in place or that we meet all the requirements, that everything is working. So, they will validate the promotion, the parms, the regressions, approval, concurrent development, any integrations. So, all this needs to be part of the use case.

Rick: Francois, are there any characteristics of an application or pilot team that you believe are important or provide the customer with the best chance of success for implementation? Are there key characteristics that you look for in that pilot team of that pilot application?

Francois: Yes, for sure, Rick, we do. Because the idea is not to tell the volume of activities is too—I don’t know this is the right word—I was talking about flavors. On the pilot, on the validation, you want to test every flavor of the things that you have to do at your site. So, we need to test if you’re running COBOL, Assembler, PL/I, so we need to test all those—if they are batch, batch online, with DB2, without DB2. So, all of this, the CICS you copy is the ability to bind. So, it’s not a matter to trigger 2000 binds, it’s to make sure that we’re going to test some of those and see if the outcome is good. So, this is the idea. The pilot can be a small application or it can be subsets of different applications altogether just to make sure, again, that we’re going to test out the different flavors. There doesn’t have to be a single application. Again, it can be a subset of one application, a full application, or maybe subsets of different applications.

And usually, Rick, we’re talking about 10 to 15 people that are part of the pilot team and over the 3-4 weeks of work, part-time—they are not fully dedicated to this, because they have other projects to do at the same time—they’re going to go, they’re going to make sure, they’re going to go through the use cases and they will document all the results and make sure that at the end that we have the “go” order.

Gate 4: Migration

So, this is the gate three, which is the solution development. After that. If this is a go, if we have the “go” to proceed to the next gate, which is gate four, this is where we will perform the real migration. The real migration is that we need to come up again, together, the client and my team, we need to build the production migration plan. Because there’s many ways to perform gate number four, we can do the big bang, we can go by groups of applications, we can go one application after the other. So, there’s different ways to be able to perform the real production cutover and there’s a lot of things that need to be taken into consideration, like if you have any date constraints, if you have any huge projects going on. So, if there’s a huge project with application ABC, you don’t want to do the production cutover before the delivery of that project, so you want to do it after the project will be done for the application ABC.

Rick: That’s always an issue. It’s always difficult to manage because you’ve got projects that are occurring at the same time that the migration is typically occurring and managing that can be difficult, but I know you guys can do a good job of that.

Francois: Yeah, so again, this is a team effort to define how… Because in gate number four, the production migration, you need to take care of the training because this is the right time to train all the people. You don’t want to train them three months in advance because they will, because they’re going to forget everything about is ISPW? So, you need to make sure that they’re going to be trained at the right time. You need to publish that migration production plan. Make sure that everybody knows about the freeze because we’re going to have to freeze the application for X number of days… 2, 3, 4 days. So, all of this needs to be very well-published and understood by… don’t forget we’re touching everybody within the IT department, almost. Every application leader, programmers, production control, everybody’s going to be impacted by this project. It is very critical that everything is well-documented and well-communicated to everyone within the company.

Matt: As an outsider, and especially I’m looking at the assessment phase, obviously, things have changed over the past couple of months, but in general, how much, if any of this is done by your team on-site and how much is done remotely with the clients?

Francois: That’s a good question. For just the current situation that we’re living. Usually, typically, Matt, the way I wanted to do the project, was the assessment, it was always done on-site. The reason why I was aiming for that is that you have a face-to-face with your client; you make a better relationship when you have a face-to-face with people.

But now, because of this Corona virus situation, we’re doing everything remotely. So, we just started a couple of projects since March. We’ve started few huge projects within Compuware and everything is being done, as you know, through WebEx. The thing is that what we used to do in like half-a-day meetings at the client site now, we cannot do a four-hour WebEx meeting, this is too long. After an hour and a half or two hours, to me, this is the most we can go within WebEx. So, we have to trigger more meetings, shorter meetings, but that’s the way. And so far, so good. I prefer to be on site, between you and me, but this is the new reality. So, this is what we have to deal with.

Gate 5: Post-Migration

Rick: Francois, so you’ve talked about four gates. How do you wrap these projects up? I assume that fifth gate is completion?

Francois: Do you think you can work with us, Rick? So, this is the… we call this the post-migration gate. This is usually, typically this is a short gate, too. This is a bit like the assessment, where we will support the client. Is there any questions?  If there is documentation missing, if there is a knowledge transfer that is missing….

Because something that I didn’t talk about through the whole project, there’s different types of trainings. There’s the administration training of ISPW. The new ISPW administrator will be part of the migration team, so this is an ongoing training for that person. So, this is from the first to the end of the project, this person will be trained on the administration of ISPW. The idea is that we want to make sure that at the end, the administration can be performed and they know how to perform tasks within ISPW. So, this is the first type of training. The second type of training that we deliver is for the pilot team. This is a one-day session where we train people on ISPW for the pilot team and finally there’s going to be x number of training sessions for the rest, the remaining, all of the programmers of the company. So, this is… But on the post-migration, if there’s still knowledge transfer that has been needed, this is where we’re going to do it. And if there’s a step that can be improved, or things that may be something popping up since we are in production, and nobody mentioned about some special things, this is where we’re going to fix or tweak what is needed to make it a perfect world. So, this is the fifth gate.

But the whole idea, Rick and Matt, about the methodology, there’s two goals for me, the two objectives. The first one is, as I mentioned, are to make sure that it’s a tool for the team to make sure that we are following the same recipe, the same step-by-step all the time and then all the templates or new things that we, that we develop from project to project will be included within the methodology. So, this is the main goal.

But the other one that I like it very much, it’s when on pre-sales when I’m involved, through WebEx, because all the clients are very concerned about the migration projects. And when I go over it, just like I’m doing right now, but through WebEx, when I’m going over the methodology, the confidence level of our clients is being raised big-time. They like it very much. They can feel, they can see that we know what we’re talking about, that we’ve done it many, many times. And I like to see that there is almost an answer to every question that they might have during the WebEx. This is, to me, a huge confidence factor for the sales force to help close the deal and to decrease the sales cycle. This is a great tool.

Rick: And it shows, Francois. The feedback from clients after you guys have gone in there is always phenomenal. You guys do such a good work. You can tell that there’s a lot of effort has been put into the developing and continuous refinement of this process. It’s really phenomenal. One of the things that interests me with regard to this process, is some of the automation, some of the tooling that you guys leverage to support this methodology. Can you talk a few minutes about that tooling and what it does for you and its advantage or its benefit to our customers?

Francois: Yes, for sure. The first tool that we have, that we use for the SCM migration projects, it’s the discovery tool. This is to help scoping the projects. This is a REXX program and the GCL that we send to the customers site. That will provide… the information provided by the discovery tool, they are used to better understand the magnitude of the migration and to help me to generate a statement of work. There’s maybe meetings or information that I’m going to need to make sure that I have a good understanding or a full picture of their current SCM solution. But typically, this is what the migration discovery tools will provide to me. It’s to size the project and to be able to put a number of days that will be required by my team to perform the project. So, this is the first set of tools that we have.

The other set of tools that we have, this is the one from the migration factory, and this is to me those migration tools are to help us to perform the migration of the pilot application within gate number three for the migration and to finally do the real migration in gate four. So, this is the art of the migration factory. The migration tools that we have, they are mostly written in REXX, so it is very easy to update or to maintain.

And the beauty about those migration tools, is that there’s a bunch of configuration modules in there, because, as I said before, we never did two migrations that looked the same. So, there’s always a bunch of things that need to be mapped from their current SCM solution. If there’s a bunch of options from ChangeMan, or processor groups within Endevor, and there’s all kind of stuff that we need to make sure that we will be able to retrieve that information from their current SCM solution and provide the right information within ISPW.

So, this is a part, this is part of the solution development, to adjust the migration, to configure the migration, to fulfill. And this is information that is coming out from the design document that we’ve done in gat two, to make sure that… I like to call this the sausage machine—when you’re going to hit the button, it’s going to extract out information. So, all of the metadata, Rick and Matt, of the ChangeMan or Endevor of the current solution, all the meta data will be extracted using the migration tool and be exported to the ISPW solution within the proper DB2 tables.

So, all this is being automated, so there’s no way we’re going to be able to perform projects with the manual process. So, all the historical information to all the back levels, the minus one, minus two, minus XX will be exported from the current SCM solution to ISPW with the proper parms, all the information, so we are not losing any auditing information. You’re still going to be able to know who’s done what and when—all of that information will be saved within the ISPW repository.

Rick: So, Francois, it’s amazing what you guys have done and the tooling that you used to support this activity is incredible. There’s no way that organizations could get through this migration as quickly and as cleanly as you’re able to do that for them, without it. So, congratulations on just a well thought-out process and good tools to make that migration as easy as possible.

I see we are about out of time. Francois, any closing comments regarding migration?

Francois: Yes, I think that every client, they think that they are unique, that their current solution is very custom, is very complicated. But I hope that I gave you enough information about our migration factory just to tell you that so far, we’ve been successful on every migration project where we were involved. And over the years, we’ve developed better and better migration factory infrastructure, that includes all the objectives that we said before: to assess our client, to achieve new objectives, and transforming their processes and procedures, to reduce the customization efforts and improve deployment delays, to increase the confidence level with these new technologies and to, just to wrap up, to freshly debut rapid adoption and implementation of best practices through this new ISPW SCM solution.

Rick: You guys do an incredible job and I certainly appreciate it and I appreciate you spending time with us today to talk about this migration effort, because it is so important, it’s critical. Most organizations, especially on the mainframe side, are still leveraging SCM technology that was wonderful at one point in time, but it was built to support traditional waterfall management techniques.

Yeah, and so moving to this modern DevOps agile world, organizations are needing the capabilities of a modern SCM to support methods like continuous integration/continuous delivery and the ability to take their existing assets and move them into a modern repository will provide them the tooling necessary to support Agile software development on the mainframe. So, we appreciate your time very much, this has been incredible. I’ve got to have you on again, at some point in time. Get deeper into this stuff. It’s good stuff.

Francois: No problem.

Rick: I appreciate it.

Matt: Thanks, Rick, that was a very interesting conversation and I’m sure there are many more questions that we could ask, and Francois could answer. And thank you, Francois, for joining us. Thank you also to everyone listening. If you have any questions about SCM migration, please join us this Friday at 11 AM, Eastern Daylight Time for Office Hour with Rick Slade. That’s our live online session where Rick answers your questions. You can set a reminder for yourself at, and where there you can also listen to all the episodes in the series watch past office hours with Rick Slade, see what’s coming up… You can also submit questions on Twitter using the hashtag #goodcoding. That’s one word. So, with all that taken care of, Rick, I’ll leave the last word to you.

Rick: I appreciate it, Matt, and thanks again, Francois, great, great 30 minutes, I appreciate this. I’ve got to have you on, I need to have you on during the live Q&A, too. We’ll talk about that. This has been great.

Folks, I hope you’ll join us Friday for the live Q&A, where you can ask questions, as Matt indicated, about the migration or any other topics around building a modern software a delivery environment. We appreciate your time today, we appreciate you downloading this podcast, and I hope to see soon. Take care, everyone, have a good week, and good coding, everybody.