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

Let’s face it — shifting workload from the general purpose processor (GPP) to the zIIP, zAAP or IFL mainframe specialty engine is smart.  Really smart.  IBM’s desire to make the mainframe a more attractive platform for new workload may dramatically slash the cost of mainframe integration and SOA projects.

The reduction in CPU consumption offered by properly leveraging specialty engines tells a compelling story.  Run your workload on a specialty engine and not only save money, but achieve higher performance.  A no brainer, right?  Well….not exactly!  As you would imagine, all workloads are not created equal.  A major issue is the ability to selectively choose which workload remains on the general processor, and which is sent to the specialty engine.

Just because you can send mainframe SOA or integration workload to a specialty engine does not mean you should. There are many use cases where it is much more efficient to NOT shift workload to a specialty engine.  Why — because, there is overhead associated with moving workload from the GPP to the zIIP or zAAP engine.  The cost will vary by situation, but a good rule of thumb is that if you shift “small” workloads from the GPP to a specialty engine the savings will not cover the CPU overhead of moving the workload.

Therefore, the “smart” approach to maximize savings and performance is to be able to discretely manage the workload that is sent to the specialty engine vs. what remains on the GPP.

Another degree of required flexibility is the ability for you to choose which specialty engine to utilize. Some enterprises will have a zIIP, others a zAAP, while others may have the zIIP, zAAP and IFL engines.  Organizations simply have not made a strategic commitment to one engine vs. another.   We often see companies starting with say a zAAP engine, and then change their mind and switch to a zIIP or IFL.

Therefore, the “smart” approach to de-risking your specialty engine commitment is to ensure the products you utilize for mainframe SOA and integration can leverage all three specialty engines, as well as not standing in the way of changing to a different specialty engine tomorrow.

Let me be clear — vendor solutions that mandate an “all or nothing approach” do so because of shortcomings in their vision and technology.

Using specialty engines is definitely smart, managing workload on a service by service basis to maximize MIPS savings without sacrificing one bit of performance is what we call “being smart about leveraging specialty engines.”