A leading insurance company and large System z shop was feeling the pain of problems typical of large organizations whose IT infrastructure had evolved over decades into a heterogeneous hodgepodge of incompatible systems. Sooner or later, management realized, the company would need to do something about the situation. Meanwhile, its systems environment was becoming increasingly expensive to maintain. Integrating applications was costly and slow, and the results often were unsatisfactory. Making changes turned into a nightmare; each change increasing the likelihood of breaking something else. The company might have continued to limp along, but a changing business environment forced it to pursue a new strategy and address its long-festering IT problems.
To address changes in the insurance market, the insurer embarked on an acquisition strategy of acquiring small niche players that already supported one or more of the new changes. That acquisition strategy required the integration of new functionality the company had gone to great expense to acquire, and the company couldn’t wait years to put the new acquisitions into production. It turned to SOA.
SOA on System z
Service-Oriented Architecture (SOA) provides an open, standards-based approach to linking business and technology that allows a company to leverage existing software assets as reusable services. These can be combined, recombined, and augmented in various ways to deliver new business functionality faster and at lower cost. In the process, SOA effectively integrates systems through services interfaces.
With SOA the insurance giant could set up business capabilities as a flexible set of services instead of rigid, cumbersome, monolithic applications. The services call other services to request data and processing while the existing applications run unchanged behind the services interface. By leaving the existing systems in place and adding standardized interfaces, the insurer’s IT group could more quickly respond to business changes.
Although the early SOA implementations typically involved distributed systems, the insurer found no reason it shouldn’t work as well with the System z. In a presentation at IBM’s Impact 2008 conference, the insurer explained why SOA on the System z made sense:
- Low TCO
- High quality of service in terms of performance and reliability
- Massive scalability
- Rock-solid security
- Availability of Java/J2EE for the System z
- Established coexistence with distributed systems, especially tools for interface development
- Availability of the full SOA stack and foundation products.
But the most important reason of all to do SOA on the System z—that’s where the valuable data, applications, and business rules and logic already resided.
The New York State Department of Taxation and Finance came to the same conclusion when it needed to meet changing expectations while under pressure to reduce costs yet be responsive. It, too, felt saddled with cumbersome legacy systems. However, it couldn’t abandon proven mainframe applications despite the cost of integrating what amounted to stovepiped systems. Instead, it turned to SOA to revamp the tax processing operation.
The Tax Department’s IT group created an SOA services layer consisting of services and composite applications built from services that enabled it to leverage and augment its existing System z applications for the purposes of delivering what appears as modern, flexible, highly responsive applications. The result: an 80 percent reduction in tax processing backlog, a 40 percent reduction in staff time required, along with corresponding staff reduction and substantially reduced application development time.
The Role of the System z