Listen to or download the entire 8:58 podcast below:
Download file
The full transcript is available below:
Liz Book (LB): This is Elizabeth Book, Editor-in-Chief of ebizQ and thanks for joining us on another ebizQ podcast. Today, I'm speaking with Rob Morris, Sr. VP for Marketing and Strategy at GT Software, a rapid SOA development solutions company for the mainframe. Thank you for being with us today, Rob.
Rob Morris (RM): Thank you, Elizabeth.
LB: So, GT Software is a 25 year old company doing really nothing but mainframe. Can you talk about SOA in the mainframe and maybe give us a state of the market perspective on what is going on?
RM: You know, it's really interesting. Within the mainframe space and it's long been known this way, there's still vast amounts of corporate data, corporate applications and core business functionality that's locked up in the mainframe and certainly the problem the mainframe integration has been around for quite some time. With the advent of SOA as an approach to maybe unlock or provide a better means to approach how I leverage that data and leverage those applications, what we're seeing is that companies are taking what I would consider a very simplistic approach to solving the problem. I think it's things we've been seeing in the industry lately that doing web services does not mean you're doing SOA and therefore, you cannot expect to realized the benefits of SOA if you're just focused on web services.
So, for a lot of reasons, we see mainframe organizations simply stopping at the term Service Enabling or web service enabling the mainframe and not really getting to the broader spectrum of what SOA can mean for them in the context of the mainframe. So, that's everything from not getting the right resources involved on the mainframe, not focusing on how I define services and what are proper services vs. just worrying about the mechanisms of how I communicate to them or something a bit broader and something not as obvious to how am I going to incorporate things like my batch systems which are still prevalent in the mainframe world and have those participate in my service oriented architecture.
So, again, people continue to take this very simplistic view and unfortunately from some of the vendor perspectives it's a view being promoted out there or being confused by what a lot of people are talking about out there and the complexities around it and when you start to break it all down, you realize that they're not going to achieve these benefits unless they take a step back and take a broader view of how they're going about this.
LB: OK, you mentioned batch processing and people don't really associate batch processing necessarily with service oriented architecture. Can we talk about that?
RM: Actually, it's a very, very interesting and intriguing development that, frankly, we're very happy about. We've been working on it in conjunction with some customers and if you take a step back on this topic and start to think about it in the financial services industry, specifically insurance and other industries like that, batch is a huge part of how they continue to run their businesses. It's really the only way that you can continue to process the volume of transactions required on a daily basis to do things like maybe claims processing or payroll remediation, things of that nature.
So, almost, you know, kicking and screaming, batch is being drug into this world by the simple fact that every day there's another web service, there's another service that those systems need to talk to.
And let me give you an example; I'll give you a couple of examples: In the insurance industry, if I'm processing auto insurance claims, one of the steps in that process is to validate the vehicle ID number, the VIN number against data that I might get from my state or federal government data sources. Well, where that used to be a daily download of data is quickly becoming a real-time web service request.
So, here I am with a batch cycle, if you will, I maybe have 3 hours to process four million claims on a daily basis and now, somehow, I have to introduce a full round trip web service call to do my VIN number validation. So, I start to have to think about how am I going to deal with a window, a batch window, that I cannot alter because I only have so much time to do this work. I have a certain volume of work I have to push through there and now I have to introduce the overhead of web service calls.
And so, we've been working very closely with the organizations on how they deal with that and, in fact, the other side of this equation is as companies themselves introduce web services into their own world and take and SOA approach, we're finding that those batch systems need to then talk to those new systems so with one of our customers that works in the health care industry, they were trying to deal with the fact that in the health care industry there's now something called a national provider ID - an NPI.
Essentially what that means is that all doctors nationally now have a number associated with them and that's how those doctors should be referred to. So, as opposed to the time when every company would associate their own proprietary ID, we now have a national identifier system so we have a customer that took an SOA type approach and built the service to do a translation between their proprietary numbers and the national provider numbers. So, again, at night, while they're trying to process claims, they now have to convert back and forth and they have to do that in such a way that they don't compromise their batch window. And, in working with them, we were able to achieve essentially a full round trip web service call in a little less than 12 milliseconds which enabled them to maintain their batch window, add the translation process and do all this in an SOA type fashion. Again, this is one of these requirements that I think in the next 6-12 months is really going to come to the forefront in the financial services base.
LB: Thank you. I guess I'd like to ask two things at the end of this. First, can you tell me in the context of GT Software and the experience that you've had at GT Software, a long-standing company with a lot of experience in this space, can you talk about some best practices for mainframe/SOA integration?
RM: Sure, absolutely and it's an area that we've tried to take ahold of and work as much as we can to help educate the market a bit that are companies that are achieving unbelievable results including the mainframe in their SOA strategy and I would say at the forefront it's thinking about the mainframe as you start to lay out your SOA strategy for many, many organizations we find, it's a bit of an afterthought and when you start to take a step back and say, you know what, if this is going to be important to me, if that data and the applications are important and the participation is important as I am setting my standards from an architectural level, I need to consider the requirements as it relates to the mainframe and what that immediately does is start to get into how I involve the resources on the mainframe. One of the most disturbing that I continue to see in the market is that mainframers are "dissed" if you will, in terms of SOA simply because SOA tends to be driven by more of your distributed, open systems type resources and I hear a lot, "well, mainframers don't understand SOA" or "these guys will never get their head around how to define the service properly" and I think, in the end, what you see is that's clearly not true. Since SOA is not about web services and about the technology, it is much more about a collaborative process by which we determine needs or services that make sense in the context of our organization and then we find ways to fulfill those needs, many times on the mainframe is where the data, those applications, that need can be fulfilled and by not including the mainframe group in that process, you're simply going to be playing catch up after the fact in building systems that do not give you the re-use, the longevity that you're hoping to get out of SOA.
So, our number one best practices is including it early and getting the people involved. And what that then leads you to are technology decisions to allow you to do both bottom up as well as top down service design. I know we went from a very broad topic to something very specific, but essentially, if you are able to work in a service definition process, working from the top down, that is working from the need that the services is supposed to fulfill and then worrying about how to fulfill it, your technology choices and who you get involved will be dramatic different because you will involve that group from the get-go, they'll be part of the process and you'll find that you'll get maybe a different set of services but certainly services that are more valuable, that give you the re-use that you're looking for an participation where people are trying to help solve the problem not working at odds with each other.
LB: All right. Thank you very much, Rob. I think we understand a little better about why GT Software is in this space and why it's considered a best of breed mainframe solutions provider. So, thanks for your time, very much.
RM: Thanks, Elizabeth, hopefully it was of value for everybody.
LB: Thank you. And, so Rob Morris, Sr. VP for Marketing and Strategy at the privately held at the Atlanta, Georgia-based GT Software.
Leave a comment