Is mainframe-based service oriented architecture on the ropes? In many organisations, the potential of SOA is being threatened by reduced budgets or by high costs of deployment.

his is particularly true in mainframe environments where, ironically, SOA delivers considerable value for enterprise wide interoperability.

Fiscally, the outlook is less than promising. Most published IT budgetary surveys anticipate growth in corporate IT spending for 2009 to be anaemic or entirely flat.

The irony lies in that, for enterprise operations that include mainframes, incorporating mainframe-based resources into some sort of SOA can no longer really be considered an option.

For certain applications (if not organisation wide), it is all but mandatory. Few organisations can realistically afford to build out service-oriented constructs without leveraging the indisputable values – reliability, availability, and scalability – that the System z provides, not to mention the considerable data resources these systems typically contain in a given business.

Deferring Mainframe Capacity Upgrades

Well-designed mainframe SOA integration products have demonstrated that as much as 76 percent of their processing can be diverted to IBM’s zIIP specialty engine. To understand how this can help defer an organisation’s need to purchase a capacity upgrade, assume a 20 percent Compound Annual Growth Rate (CAGR) for the System z computer power calculation, MIPS with a current capacity utilisation rate of 66 percent, and an average incremental SOA processing load of 10 percent.

Traditionally, an organisation having this scenario would require an upgrade in the first year in order to avoid undue capacity constraints. Employing a next-generation mainframe SOA integration product capable of 70 percent SOA offload rate to the zIIP specialty engine, the organisation could potentially delay a mainframe capacity upgrade for another 12 months.

But mainframe integration tends to be costly. Traditional mainframe workloads typically require low-level integration or build-it-yourself solutions demanding specialty skill sets that are in short supply.

Complexity also drives up costs. IT portfolios that rely on multiple integration technologies with differing capabilities and requirements creates a spaghetti scenario, and runtime operations are complicated due to the use of multiple, often overlapping tools that are inefficient in their use of mainframe resources.

While once in place a SOA can address many of these concerns, it does carry the potential of bringing costly factors into the equation -- the ongoing increase in mainframe processing costs associated with Web services.

This “after the fact” cost can even sour functionally successful implementations due to the collateral operational costs associated with mainframe upgrades and the associated increase in mainframe software licensing and maintenance fees to support the additional processing needs for SOA.

The dilemma faced by organisations and/or departments is that they lack the additional budgets to support new SOA initiatives, yet are expected to support such initiatives. Where are the resources to come from?

A Balancing Act

The good news is that the Return on Investment (ROI) from deploying a SOA initiative can pay for itself and may even provide sufficient cost-cutting dividends to fund additional SOA initiatives.

The trick is to bring operational systems into SOA in a cost-effective manner and as quickly as possible while preserving the operational balance the budget requires. By taking a well-planned and intelligent approach, an organisation can avoid several pitfalls common to mainframe-based SOA and leverage cost-saving strategies available to the z/OS platform.

One mistake widely made by businesses is to approach SOA as a wholesale overhaul of their IT architecture. In an enterprise-scale operation, this naturally represents an enormous and potentially budget-busting upfront expense.

The first step in considering SOA is to honestly appraise where more interoperability between applications and/or more reuse of resources will have the greatest impact. It could be individual Web services rather than a SOA deployment makes better economic sense than an enterprise wide deployment, both in terms of results and with regard to time to value.

In any case, an integration solution should be sought that allows for a SOA to be deployed on an incremental basis and easily expanded upon on as needed.

In line with this, it is also essential to keep complexity to a minimum, because complexity equates to cost and delay. Organisations should resist the tendency to build complexity on top of underlying resources. By the same token, they should avoid utilising an abundance of disparate development tools and methodologies.

Mainframe integration products are available that mask mainframe complexity and that employ a common development metaphor across industry-standard integration paradigms. Development teams should seek a unified mainframe SOA-enabling architecture for reducing integration complexity and overhead.

It should build upon existing mainframe development processes rather than replace them, and should generate minimal artefacts that can be readily managed using existing migration procedures and traditional tools.

This brings up another important factor to consider in SOA-enabling mainframe assets: the integration solution should leverage more than those assets for reuse as new services — and without disrupting or changing ongoing operations.

It should also leverage the skill sets already present within the organisation. A mainframe integration product should enable personnel familiar with a mainframe application and related tools to quickly make the value of the application available as services, without those personnel having to be SOA masters themselves.

Strategising to Reduce Costs

While mainframes posses huge amounts of processing capacity, it can be costly. Much of the cost for software residing on a mainframe, including licensing and maintenance is tied to the capacity of the mainframe, which is typically measured in MIPS.

Unfortunately many commonly used integration solutions for the mainframe fail to optimise their run-time in order to conserve mainframe CPU usage at runtime. Hence many mainframe customers are struggling to manage the growth of their mainframe capacity.

Nowhere is this more important than with SOA projects. If an organisation can harness a technology that enables it to expand a large application’s participation in SOA with only a small incremental increase in MIPS to handle the large increase in processing of Web services, that actually represents a platform wide rather than application-specific dividend.

The Simple Object Access Protocol (SOAP) and the Web Services Description Language (WSDL) standards that enable SOA are all about XML — highly verbose, text-based messages that require XML parsing and XML navigation. Such computationally intensive tasks are precisely where mainframes excel. But their impact on the budget must be addressed.

If a SOA-enabling mainframe integration solution simply runs all processing exclusively within existing subsystems such as CICS — as some of the more commonly used solutions do — there can be a significant increase in MIPS required and therefore mainframe-wide software usage fees can be considerable. Next-generation products are available that run in their own specialty subsystems that can minimise the impact of the processing intensive nature of mainframe-based Web services.

Such products are designed to exploit IBM’s innovative specialty engines such as the Integrated Information Processor (zIIP) — which processes eligible workloads using dedicated processors that are free of the governing constraints put on the general purpose processor (GPP) and free of associated software charges. In other words, every MIP used on the zIIP to handle processing intensive SOA is a MIP saved on the GPP and thus cost avoidance.

Use of these engines should be transparent to developers and automatic in nature so that if a zIIP is not present initially, SOA applications can immediately and automatically exploit it as soon as one is present.

Developers working with these next-generation products can with confidence develop mainframe—resident services that exploit zIIP engines for service-specific tasks including XML/SOAP processing. This yields a GPP dividend that can be applied to growth in traditional or new business applications and can also serve to defer expensive mainframe capacity upgrades.

While SOA may have received a bad financial rap, the technology exists to dramatically lower the cost of mainframe SOA initiatives. Organisations that require the transactional prowess delivered by mainframe systems can ill afford to turn away from SOA. They still need the infrastructure agility provided by SOA and Web services in order to effectively compete in today’s real-time marketplace.

With careful consideration toward their technology investments, both hardware and middleware, reducing complexity, reusing available assets (both software and staff), and conserving runtime processing costs, organisations can make SOA viable for their business – and with the resulting efficiencies provide the resources needed to fund SOA initiatives in the future.

Gregg Willhoit is the Chief Software Architect for DataDirect Technologies responsible for the technical leadership of its mainframe-based Shadow products. He has architected and developed a wide variety of commercially successful software products including; DBMS Catalog Management tools, MVS and DB2 performance monitor and is the co-developer of Shadow Direct, the first commercially successful ODBC-to-mainframe data product for DB2, IMS, VSAM, CICS, and Adabas. He can be reached at [email protected]