SOA is not dead

Mark Twain and Service Oriented Architecture (SOA) seem to have much in common; the rumours of their deaths have both been greatly exaggerated.

Following the SOA obituary published by a prominent industry analyst last month, there has been considerable debate about the viability of SOA and its ability to deliver on its promise.

Indeed, reduced budgets or the high costs of deployment means that SOA's potential is under threat in many organisations. And, when you look at current financial trends, things look like they are growing less rosey. Most published IT budgetary surveys show corporate IT spending for 2009 has flatlined. According to Gartner, Inc., budgetary growth of 2.3 to 0% is most likely, with a worst-case projection of 2.5 % in the negative!

The irony is that SOA actually delivers considerable value for enterprise-wide interoperability. Incorporating mainframe-based resources into some sort of Web services integration initiative or a SOA is not really 'just an option' any longer. 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.

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 create a spaghetti scenario, and runtime operations are complicated due to multiple, often overlapping, tools that are inefficient in their use of mainframe resources.

While, once in place, an SOA can address many of these concerns, it can be expensive when you consider the ongoing increase in mainframe processing costs associated with Web services. This “after the fact” cost can even sour functionally successful implementations once you start thinking about mainframe upgrades and the associated increase in mainframe software licensing and maintenance fees to support SOA's additional processing needs. Here's the dilemma: how do you support new SOA initiatives when there is just no budget available?

Getting it right

The good news is that an SOA initiative can pay for itself and may even save enough to fund further SOA projects. The trick is to bring operational systems into SOA cost-effectively and quickly, while preserving the operational balance the budget requires.

By taking a well-planned and intelligent approach, you can avoid the pitfalls common to mainframe-based SOA and get the ROI typical of the z/OS platform.

One mistake is to approach SOA as a wholescale overhaul of enterprise IT architecture; it's likely to bust the budget in the current environment. In fact, a recent Gartner survey stated the two major reasons organisations cite for choosing not to pursue SOA was a lack of skills and expertise, and no viable business case.

However, 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 that individual web services rather than an SOA deployment makes better economic sense than an enterprise-wide deployment when you consider the desired results and time involved.

In any case, the best integration solutions allows for incremental deployment of an SOA and can easily be expanded upon on as needed. In line with this, it's also essential to keep complexity to a minimum, because this equates to cost and delay. Resist the tendency to build complexity on top of underlying resources and try to keep it simple by avoiding the use of disparate development tools and methodologies.

There are mainframe integration products 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 artifacts 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 make the most of the skill sets you already have.

A mainframe integration product should enable people familiar with a mainframe application and related tools to make applications work quickly, without actually having to be an SOA master. 

Fresh opportunities for the mainframe

The adoption of SOA as the de facto IT architecture is providing fresh opportunities for the mainframe platform to drive new business services; however, if you want to expand the mainframe into SOA initiatives, you must be aware of architectural requirements that include technologies to enable the mainframe to be cost-competitive against other platforms.

Without effective tools for reducing mainframe SOA processing costs, the benefits of easy integration will be overshadowed by deflated project ROI. While mainframes possess huge amounts of processing capacity, it can be costly. Much of the outlay 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 mainframe solutions fail to optimise their run-time environments with the express aim of conserving mainframe CPU usage at runtime. That's why many mainframe customers struggle to manage the growth of their mainframe capacity. Nowhere is this more important than with SOA projects.

So, if you find a tool that allows a rather large application to play a bigger role in an SOA and deliver with only a small incremental increase in MIPS, it actually pays dividends platform-wide rather than just on the application. It allows an organisation just now adopting SOA to better manage its MIPS growth as its SOA initiatives mature. This efficiency gives you the ability to re-allocate these MIPS to new workloads or absorb increased MIPS requirements from existing workloads.

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 they also impact the budget.

If an SOA-enabling mainframe integration solution simply runs all processing exclusively within existing subsystems such as CICS you can get a considerable increase in MIPS usage, which corresponds ultimately in a significantly increase in processing costs and Mainframe Total Cost of Ownership (TCO).

