Prohibitive Infrastructure Costs

The concept of EAI isn’t difficult to understand. The difficulty is the high cost associated with building a significant piece of new infrastructure. Like any good infrastructure, EAI will benefit many applications and projects. Yet, without the backing of a solid architectural model, it will be funded and deployed piecemeal on a project-by-project basis. This Balkanization of infrastructure is so expensive that individual projects will either not attempt to do it, or will underfund or underestimate the funding requirements. The various EAI companies that understate the cost and complexity of deploying these solutions abet this. The results are blown budgets and timelines and an even more difficult job of convincing top management that EAI tools deliver value.

Companies typically underestimate the integration costs associated with major legacy replacement or other significant IT projects even when they pursue traditional tools and point-to-point integration approaches. Significant costs associated with integration are ignored or unaccounted for. The use of EAI tools often forces an explicit recognition of these hidden costs. The combination of project-by-project funding and exposing hidden costs can make the use of EAI tools appear to be substantially more expensive than traditional approaches.

Among the hidden costs that become exposed in an EAI implementation are new infrastructure and the cost of creating a reliable integration environment. In the case of infrastructure, the cost of the computing power needed to do the Extract, Transform, and Load (ETL) piece of the integration was frequently hidden in the cost of running the application on the mainframe. This was just another COBOL job required to run the application and not accounted for separately from the cost of application development, operations, and maintenance. In an EAI world, the tool is frequently hosted in a separate computing environment that has to be made fault-tolerant. The costs of this separate environment can be easily counted. They appear right on the hardware and software POs. These costs are frequently an addition to the business case costs because the original business case didn’t include the use or cost of an EAI tool.

The cost savings almost impossible to capture that derive from EAI tools are in operation of the legacy integration solution.

The Problem With ROI

Demonstrating a positive ROI or Net Present Value (NPV) is critical for the deployment of EAI tools, but it’s also difficult. Many IT professionals have privately berated the finance people who, they claim, prevent the IT folks from doing the right thing and deploying enterprise solutions. It’s no surprise that those responsible for ensuring profitability don’t always believe the IT people when they say, “Trust me, these new-fangled widgets will save the company millions.” They’ve heard the story before, and often — the technology didn’t meet expectations. Even when expectations were met, the finance people attribute it to luck or say it occurred despite the best efforts of IT.

Again, this points to the requirement to have a solid architecture in place before launching an EAI effort. This reduces the cost and risk of deploying new technology. Moreover, in the eyes of the business people, it reassures them that there’s an overall IT plan and that this project fits into that plan. It addresses the issue of trust.

Trust also stems from making clear commitments on costs and savings, and then meeting or beating those commitments. Calculating an ROI is pretty simple. Yo u need to know your up-front and ongoing costs for the new solution and ongoing costs for the legacy solution. A simple formula that takes into account the time value of money and the cost to borrow or obtain equity financing is used to determine whether a project or technology is viable. There’s little room for strategic fit or other soft factors. Many companies won’t even allow the use of soft savings such as productivity improvement or resource reallocation. They’ve frequently seen that such soft savings weren’t actually realized on IT projects.

So, including the complete current operating cost picture is essential. It’s difficult to do and rarely gets the attention it deserves. Benefits get overstated and costs understated. This funds the current project, but dooms future efforts because expectations set in the business case cannot be met. Never assume that finance managers will ever forget a set of numbers promised as cost savings! They will also latch on to the most optimistic numbers they hear, even if they don’t make it into the final business case.

There are obvious sources of current costs (e.g., cost of maintenance on development tools and the labor needed to maintain integration programs) and hidden sources difficult to quantify. Hidden costs include:
• Labor required for fixing bad transactions and repairing databases corrupted due to a bad transaction. This is probably the largest source of overlooked costs. With the EAI tool, we’ve presumably included the costs to create a highly fault-tolerant, operable, and recoverable environment. What were the costs of not having this or what were the costs in people resources needed to monitor, repair, and re-run the legacy system?
• Mainframe CPUs and other resources needed to run integration jobs. This requires documenting all jobs related to integration and tracing back the costs to execute them.
• Programming resources needed to maintain the integration. Often, programmers will work on integration and application maintenance chores. Yo u should make the effort required to separately assign a cost to each of these.
• Network costs for transferring data files. Many Value-Added Networks (VANs) still charge by the bit or transfer. Are mailboxes required for exchanging data and do these have a monthly cost? Many Electronic Data Interchange (EDI) networks had a lot of these hidden costs.
• Batch processing costs — What did it cost to have batch vs. real-time or near real-time integration? Did this result in slower response to customer requests for inventory availability or slower credit approvals because the data wasn’t available?
• Data integrity costs — What’s the cost of redundant or incorrect data in the legacy systems? What happens when the information in the payroll system doesn’t match the HR system?

Evaluating all these factors and assigning costs to them on the legacy side and benefits on the new application will be critical to getting EAI projects funded and approved. Set expectations up-front, then meet them. Often, the right thing for the organization is to employ a tool, but usually IT managers aren’t diligent enough to run down all these hidden costs. This then requires them to promise the moon in benefits to pass the ROI hurdle. Fully exposing the costs of the current integration environment will help deliver a compelling ROI case and set realistic expectations for the new environment.

Consider the case of a large manufacturing organization that was evaluating the use of a complete EAI tool suite to replace a large legacy application. Initially, the cost of the EAI tool suite and attendant infrastructure elements put the approach out of reach. However, the project management team discovered many of the hidden costs in the proposed point-to-point development effort. The legacy system had 28 support people. More than a third spent their time fixing or maintaining integration to the 50 or so other systems in the application landscape. The proposed point-to-point solution would not eliminate the problems these people were addressing. Costs of running the point-to-point interfaces were buried in the single line item charge for using mainframe resources. It wasn’t until the individual batch jobs and programs were identified that the cost of running those interfaces became explicit. These costs weren’t even included in the cost of the new point-to-point proposal, but all the previous mainframe costs were assumed to go away! Once these elements were factored in, the EAI tool suite proposal became favorable and the project went forward.

Conclusion

Introducing EAI tools into an infrastructure isn’t for the faint of heart. However, the promised benefits and cost savings can be achieved and the use of the tool justified. A competitive advantage can accrue from developing a comprehensive architecture and common EAI infrastructure. The technical infrastructure should allow rapid reconfiguration of information flow between information systems to support an adaptive process infrastructure.