LiteBytes from Lustratus Research

Secure mainframe SOA-in-a-box

I was reading the announcement from Layer7 about its 'SOA-in-a-box' for IBM mainframe users, and a number of things struck me. First, I am SO PLEASED to see someone remembering that CICS is not the only mainframe transaction processing environment in use today. A significant number of large enterprises, particularly in the finance industry, use IBM's IMS transaction processing system instead. With the strength and penetration of CICS in mainframe enterprises, it sometimes seems like these users have become the forgotten tribe, but investments in IMS are still huge in anyone's numbers and it is a smart move to cater to them. I am sure that the fact that this solution serves IMS as well as CICS users will be a big plus.

The other point that struck me was that I have felt for some time that, with the security/intrusion detection/firewall/identity management market seeing such a shift to security appliances, it was time vendors thought of piggy-backing functionality onto these platforms. Of course, one reason for having an appliance is to provide a dedicated environment to address issues such as security, but in truth these appliances are rarely used to anywhere near capacity. Therefore it makes a lot of sense to optimize the use of the available processing power rather than slavishly locking it away where it can;t help anyone.

Finally, I have to admit my first reaction to this announcement was to worry about how good connectivity would be to the mainframe. Dealing with mainframes is an arcane area, and I was not aware that Layer7 had any special expertise or credentials here, but I see that GT Software is apparently providing the mainframe integration piece. This makes me a lot happier, since this company has been dealing with mainframes for 20 years. In fact, Lustratus did a review recently on GT Software's Ivory mainframe SOA tool, which is apparently what is included in the Layer7 box.

Anyway, on behalf of all those IMS users out there, thanks Layer7!

Steve

User experience with mainframe SOA provides interesting pointers

Yesterday, I had the pleasure to host an Integration Consortium webinar on the topic of mainframe SOA. The user experiences were provided by SunTrust, a major US bank, and I found them most illuminating.

One point that struck me was to do with ownership of the new services, from an organizational point of view. The issue here is that, although services representing mainframe transactions clearly fall into the domain of the mainframe programmer, the concepts of SOA and often the related tools can be quite alien to these programmers - having to worry about SOAP messages, XML, WSDL and web services standards for example. SunTrust cleverly selected a mainframe SOA toolset that masked much of this complexity, offering a development environment that COBOL programmers felt comfortable with. As a result, mainframe services are built and owned within the mainframe team, which is where they belong to be honest. To complete the picture, the tool transparently handles the service deployment, creating WSDL and exporting to UDDI registries as required, ensuring that SOA users will see familiar services.

The lesson seems to be, be clear on who you want to own what, and then choose a toolset that supports that decision. The alternative is a confused mishmash where no-one knows who is responsible for what.

Steve

Is your legacy integration just a veneer?

Summer seems to be a time for reading through that huge pile of interesting articles and magazines that you can only find time to look at on vacation. On flicking through my own mountain of stuff, I came across the Q2 edition of Financial-i, a magazine targeted at the Financial Services industry. One point to jump out at me was a comment from Paul Joynt of Nordea, a Scandinavian finance house.  Paul was pointing out that SOA does not necessarily solve the problems associated with legacy integration.

The article, 'SOA - is it worth the effort', is available from the Financial-i site if you register, but Paul comments that covering a legacy system with a wrapper "so it looks like what you want" still leaves problems with the next level of change, because "it's only a veneer".

I think Paul has hit on an important point here. Different vendors in the SOA space have different approaches to addressing the problem of integrating legacy systems. Some will simply 'hand off' the request for legacy information to a tool from the legacy supplier - in the case of IBM mainframes this might mean using WebSphereMQ as the bridge, for instance. Others might approach the problem in some sort of screen-scraping or other interface simulation approach, where the legacy application is fooled into thinking it is running in its normal mode of operations. Yet more may generate code-based wrappers for each individual need, to be executed whenever a particular service is required.

To me, this all sounds too much like veneer in Paul's terms. Although this might address immediate needs, future changes will continue to generate substantial additional work and the generation of more and more 'special-case' code and wrappers.

Instead, the best of breed legacy integration solution should embrace SOA and integration rather than try to fool it with wrappers designed to seal off the legacy world from the outside. Legacy integration should be about making the legacy system a full and active participant in the service definition and execution. For example, orchestration should be possible both outside and within the legacy environment. Services should be built with full participation from both sides. By taking this approach, the best of breed legacy integration tool will ensure that future changes will become easier, quicker, cheaper and more reliable.

For more information on the whole subject of legacy integration, specifically in the case of mainframe systems, Lustratus offers a free paper on the subject.

Steve