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.
