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.