Join AITSM Co-Op, A community for those who ♥️ AITSM (ITSM, ITIL, AI and Automation for ITSM)

The Evolution Of AITSM (Part-1) - How has technology progressed & What Changed? An Interesting Problem & My Toolkit To Resolve Anything?

April 5, 2022

The Evolution Of AITSM (Part-1) - How has technology progressed & What Changed? An Interesting Problem & My Toolkit To Resolve Anything?

AITSM Show - Episode 5 - Special Interview With Greg Specht

The Evolution Of AITSM(Part-1) 

How has technology progressed & What Changed?

An Interesting Problem & My Toolkit To Resolve Anything?

AITSM Show - Episode 5 - Special Interview With Greg Specht

The Evolution Of AITSM (Part-1) 

How has technology progressed & What Changed?

An Interesting Problem & My Toolkit To Resolve Anything? 

As we know, AITSM is ITSM-driven by intelligent automation to assist with tasks, requests, and actions at the IT service desk. Our guest Greg has over three and half decades of experience and watched the technology space grow exponentially.

We'd our pertinent questions like - How has technology progressed & What Changed? Any interesting problems those days and how they got resolved? Was there a relevant skill or toolkit which you use even today?

We asked it from Greg Specht, Sr. Director at DxSherpa Technologies. We'd learn a lot from him with plenty of reminiscences, laughs, and interesting anecdotes from his rich and diverse experience. 
Don't miss his toolkit to solve any problem. Check out an interesting problem he resolved in a crazy simple way, and he was featured in a blurb IBM did with educators across the country.
"It was just so funny, and one of those things where you tend to overthink, and then when you take a step back, you're like, the solution is quite simple. Right. So, sometimes we can overthink a lot of the things that we look at. I would say that keep things simple, right?"

Learn and Grow, With AITSM Show!!!


Anand Tambey: Welcome back to AITSM show. Today we have Greg Specht with us who is having more than three decades of experience. We'll be learning many things in this interview and we will be uncovering his experiences. So without much ado, I will start the interview and I will ask, Greg about how your journey had started and how you feel about the state of automation here.

Greg Specht: Thanks, Anand. Excited to be on and you know, talk about sort of the the progression of automation and the early years and the challenges that have brought us as an industry to this point as we have AI being introduced. Obviously the artificial intelligence really progressing exponentially. But it wasn't always like that in the early days. I'm excited to be here and I'm looking forward to the discussion.

Anand Tambey: Yes, we are lucky to have you on the show. So, yeah, please go on about your journey and experience with your early days and how it has progressed further.

Greg Specht: Yeah, absolutely. When I got started in college I went to Cleveland state university and my background was originally Mechanical engineer.

And one of the classes that we had to take was an engineering Fortran class. I don't know if you're familiar with that language. So everything was on a mainframe. Right. And we actually had a key punch room, so I'm seriously dating myself here, I mean, we had to schedule time to do key punch cards to write your programs. Things were, very much, very different back then than they are today, obviously.

As I progress forward as an Engineer a company called AutoCAD at a program and I was a terrible draftsman. So my, my handwriting wasn't, isn't the best. So I wasn't very good at drafting. So when AutoCAD came out, you could do everything on a computer.

And I think that's where it really got me started into IT was, you know, that initial part and as I progressed forward and got out of school I had a good friend of mine who was already a computer technician. Networking was, local area networking was becoming the buzzword. And so we actually started a consulting business and installed one of the first computer networks at Ohio state university. Sharing files and printers and things like that. It was hot technology. Being able to access the internet and that still was very much in its infancy.

One of the challenges that we saw was that when things would break or there were problems there's really no automated way to fix stuff. Right. Companies had people manning help desks people you would call in or you would have a pager, right?

 You'd wait for that thing to go off and then you drop everything and run to help the customer and even, remote taking over a PC or anything like that. None of that technology was really there. Everything was manual in-person. Drop everything. Run around like your hair's on fire and, try to fix something.

So it was so reactive back then, but there really wasn't anything else out there. But I think the discussions began to happen, what can we do to make things easier and be able to fix things. So I think the next progression that I remembered was being able remotely take over somebody's PC.

And even then, like I say that the technology you're using modems to be able to dial in. So the speeds, so slow that, it was very difficult to do those types of things. So technology began to progress from the old dial up modem days and that took some time.

But internally in, computer networks and local area networks companies were beginning to do some sort of self fixed type scenarios, run a command line, write a script and have it shut down a process on a computer. We're starting to progress. Probably not until the early nineties with the internet, with the bandwidth speeds and everything becoming better. Right. We began to see more remote capabilities and things like that, but a lot of the programs that we're doing, some of the self fix and automation started from internal type of a scenario.

Right. The whole concept of SaaS was not even, thought about. Everybody had their own internal help desk software, manually logging tickets, calling into the help desk saying this is what's wrong.

Finally when you could actually remote into that system, that was a big deal. Right. But you're always manually working in helping the end user.

Anand Tambey: True . So, that time even if you are maybe manually fixing, on site fixing, but what kind of automation you did back then?

Greg Specht: Well, it was pretty much writing scripts, either Perl scripts, batch scripts, right. You know, DOS command line type stuff.

If it was Unix Linux, you could write a Perl script to initiate a process. But a lot of times you had to manually kick it off. Right. So it's still there wasn't really the intelligence built in as of yet to automate that process. Even so those are big challenges within organizations and the IT departments were, for larger organizations, very large.

