IBM i DevOps TechTalk  – Automation #1

Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with our Arcad experts. Today’s topic is automation.
Hi everyone. My name is Ray Bernardi from ARCAD Software. I’ve been here for sixteen years. I’ve been in the application lifecycle management space for I think over 30 years now at this point in time. And I’ve got a couple of experts here with me today. I’ve got Jeff Tickner. Jeff, why don’t you say hello to everybody?

Jeff Tickner – Hi, I’m Jeff Tickner. I’ve been working in change management for over 25 years myself with a couple of different companies and I do implementation. So I’ve been kind of the hands on, implement and train on the development processes we set up.

R.B. – Thanks, Jeff. Also joining us today is Alan Ashley. Alan, why don’t you say hello and tell us why you’re here?

Alan Ashley – I am here as kind of the DevOps representative, the one that begins to show and tell part of this after a long career over at Big Blue.

R.B. – And you’re more into the testing area and things like that, are you not?

A.A. – Testing and anonymization and things like that, yes.

R.B. All right. Today’s discussion is going to be on automation, basically. So why don’t we get started? Jeff, why should I automate?

J.T. – So in my long experience, the change management, I’ve been doing automation every step of the way. In the old days, the promotion process was where we automated it with scripted or used exit points. And with ARCAD using these new tools like Jenkins and setting up pipelines, I see benefits and the opportunity to automate more because automation just makes your process more efficient and it makes it more consistent. You don’t skip over some steps in the process because you can always hit all of your marks there and you’re trying to reduce manual effort.

You know, life is tedious enough as it is. If I can automate those tedious parts, then it’s easier, right?

R.B. – Yes, for sure.

A.A. – And would you say in automation by you remove the human error?

J.T. – Yes. Consistency and removing human error as much as possible because everybody has a bad day where they’re tired and they missed a key and something else happens and they’re surprised in the steps in the process.

R.B. – So what are the benefits of automating?

J.T. – The things you get out of it is consistency and what surprises people. They think they’re going to get efficiency and things will go faster. And that’s true what you actually get in cool quality because things don’t get set up. You have a consistent process and hopefully one of the the next is fewer bugs because you’re consistently doing unit testing or other testing and so on.

But really the goal is to reduce manual effort so you have more time for coding. Coding can’t be automated like everything else around it.

A.A. – You know, Jeff, I always think of it as let automation do the stuff so that you can actually do your job right.

J.T. – And the interesting thing is you probably have some automation tools at your company and that are in use. So you can take advantage of those tools and there’s not a lot of overhead potentially. And so you get quick ROI. People don’t think that IBM i is open to automation tools, but I’ve learned working with Arcad and it really is. All these tools can be adapted.

There’s many ways you can take advantage of the tools that you’re already using at your company and using those existing tools gives you the best return on investment.

R.B. – So there’s no way that IBM i is an out-of-date platform then.

J.T. – Oh no. The perception is that or the mindset is out-of-date. But you can install Jenkins on IBM i. It’s a very open platform supports open source and is easy to integrate. It’s like Arcad. Arcad is also a very open and integrated set of tools for that same reason. So everybody has strengths and one of those strengths is openness.

R.B. – So where would I get started with automation?

J.T. – The best place to start is look at your current process. And my experience is working with new customers people may not even have a change management package, but they always have a development process that they’re following. And so we want to look at that development process and say, where is the high level of manual effort? So it’s not coding, unfortunately or fortunately, you can’t automate coding, but you can automate everything around that process and give yourself more time for coding.

So you want to see what’s the tedious task I’m doing right now. Is it managing the dependencies? Is it the unit testing? And so what we call this task that is tedious and takes a long time, it’s called a bottleneck and that term comes from value stream mapping. That’s a industry term, a buzzword, but it actually makes sense.

You look at your process, that’s your essential value stream and you’re seeing where the big investment in time is and then seeing how you can make that more efficient. And the answer is automation. But the important thing is not to get caught up in the automation. You also want to get the low hanging fruit. So I might identify the slowest task, but it might be the hardest to automate.

So again, back to the tools I’m already using, what are the guys and other platforms doing? You know, what tools do they already have? What expertise do I have in-house and how can I adapt that to my tasks on the IBM i side?

R.B. – So we’re basically identifying repetitive tasks and figuring out where the time is going.

J.T. – Yes, exactly.

