IMS has been around and in production for over 40 years as the backbone system of many world class organizations in all industry verticals.  Now with some of the new technologies and systems many are looking to try and replace those tried and true systems. Why replace something that is tried and true, why not just incorporate the new technologies and let them drive the existing IMS systems (without changing the IMS systems).

Already companies are using web-services to drive IMS transactions or sets of transactions to create composite business services needed by the new business initiatives. Now it is also possible to create RESTful services (RESTful interfaces typically require less development effort and use less runtime overhead) and include those in many new technologies easier that using the WSDL or Web service protocol. Also as many systems move to Web 2.0 interfaces they can be used there also with mash-up tools to create the new user facing systems. You can also use both Web Services and RESTful services in mash-up tools depending on designer preferences.

If you are using Microsoft tooling like SharePoint 2010 those services can be easily incorporated into the design of the SharePoint 2010 applications also. In SharePoint 2010 you can also use either service (REST or WSDL).

In all the scenarios mentioned, the underlying IMS applications (transactions) do not need to be changed; they just continue to work as they have for decades. The important part is to focus on the business need required to drive the use of the new technology, and not replacing existing software just because it’s been running for awhile. Use IMS with the new technology, it will be a lot easier and less painful.

For Information on using IMS with REST, Web Services, SharePoint 2010 see www.gtsoftware.com.

IMS has been a production ready system for over 40 years, and as Steve Nathan (IBM) has said for years , “IMS was the first real application server”.

Let’s look at the definition first:

Application Server: Also called an appserver.   A program that manages all of the operations between a user’s application and the organization’s backend business applications or databases.  Application servers are typically used for complex transaction-based applications. To support high-end needs, an application server has to have built-in redundancy, scalability, security, logging, monitors for high-availability, high-performance distributed application services and support for complex database access.

This is basically what IMS has been doing for over 40 years in a dependable environment, that is both scalable and is “bet your business” for many of the world’s largest companies. Now as new environments come about they want to replace this dependable system with a new “application server” that lacks most of the qualities specified in the definition above, the only new part is that it runs somewhere else other than the mainframe.

How about this , there are companies today that add the ability to expose those tried and tested IMS transactions as services(WSDL and REST), they can allow IMS transactions to call other “new” distributed systems, they can allow IMS to be included in “new” architectures (BPM, Mash-ups, Sharepoint 2010 etc..), and they can do this without changing the original applications. So stay with the original and let it do what it does best.

And I close with a quote from Seymour Cray (Cray Computers), I think he was talking about IMS (maybe!) “If you were plowing a field, which would you rather use?  Two strong oxen or 1024 chickens”.

I was recently contacted by a customer who started the discussion with “I was looking at this BPMS tool that uses a BPMN 2.0 modeling with BPEL execution to create a business process and I need to include an IMS transaction, how can I do that?” Well after trying to decode all the acronyms in that question I asked him what he needed. They had started using a very powerful tool (ActiveVOS www.activevos.com) and were putting together some very interesting business processes, and inevitably he ran into process that needed information from the mainframe. After researching and talking to the guys at ActiveVOS, we realized that a web service that was created in Ivory Service Architect could easily be included into a business process (as a partner link) into ActiveVOS flows.    We created a simple IMS service in Ivory we turned the WSDL over to the designer in ActiveVOS, and in about 5 minutes that flow was invoking the service. We went on to create more complex services in Ivory that involved calling multiple IMS transactions in one service( a mainframe composite service), and again it only took a few minutes before that service was part of a business flow. So, two groups, that spoke their own languages, were able to easily and quickly create business services involving diverse architectures including the mainframe applications.

From that discussion the two companies put together a joint webinar showing how these two products and ideas were easily melded into true business solutions. So now I know that BPMS is (Business Process Management Suite), and BPMN is (Business Process Modeling Notation) and BPEL is (Business Process Execution Language) and all they need to know is that talking to mainframe is easy via a WSDL in Ivory Service Architect. That webinar is at www.vosibilities.com “Leveraging mainframes for BPM success”.

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.