GT Software BLOG

Before we start, I must acknowledge that this is in fact my first BLOG ever. I know, I know, I’m a real trendsetter, but I’ve often felt that you need to be committed to the “cause” and ensure consistent BLOGing or simply don’t do it at all. Well after much self-reflection (and prodding by some ‘friends’) – I’m ready to give it a go!

I’ve have been working in the integration space, most recently mainframe integration, for well over 15 years. The last 5 years with GT Software. We all know that the mainframe is a pricey, though extremely effective, platform and integration is key to ensuring the mainframe’s current and future viability.

Over my career, I’ve witnessed raging mainframe integration successes, and miserable mainframe integration failures. It’s always interesting to reflect on what causes success or failure and try and boil it down to a few simple ideas that are easy to understand and implement. Over the next few weeks I will do just that and provide what I believe to be the 5 guiding principles that can be the difference between success or failure for your mainframe integration projects.

Here’s the roadmap we will cover to ensure your raging success for mainframe integration projects:

Foreword: Before We Start, What is the Real Problem We’re Trying to Solve?

1. Defining the service
2. Assembling the service
3. Deployment
4. Time to deliver
5. Flexibility to change

I hope you’ll take the time to follow this thread and share your experiences and comments as we refine the integration problem to its core elements ensuring you make informed decisions about your future.

Rob

I took the Ivory Service Architect and created a very nice service based on IMS transactions. I then went into the Oracle BPEL process manager and created a BPEL process that included the aforementioned service.

So in a matter of ten minutes I had a BPEL business flow that call the IMS service as a partner-link(BPEL – Speak). I also created a composite service in Ivory that actually orchestrated multiple IMS transactions , then included that into a BPEL flow, which means the orchestration takes place on the mainframe where it belongs and does not require the BPEL tool to have to deal with multiple mainframe transactions. So yes you can easily include “ANY” mainframe artifact in a service that can be included into a BPEL flow…in minutes, not days or weeks.

In meeting with most IMS customers, most of the old IMS systems staff have for years been writing their own solutions. In most cases the product did not have a tools following so many customers just gave the IMS System group the guidelines and they wrote tools and utilities. The only problem is that the solution then took on a life of its own and consumed resources and staff just to keep the homegrown tools viable. As I go and talk to IMS customers about Ivory and SOA and how easy and straightforward the solution has become, I often hear…

1) have written some of their own  or

2) they have taken a few of the “free” IMS tools and force fit them together for a patchwork solution.

The issues that come up are extensibility, scalability and performance. To add a new function to a home grown solution in reacting to a new feature in IMS or try to get an old tool to work with new applications often causes more work than the worth of the actual solution. So it’s time to resist the urge to write your own DIY solution and let the vendors worry about all those details, versions of IMS, features of releases and other issues. Because at the end of the day the IMS systems will be around for decades, but the homegrown solutions will not react in kind. Resist the urge, don’t do it yourself.

I have had many discussions lately with IMS companies that end with that statement. In fact, you can substitute “IMS” with “mainframe” in that sentence too.  Too often companies think that to modernize means they need to scrap what they have and move to a new platform. No new functions, no new business value; just move to a different platform and all your issues will go away. Most of these IMS systems have been running fault free, day in day out for decades, and will continue to do so. Companies forget that to actually move off of IMS there would be huge costs (programming, analysis, testing, and acceptance from users) and the effort would take years, to only give the company a new platform and no added value to the bottom line.  Several questions should be asked the next time they say — “we are moving off IMS”; Why?  What new functions are we implementing that address the user’s or business’s needs? How will the new system add to the bottom line?  Maybe the consultants that suggested it are looking at a multi-year billable deal and not looking at functionality. IMS has been around for 40+ years and will continue to function. Maybe the real question should be to ask the users; what other information, what other processes and data do you need to provide? Then look at ways to provide those needed assets and functions by reusing what is already in place with state of the art integration technologies such as web services.