A.A. – Well Ray, with that, the time and the money. Because that’s when you get into the value stream mapping and you start tying into some ROI down the road.

R.B. – This also opens up an opportunity to review your process, doesn’t it?

J.T. – Yes. It’s a great time to look at your process and maybe look at compliance requirements that are, everybody has to deal with some level of compliance. Some folks, some of our customers have a very high level of compliance requirements and they might be spending a lot of time complying with these requirements. Even the developer can meet those and they have nothing to do with development.

They’re just part of the business requirements. That’s a great place to look at. How can I bring those officially into the process and in turn make them consistent and as less work as possible.

R.B. – It almost sounded like you’re talking about doing this like one step at a time; hey, you don’t have to automate everything all at once. You can start with something small.

J.T. – Yes. That’s a really good point. You can automate a single step in the process. And, you know, Alan used the term DevOps, which is an accurate assessment of where we should be going. But people often think if I say DevOps, it means when I write my whole process out and replace the whole thing with something new and exotic which is not really required. It’d be nice to have that as a goal to get to because there’s a lot of benefits, but it’s not a requirement to start automating.

R.B. – You’re saying that you don’t even have to be using source control to do this?

J.T. – That’s a good point, Ray. No, you don’t. Source control definitely makes it easier to automate, but it requires a significant investment in time and training to do it well. So I have had some customers that have adopted source control just because and they essentially are using it because somebody told them that they have to. And when I’ve had customers also that use it effectively as a jumping off point but I won’t lie, adopting source control is not something that’s low hanging fruit.

R.B. – No, it’s definitely.

J.T. – A target for you in the future.

R.B. – You keep saying incremental. And so can you automate your entire process, though?

J.T. – You can. It just is a high level of investment and effort and you might not see the ROI at the end. And so often when we’re talking with new customers and what their goal is when they say we’d like to automate the whole thing and we tell them what the level of input required is going to be, they lose interest.

And so certainly you can and it’s an admirable goal, but because of the openness of these tools and how easily they integrate, you know the COIs, ARCAD’s COIs, a command line interface for all of its tools so it doesn’t have to have a dedicated plugin like we do have in for Jenkins. But if I’m going to use bamboo for a pipeline tool to automate my entire process, we don’t have a plugin for that.

We’re going to use a C a lot. It’s all possible. But I think stitching together a piece at a time and I can demonstrate the value of doing an automating that piece. But I can have a long term goal of automating the entire process. If I want to automate the entire process, I do want to get to source control because source control provides two values:

– Visibility because I’m tracking source changes at the line level, but it’s also another very open tool that integrates very tightly with other tools.

– Project management from the first requirement of the change to the deployment.

R.B. – So you’re basically identifying all the tasks around the coding and figuring out what you can automate.

J.T. – Yes, exactly. And not just because I’d say you can generally automate all of those tasks except for coding, but where is the logical place to start? What is the slowest task? What are the tools I’m already using that I can adapt to my IBM i development process? You know, if I just say I have to do it all, I’ll never get there.

R.B. – There. So to go after things like code quality and unit testing.

J.T. – Yes, absolutely. Those are a tedious things. And what you didn’t mention with Git code quality is the peer review process. It has a much better interface for peer review than what you’ll be using without Git. Yeah, and it can be automated further because ARCAD has a tool called codechecker that automates completely that peer review. But that can be an incremental step.

A.A. – And Jeff, as you said earlier, with some of the automation and taking out the human error. When you start getting into code quality and QA testing, you can automate. When you automate those, you take out that human error or being from a system admin, you never let developers test their own code because they know where the faults are.

Automation doesn’t know where the faults are in your code. When it gets to the code quality or the unit testing or the QA testing so it can help find more of those bugs and shift further left.

R.B. – Correction in the wrong way. I mean, it sounds to me like all this stuff can be orchestrated with other platforms and your deployment process.

J.T. – Yes, that’s another benefit of automation is synchronization. Most IBM i customers are supporting a more gooey interface of some kind web based their client server or something, and that’s often developing on another platform. That’s where those tools often are already in use. And it gives me an opportunity to synchronize with them. Because I should be testing my interface and my back-end together.

And when a change impacts both, they should be tested together and this gives me the opportunity of synchronizing that. So the theme, what I mentioned is one of the things I see that my customers do is they skip over the steps on a simple change. I’m changing a CO. Oh, what could go wrong? I don’t bother unit testing or regression testing or code review.

