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.
Have you read these related articles?
Newsletter:
