Ever wonder about what the various mainframe job roles are? Not sure whom to ask? Well, look no further — this new video series brings in professionals to tell you all about their mainframe jobs, what brought them to mainframes, what they love about it, and more!
In this video, we chat with Gary McAfee, a Software Architect at IBM.
What is a Software Architect?
Gary: An architect is a person who produces high-level designs that implement new features for a product, primarily. And those high-level designs are fed into a development and a test team for implementation. Even after those implementations are delivered to customers, the architect is oftentimes involved in discussing those features with the customers and dealing with any potential questions or problems.
How did you come to be an architect in a mainframe space?
Gary: When I came out of college, mainframes were about the only platform available. There were such things called “mini computers,” but most of the business was being done on mainframe computers. So, I began my career in the mainframe area and decided to stay in the mainframe area. I gained a lot of experience throughout my career here at IBM working on mainframes, and experience is something that is needed in the architecture role. I also find that the mainframe environment is challenging and I always look forward to challenges. I stuck with the mainframe area and kind of grew into the architecture role.
What do you like most about your job?
Gary: Architects are involved with creating high-level designs and that takes a lot of creativity. There are multiple ways to attack the problems and some of them are better than others. You kind of have to think of and dream up these various different scenarios that might solve the issue that you’re trying to tackle. And finally, once the solution is delivered to customers, it’s very satisfying to see customers that are delighted with the solution that you’ve worked so hard on along with the development and test teams. So, I enjoy both the creativity and making customers happy.
What skills do you need to become a mainframe architect?
Gary: I’ll be honest, most people aren’t going to just walk right into an architecture role. Typically, architects need a lot of experience in the field that they’re working in. So, experience is primarily job number one. Coding is helpful, but I wouldn’t say it’s necessary. Communication skills are important — architects spend a lot of time talking with customers to find out what their pain points are, what their wants and desires from your product are. We spend a lot of time in meetings with subject matter experts in our area and other architects. And just general knowledge of the ecosystem that you’re working in — the software that interacts with your product, the hardware or the platform that you’re working on.
What does a typical day look like for a software architect?
Gary: Well, as in most job roles there really isn’t a typical day for an architect. But, there are some of the things that we go through pretty much on a daily basis because we’re working on high-level designs. There’s a lot of research that involves a lot of technical reading and discussions with subject matter experts. We do have meetings and phone calls with customers to understand what their pain points are, wants and desires for your product, and discussions with other architects to see how your proposed solution is going to work out with their areas and leverage their experience. Then, maybe this is kind of funny, but when we’re using high-level designs or coming up with high-level designs, PowerPoint is our best friend. We spend a lot of time working with our high-level designs and PowerPoint.
Developers like to talk about languages and tools. What do architects like to talk about?
Gary: Architects like to talk about several different things. One of them that gets a lot of our time and attention is customer requirements. Those are things that our customers have contacted us about saying “Hey, we would really like a new feature that does this” or “Hey, we’re having a problem using this, can you improve upon this?” So, we get a list of those things and we have to rank them and prioritize them, and use that list to decide which ones we’re going to work on in upcoming releases. We get together and talk about it, and rank, and discuss those things, and talk about which ones might give us and our customers the biggest bang for the buck. We do talk a lot about new technologies, of course. We have to balance implementing new technologies with these customer requirements. They’re not one in the same thing. We have to have a mixture of both of those. So, we constantly evaluate new technologies that are popping up, and evaluate whether they relate to our product, and if they do, how we might at a very high level involve that technology in our product. And, maybe surprisingly enough, we do a lot of customer presentations and we talk about planning for those. We talk to customers about how to use our new features and functions, and we go to conferences to discuss those with our customers and explain them.
Can you recommend any specific educational materials or courses for mainframe architects?
Gary: There is a program that IBM has called “Master the Mainframe.” I would say that’s a very good place to get a foothold on mainframes in general. But, most people aren’t going to start off as an architect in the mainframe area on day one. Experience is the best education you can have to become an architect. Sometimes, in certain areas, that’s going to take many years of experience on a product area either developing, or testing, or servicing customer issues.
Do you use any specific architect tools or methodologies to do your job?
Gary: Architects are big players with the agile methodology that includes doing playbacks and having sponsor users. When we begin working on a design, once we’ve gotten to a point where we think we have a direction figured out, we do a playback to a broader audience. Those are stakeholders that will be potentially using our features, other product areas that we’re interfacing with. We present to them the design and the design direction that we’re thinking of using, and gather their feedback to understand whether we’re really on the right track or not, and what areas we might need to improve upon. We do similar things with sponsor users. Sponsor users are a part of the agile process and they are customers that have a vested interest in the feature that we’re working on, that we’re designing and developing. Oftentimes, we present to them our early thoughts and early designs, and get feedback from them, and do the same with that feedback. We use that to improve a user interface or add some additional smaller features to the overall feature that we’re working on.
What types of applications run best on the mainframe as opposed to distributed or cloud-based solutions?
Gary: Most applications are going to run best and perform best when they’re near the place where their data resides. A lot of mainframe customers and a lot of customers in general have a good amount of data on a mainframe. I think last I heard, it was around 50% of customers with mainframes have their data on the mainframe. Applications that are near that data can perform better. Other applications that really need to be reliable and highly available run best on the mainframe because the mainframe is a very reliable platform. If a customer has critical applications that can’t experience downtime they will want to run those on a mainframe. The same goes with security, performance, and processing power. Each new mainframe has delivered has more and more processing power and we do keep on top of security. Security is a prime focus area for our customers, because they can’t afford to be the victim of hacking because it would adversely affect their business. So, for any of these reasons — reliability, availability, security, and performance — those are all good areas and reasons to have an application run on the mainframe.
How do you make sure the decisions you make as an architect are correct?
Gary: I would say there’s probably two different questions involved in this. One is “How do we know we’re working on the right things?” and the other question is “Once we decide what we’re gonna work on, how do we know whether we’re taking the right approach to that?” So on the first part, “How do we know we’re working on the right things,” that’s where we look at the list of prioritized requirements from our customers. We know those customers are invested in those requirements. Otherwise, they wouldn’t have brought them forward to us. We take a look at those and we always pick among the most highly prioritized customer requirements to do some amount of work on. Once we’ve hunkered down and started a high-level design, then we constantly review that design both internally with our subject matter experts and other architects to see if we’re going down the right path, whether we’ve overlooked something, and we also leverage our sponsor users with that design to see if what we’ve come up with is going to satisfy their wants and needs and desires.
Are you considering a career in the mainframe world? Join our Talent Network!