And it turns out that CO is called by a bunch of stuff. It actually is fairly important. And so a bug can be magnified because of the interdependence of our business applications.

R.B. – So I mean, it sounds like a lot, but it also sounds like what you’re saying is, I could actually automate fairly quickly.

J.T. – Yes. You know, that’s the thing. The mindset is I had to adopt SEM. I had to do all this I to have a pipeline and you don’t have to. You are going back to identify the bottleneck, the slowest part of the process, and then looking at your current tools? So for example, you could say my unit testing or my QA testing is the slowest part of my process.

I can look at my current promotion process. Does it have an exit point or is it script based? And I can go and automate that testing phase. So what happens consistently and quickly? I get to look at results. I don’t have to do the actual testing and there’s architect tools. There’s other open source tools on the IBM i platform for this kind of testing.

So you have a lot of opportunity there and you haven’t gone to the big tools like Jenkins. But you’re positioning yourself to do that later.

R.B. – So you’re basically attacking a problem area with tools like ARCAD i Unit, ARCAD CodeChecker, ARCAD verifier and going after that and taking these standalone tools and they’re going to become part of your automated process.

J.T. – Yes. You’re positioning yourself and you’re seeing a quick return on investment so that you can adjustify this effort to the corporate structure and say this is a worthwhile use of my time and I should continue. And now maybe you can say I can justify automating the whole process, adopting SEM because I’ve already seen the benefits of incremental automation.

R.B. – So I mean, it sounds like it’s going to be a little bit of work, so there better be some return on investment. I mean, or else nobody is going to do this. So exactly what is the ROI here?

J.T. – The ROI is going to depend on your process and where you’re spending time. And that’s why I say an incremental start where I can demonstrate the rely on a specific part, you know, the low hanging fruit with the least amount. Certainly I can adopt SEM and automate my whole process completely, but it’s a big upfront investment in time and money and it’s going to be a while before you can demonstrate ROI specifically at your organization.

We do have some information about our ROI that’s available for some of these processes for automating them, but it’s going to vary from organization to organization. So this is where a individual tool adopting, you know, I can do SEM and I can do my cool peer review with a pull request or I can get CodeChecker and just completely automate it and either in a standalone or even in a manual trigger and have that history and set myself up for that automation there. Even when you have a tool, people often want eyeballs on it and review it.

R.B. – Now you mentioned compliance earlier in this talk, So I mean that seems to me like it would be a good point to go after for immediate ROI.

J.T. – Yes. So things that you have no control over, everybody has some level of compliance requirements and some of our customers have really incredible compliance requirements and that gives you a return on investment both in the development process when you’re checking all the boxes and dotting all the i’s and crossing all the t’s. But what’s harder to identify but is significant is the ROI when it’s audit time.

So I work with our customers when they have auditors in the shop, when they need reports and to demonstrate things. And every auditor seems to be different in what makes them happy. But when you tell them it’s automated and it’s a consistent process, they look at one cycle, one object, one change, and say, if you can say it’s automated, it’s consistent. They normally will leave you alone.

R.B. – So it sounds like there’s significant ROI in this process. So you keep mentioning tools and tools. You keep saying tools. What kind of tools are out there to orchestrate?

J.T. – There are so many tools out there on the screen. You’ll see that the periodic table of tools that just many, many tools and I always say start with the tools that are in your shop. But I think we could spend a whole other session just talking about the tools and the integration between the IBM i, the native development process and those tools.

R.B. – So Alan, all these tools actually work on IBM i.

A.A – When you start looking at it, many of these are open source and they were developed open source, so they don’t speak IBM i and this is where ARCAD and our expertise for doing this for so long comes in. We kind of translate what’s happening between these open source tools like GitHub and bamboo and Jenkins and the IBM i. And we also have some standalone tools that fit into this pipeline, as we’ve mentioned before, like CodeChecker, i Unit and Verifier to help orchestrate the entire pipeline.

R.B. – I learned a lot. Let me go ahead and summarize a little bit here. I guess the first thing you should do to get started is to identify the worst parts of your process, all the way from coding to deployment to production, and then automate those portions, go after that, find the bottlenecks, use value stream mapping to help you do that.
That’s going to help you identify your pain points. It’s going to help you figure out which tools you need. It’s going to figure out how you can automate now and use that automation in the future as well. Automation won’t be the same for everyone. Figure out what’s right for you. The idea, though, is to be more consistent in your process.