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

So many times we hear that bigger is better. I would argue that when it comes to web services, smaller is better. It is very easy to be drawn in by the idea of taking a copybook, creating a service, without any regard for what is in the copybook. When we need a gallon of milk, we don’t go and buy the entire store! We get only what we need. The same should hold true for web services. Too many times we try to create services that cover all the possibilities anticipated. I would argue this type of approach is too broad and would incur a significant amount of unnecessary overhead. That is not to say that every service needs to be absolute either. Tacking on an extra field or two for the sake of reusability would not be a bad idea. When thinking about the size of the service, remember size does matter, and that is the right size.