In this edition of "The Subnet," we catch up with Michael J. Kerkau, the network infrastructure manager for North America at ABB Ltd., an engineering, manufacturing and robotics company headquartered in Switzerland.
Kerkau runs network operations for the company's 30,000 users in the United States and Canada. And when they complain an application is lagging because the network is slow, it's up to Kerkau to identify the real culprit.
What are you working on these days?
ABB is going through a state of constant expansion. We're very aggressive in acquiring businesses that can help the overall delivery of products and services to our customers around the world. As part of that growth, we're faced with integrating diverse networks into the ABB corporate network. In a lot of cases, that's not a full integration; it's a matter of just making these different networks work together so users in each environment can reach the resources they require.
I also find we're using a lot of time to help with application performance management, working with Riverbed's SteelCentral platform. It used to be, with older technologies, that a user would point at their own machine or they would point at the server and say, 'There must be a problem on the server.' Nowadays the knee-jerk reaction to any issues where performance is less than optimal, or less than the user expects, is typically to say there's a network problem. As a result, I get the call on most any application performance problem. So a lot of my time now is spent figuring out just exactly what part of the application performance is not working up to snuff.
In today's world, we've got much more robust network connections than we did back when people were still using dial-up. It used to be a proper diagnosis oftentimes to say that it was the network because there were so many different variables tied into it. Nowadays it is less often the network and more often something else that's getting in the way of the performance, such as limitations on the servers or even limitations in the applications.
What do you mean by limitations in the applications?
There are a lot of cases where we have to reinvent the wheel to make our products work with an environment that has technology involved. As a result, we've got a lot of homegrown applications, and some of them have pretty good age on them. We build power distribution units and power transformers that are put into a neighborhood, shopping center or hospital, and they're expected to run for the next quarter-century to a half-century essentially untouched.
We need to maintain some of the applications [supporting these devices] that are long since outdated, and they might run better on a newer applications platform, but transitioning a device that was created 15 years ago to new technology today is a daunting undertaking. As a result, we maintain these applications that weren't necessarily designed to run on the infrastructure we have now. For instance, some of our applications, we've learned, had delays designed into their procedures to compensate for the fact that there might be a delay at the server. The [original] servers weren't fast enough to return the right data that's necessary for the next step in the program. And now when people are expecting point-and-click and the new page arrives, these applications aren't doing that. So again, it's initially diagnosed as a network problem, and then the more that we dig into it, we realize it's a matter of making these old applications work in the new environment.
Do you have a background in software or any skills that help you diagnose these issues?
No, I'm not at all trained in applications. My actual professional expertise is in support of client systems more than anything else. Matter of fact, the network role that I fill now was supposed to be a three-month, just-kind-of-man-the-store thing until they replaced the role with someone who was trained in networks. I'm not even trained in networks, so I've just picked things up along the way -- mostly with troubleshooting.
Michael J. Kerkaunetwork infrastructure manager, ABB Ltd.
Wow. So how long have you been in this role?
I'm starting my third year.
So much for the "man the store."
Yes, exactly. I turned into the de facto network guy, but I definitely lean on the other resources. I am the network management team for North America. My team is basically augmented as necessary, depending on whatever the contingency is that we face, but it's essentially me. I'm the Bat Phone guy, I guess you would say, for networks.
Can you talk more about the Riverbed products you're using?
My company started working with what's now Riverbed Professional Management Services when they were OPNET, before they were acquired by Riverbed. We initially brought them in because we were moving a data center from Windsor, Connecticut, to the Raleigh, North Carolina, IBM data centers. We needed to know during the transition what the performance of these applications was in the new structure and how it differed from their original performance in the Windsor data center. Once we got the transition done, we used OPNET to create a response service basically for when [performance] issues come up.
We also use Riverbed's SteelCentral Transaction Analyzer to put an agent on a client [if a user] is complaining about performance, and that agent can actually track the transactions of an application from the point that the client enters data and clicks send through the network to the server.
We are also trying to implement some dashboards, which we really haven't been successful with yet. It also hasn't been our primary focus because we're consistently working on these applications performance issues. But the value for us would be the ability to, in a small set of screens using a Web interface, identify whether or not the applications are performing as they had been historically.
Why has that been difficult to set up?
It's primarily a matter of setting priorities. We just haven't been able to focus hard enough, long enough to get it up and running. But part of it is also technical. For instance, one of the limitations we ran into in getting the dashboard to give us accurate feedback is … because in North America we have about 900 subnets. And the way that the dashboard application works, apparently, that's a lot of data to churn through on a regular basis in order to present data that's meaningful.
Your company does a lot of heavy-duty engineering work. What does that mean for the network?
We've got over a 100 sites in the U.S. and Canada alone. They share engineering data on a constant basis, and 3-D CAD has actually been a real challenge for us. For instance, if someone from one of our parts providers makes a change to their component, that might have ramifications -- not just physical changes that would [require us] to redesign some components to fit around them, but it might also change voltage or something else of a very discrete nature.
The component manufacturer would go into a 3-D CAD drawing and make their changes. What would typically happen is that then the teams in charge of those components would be alerted to the change. Then they would have to go into the same 3-D design and make their changes, and it could be a snowball effect that touches another set of components and they need to change. All of this is tied into these enormous, multiple-gigabyte-sized 3-D drawings.
So it's not just the challenge of getting a large 3-D drawing passed all around North America, but it's also a matter of having these multiple people working on these different components and sometimes simultaneously. And that's a challenge frankly we don't quite have our head around.
Here's one thing we always ask: How did you wind up in IT?
I started in the United States Marine Corps. I was trained in special intelligence -- not at all technical. Actually, my primary job was Morse code collection and intelligence analysis. I spent about seven years in that field for the Marine Corps, and after active duty went into the reserves. This would have been around '98 or '99, and they didn't have a requirement for special intelligence and asked if I would be willing to retrain. I was, and there was a demand at the time for IT professionals.
I was retrained, and then Y2K came up. At the time, I was a sergeant in the Marines -- the equivalent of a middle manager -- and I was brought into the role of help desk manager. I was in charge of the transition for Y2K for one of the major commands in North America. I was later hired as a temporary employee at ABB in 2000 as a help desk technician.
Because of my computer knowledge as well as my intelligence background, I started working with internal investigations to support their efforts from a computer standpoint, which was a component to investigations that they never really had before and never attempted. While I was working with the investigators at ABB, I explained to them that I could be a lot more effective if we had a computer forensics discipline in the company. I helped to set the groundwork, and we created a special investigations computer forensics unit. It was the first one ABB ever had, and I came back to ABB to man that office.
That office still continues, and it's expanded quite a bit. But then I was brought back into the North American IS management team as a projects manager, as an incident response manager and as a division service manager. And then, as I mentioned, we had a vacancy in network management, so they brought me in just to fill the void for a couple of months, and it's turned into my primary role.
Final question. The category is music. What is the last concert you went to?
It was a band from St. Johns, Newfoundland and Labrador, named Great Big Sea. They're kind of a rock and Celtic band. There are several bands doing that now, but they were probably the big show in town back then. It's been a few years, actually. I don't tend to get to a lot of concerts, but they were awesome. The band has since disbanded, but it was fantastic music. It was a heck of a show.
Cisco broadens its portfolio with AppDynamics acquisition