And because you needed a lot of people to care and feed things. You had people working third shift and mainframe departments, right. Having to feed backups and putting tapes in the backup devices and stuff like that. I mean, all those automated things don't work there.

So it's pretty exciting to see how we've progressed. Some of that brings in some additional complexity, it's just a natural progression of technology. We try to focus on ease of use, but sometimes even on the back end to build some of this stuff, it takes a lot of work. Right. So, we're starting to see low code, no code development and things like that. Right. I think that making things user friendly particularly to the end user, particularly to an individual who has no IT experience. But to build those things, it takes a lot of smart people to do that. So the need for the technology savvy people is always going to be there.

Anand Tambey: Right. So, when you have started and maybe after 10 to 15 years, which you can say maybe a mid of your experience. What things changed towards the service desks and automation in that?

Greg Specht: Well, like I say being able to do remote desktop connections , the automation technologies and there were software, for example, I worked with the CA technology, they had a product called spectrum, which was a network server monitoring tool. You began to leverage things like agents. You install agents on a computer and within that agent automation was built into it. So you could essentially remotely monitor a device, see what it was doing. Be able to understand if something did break, you could tell if this happens, initiate this, fix this, kill this process. So you began to build those things up front. And if things did break you kind of alleviated the manual processes. So you were able to be alerted that, this process went down. I tried to restart it. Maybe after three times, if it doesn't restart, okay.

Now, you know, you need to get involved and fix the issue. But even then, the whole concept of cloud, we're still in its infancy, right? You didn't have off premise type things. You still had to go into a data center to work on things.

There was back in the day, a company that I worked with called Exodus communications. Essentially it was a managed data center which was offsite. But in order to set things up, you still had to travel to that data center to touch the equipment, to see what was going on.

So That was sort of the infancy of the cloud platforms. So that's obviously changed over the years. You know luxury of, for example, an AWS where you can spin up server farms not even have to physically touch those things right. It's being done for you. So that has progressed quite a bit. Even networking now, you've Cisco ACI, which is basically software based, right?

So everything is changing you know, substantially over the years. So it's kind of exciting to see the industry go from where it was to where it is now.

Anand Tambey: Right. So what was the most exciting challenge, which you have resolved that time and it was maybe the highlight of your career at that time.

Greg Specht: Well, I've seen a lot, I guess, but I had an interesting scenario. It was probably in the, oh gosh, probably the early nineties. I had worked for a storefront.

The old franchise storefront shops that sold PCs and we were in the back of the storefronts. I was actually with a vendor that was a partner with IBM. And we installed a lot of networking labs in various universities. I was working with a vocational school and they came out with PCs that were essentially headless per se. Right. So they didn't have any, any sort of boot devices on them. They were all controlled through a server. So it was very similar to, like an old Unix type system where you had terminals, but they were PC. But they had a hard drive, but they didn't have a floppy drive or anything like that.

So they basically had a remote boot. We had an issue where the program we had, needed to look for a floppy disk drive and it was a bug. We couldn't get it. And these were hundreds of these things in this lab. We could not figure out how to get these things to come up. And I basically wrote a simple batch program.

It was literally one of those things where I was banging my head against the wall and late at night I'm in bed. And it was like, I woke up out of a dead sleep and ah, this is so simple to fix this problem. And wrote a real simple batch script to basically all the device that there was in "A:" drive on it.

And it was able put a partition on there, on the hard drive and call it "A:" drive and wrote the batch script to look for it. And it found it and everything booted up. And that fix, I was actually featured in a rag, basically a blurb that that IBM did with educators, all across the country.

So it was just such a simple little thing. It was just so funny, but you know it's one of those things where you tend to overthink and then when you take a step back, you're like, the solution to this is quite simple. Right. So sometimes we can overthink a lot of the things that we look at. I would say that was probably a very interesting scenario and like you say, keeping things simple, right? Yeah.

Anand Tambey: So as you resolve problems and excited about it, so what is the one toolkit or one skill you have, which is still with you and you use it throughout your experience to solve the problems or whatever.

Greg Specht: Well, I'll be honest with you. You know, I came from a networking technology background. So my experience in infrastructure monitoring, application performance monitoring. And my tool that is, still like a go-to tool to troubleshoot or look at things, is a "packet capture".

The way things flow on a wire really hasn't changed. Right. And so being able to troubleshoot things, and I think the challenge with cloud and things like that, is to analyze data across the wire. It can be challenging, but it's still a very effective way to understand what's going on.

So even on my home network, if there's issues or problems, I'm kind of a nerd. So I have the ability to do "packet captures" on my home router, to see if there's any kind of, intrusion detection and those types of things are still very relevant.

So I mean, "hack a capture technology". It works, right? What's being put on a wire is not changed and there may be some new protocols but the ability to look at what's really going on, has still been very effective over the years.

Anand Tambey: Thanks a lot. Greg. Thanks for being on our show. It was very insightful interview and lot of learning.

Lots of ideas from this discussion, really, Greg. We'll continue this discussion in the next episode too. So yes, we will do another episode of it. Thanks. Thanks a lot.

Greg Specht: Awesome. Well, thanks Anand. Thanks for having me.

Anand Tambey: So audience, if you love this conversation, please share it generously and give us feedback. What are the questions to be asked to our IT pros and we will keep coming with more and more interesting topics. Watch this space for more. Thanks. Bye-Bye!

Greg Specht Profile Photo

Greg Specht

Sr. Director, DxSherpa Technologies