Next-generation middleware is now available to take full advantage of specialty engines, both the zIIP and zAAP specialty engines, to minimise the potential impact of the processing-intensive nature of mainframe-based Web services.

Saving costs by taking control

Today’s mainframes include sophisticated hardware and software features, such as the Workload Manager (WLM), which allows a system to offer threading or managed Quality of Service (QoS) with smart work dispatches on the mainframe; leveraging these features gives administrators granular control over the different assets and how they’re deployed.

Let’s explore the multitasking environment of the mainframe in more detail, so that we can better understand how a next-generation middleware product can be used for cost-effective SOA-enabled mainframe integration.

Mainframe processors are dispatched as threads through Task Control Blocks (TCBs), but not all threads are created equal. The WLM software prioritizes TCBs within the z/OS in order to help administrators control workloads according to such considerations as QoS and Service Level Agreement (SLA) goals. The z/OS also uses a lightweight, low-overhead type of thread called an enclave Service Request Block (SRB).

Certain enclave SRBs are eligible to run on the zIIP specialty engine, designed by IBM primarily to make it more cost-effective to employ IBM’s DB2 with such data-intensive applications such as Enterprise Resource Planning (ERP), Business Intelligence (BI), and Customer Relationships Management (CRM). Eligible SRB workloads can run without the governing constraints put on the general purpose processor (GPP) and use no measured software, reducing the overall MIPS consumption and avoiding a cascade of associated ISV-related charges.

To the best of my knowledge, no middleware products sold today to support mainframe SOA were written to run in enclave SRB mode. Most strictly utilise Task Control Blocks (TCB) threads to handle integration functions. A relatively new development is next-generation middleware that uses a hybrid threading models which dynamically switches from running in SRB mode to TCB mode when needed and back to SRB mode for optimised performance and zIIP access.

Unlike typical mainframe middleware products that can't exploit the zIIP or do so under constrained circumstances that relies on XML System Services, the hybrid threading model of next-generation middleware enables almost all necessary processing — such as XML, un-marshaling and marshaling, security processing, and development-related processing — to be migrated from the GPP to the zIIP, where it is processed faster and at a lower cost.

Every MIP used on the zIIP to handle processing-intensive SOA is a MIP saved on the GPP and so avoids incurring costs. 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 next-generation middleware can, with confidence, develop mainframe-resident services that exploit zIIP engines for services-specific tasks including XML/SOAP processing.

Well-designed mainframe SOA integration products can demonstrate that as much as 99 % of their processing can be diverted to IBM’s zIIP specialty engine. This yields a GPP dividend that can be applied to growth in traditional or new business applications, ensuring improved throughput and the lower TCO necessary to cost-effectively integrate mainframe assets into a SOA.

Deferring capacity upgrades

The strategy described here will not only help you achieve SOA-specific goals with scalable and cost-effective mainframe Web services processing, it also helps reduce mainframe TCO by slowing the rate of MIPS growth associated with integration workloads. This allows you to avoid or defer costly mainframe capacity upgrades.

Here's how it works. Assume a 20% Compound Annual Growth Rate (CAGR) for MIPs, the System z computing power calculation, with a current capacity utilization rate of 66 %, and an average incremental mainframe-based Web services processing load of 10%.

Traditionally, an organisation having this scenario would require an upgrade in the first year to avoid undue capacity constraints beginning in Year Two.

By employing a zIIP enabled, next-generation mainframe middleware product approximately 70% of the SOA related processing can be offloaded to the zIIP specialty engine. This scenario could potentially delay the organization’s need for a mainframe capacity upgrade until the end of Year Two — a full year later.

Considering that the fully loaded costs of each mainframe MIP can run into the thousands of pounds, the savings provided by zIIP offload can be significant and provide a way to cost justify an initial implementation of mainframe Web services or continuing to expand on existing SOA initiatives.

While SOA may have received a bad financial rap, there is technology that can dramatically lower the cost of mainframe Web services supporting SOA. Organisations that require the transactional prowess delivered by mainframe systems can ill afford to turn away from SOA. They still need its infrastructure agility 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, you can make SOA viable for your business — and with the resulting efficiencies, can provide the resources needed to fund SOA initiatives in the future.