IN THE MIDDLE

Those Application Networking Nightmares

Sometimes we talk so much about middleware products that we forget that the real important stuff is applications. I recently researched some major- league applications from a networking perspective and found some interesting, or perhaps I should say depressing, results.

Major-league applications? Unlike baseball operations, application solutions from SAP America, PeopleSoft and Baan Co. are making major bucks. I haven't talked with a Global 2000 company in the last six months that was not planning to implement SAP R/3. Seriously.

These are mission-critical applicat ions. In fact, many corporations are buying rather than building these financial and human resources (HR) products and spending multiple millions of dollars to implement them. Applications like these get special project teams, huge budgets and high priorities. All possibilities for complete fault-tolerance are addressed with massively redundant hardware solutions. This all comes with a large software and hardware price tag, but that pales in comparison to the cost of the labor required to customize the product to specific corporate needs and fully install and switch over fromexisting solutions.

In fact, unlike many things most networking professionals deploy, the size of the budget and the impact on the corporation of a failed implementation of one of these p roducts could lead to early retirement--not only for certain employees on the project, but also for the CEO who approved it. (Maybe baseball could learn a few things from the corporate applications business after all.)

Networked Application A rchitectures Perf ormance of applications was easier to measure and control when everything was running on a single machine. But those days are over. These major-league applications have moved from mainframe to client/server implementations. And, predictably, application performance has become even harder to forecast or guarantee.

Fortunately, as these solutions have evolved from products developed in-house to shrink-wrapped products (well, mostly bought, not built), it's easy to see patterns in application performance by examining a number of customer implementations of the same application. I've focused recently on the networking performance of two of the biggies: SAP R/3 and the PeopleSoft HR applications.

Both are client/server, but that's where the similarities end. R/3 is a three-tier implementation; PeopleSoft is still a two-tier data-access solution. Let me explain.

R/3 keeps its data in a Relational Database Management System (RDBMS)--usually Oracle Corp.'s, but others are support ed as well. Application serv ers on Unix or NT run most of the business logic of the application itself, interacting with a single shared RDBMS for data. There can be many application servers, but only one RDBMS server. Given that the scope of these applications is the enterprise, that server will be a huge RDBMS platform. From application server to desktop client (Windows), R/3 runs its own proprietary middleware to the client.

While the application server-to-RDBMS connection is carefully specified to be something very fast, like FDDI (or even the internal bus of an IBM SP2 box), the connection to the desktop user can be across the entire enterprise network. Given the lightweight RPC-like interaction, I've seen implementations that have scaled well over WAN links of vario us sizes. R/3 benefits scaling by making good use of a three-tier architecture for an on-line application solution.

PeopleSoft's Application Networking Architecture PeopleSoft keeps its data in an RDBMS also--again, usua lly Oracle's but with support fo r others. But the desktop client runs all the application code; there aren't even any stored procedures on the RDBMS servers. PeopleSoft uses Oracle SQL*Net or other RDBMS native data-access middleware to connect from client to server. With the client making all the decisions on every bit of data processing, much more data travels out to the client and back to the RDBMS.

Moreover, by depending on chatty data-access middleware to support its application networking, PeopleSoft applications do not scale well over WAN links that have lower bandwidth and much higher latency. I've talked with numerous META Group customers who have tried supporting HR users outside the main office. One said performance for a few very light users over a 64-Kbps ISDN line was adequate. But no other customers said anything worked even adequately over any kind of WAN link. One customer said he was not happy with performance over 128-Kbps links for a few serious HR users in a few remote offices.

A lthough it is a genuine client/serv er tool, PeopleSoft's application architecture represents the early two-tier PowerBuilder model run amok: great application, but not an enterprise-scalable networked implementation. No wonder people complain about how disappointing all of this client/server stuff has turned out. Not only do applications that require all desktops to talk to a centralized resource individually not scale up (you can't build an RDBMS server big enough), but they typically don't scale out over real networks, either.

A Specific Case Scenario Another customer, just in the planning stages, was concer ned about how much bandwidth they would have to throw at an implementation that required two main sites, each with at least 200 HR users going at it. Given the priority and budget for such applications, t he customer is willing to allocate the necessary bandwidth.

Let's look at the economics. The customer has two major sites quite distant from each other. The T1 quote is more than $10,000 per month or $240,000 during the course of two years. This, they'll pay. But can anyone guarantee that this will be enough? I can't find anyone who's doing this. I talked with PeopleSoft, and folks there haven't come back with any WAN implementation of this size. (If you know of a successful WAN PeopleSoft implementation, please contact me!) Serious testing will be required to verify that a T1 line can adequately handle the load. (Will they have to double the WAN cost to $480,000?)

In situations where data-access, middleware-based applications aren't scaling over WAN links, I'd look at using a remote-control alternative. Products such as Citrix WinFrame and others can eliminate the chatty, latency-impacted data-access middleware bottleneck. But at $20,000 to $40,000 per Citrix Winframe server for 15 users (fast, larg e RAM NT boxes), it comes to between $200, 000 and $400,000 for 200 users. Although I've talked with customers who like this remote-control approach for smaller sets of remote users, a single site with 200 users isn't suited to this particular Band-Aid. There's more to break here.

I've looked into replicating the Oracle database behind the back of the PeopleSoft applications. RDBMS native replication isn't perfect for large numbers of distributed servers, but it sounds like it could be useful for a two-site implementation. Replicate between servers in each site, and point each site's users at their local copy. Unfortunately, I've yet to find a customer who's doing this, either, and PeopleSoft doesn't officially support such an implementation. It might work, but who wants to take on this system's integration task internally? I'm just guessing here, but wouldn't it also cost much more than $200,000? After all, you'd probably spend that much just on the second server, not to mention all the work.

Pe opleSoft Networking Futures PeopleSoft knows its applications aren't scaling, and it has announced plans for application networking architecture improvements. These changes aren't just Band-Aids, either--they're serious surgery.

First, the applications will be moved to a message-oriented transaction monitor (using BEA's Tuxedo) for interaction between client and server.

Second, the company is moving toward a multitiered implementation, where less data would move all the way out to the client. The tiered architecture would segregate RDBMS-intensive traffic to networks that can be easily provided and controlled centrally, (as it does in SAP R/3) while allowing the lightweight network-friendlier, message-oriented middleware to be used across the enterprise network.

Finally, PeopleSoft is working on Web-enabled versions of its desktop applications. Initially, these will not offer full functionality, but a subset as appropriate for some of the user population that needs access to PeopleSoft data. A thinner client for a thinner number of use rs.

PeopleSoft says it expects to complete this effort by the end of 1997. Customers could begin implementations in 1998. I'm hoping the new architecture won't cost another $1,000 to $2,000 per user like the Band-Aid solutions described above.

For the next two years, though, customers will still have to spend money on WAN implementation Band-Aids to survive with the existing PeopleSoft applications and its two-tier network architecture. It's either that or heads will roll.

Bruce Robertson is a program director with the META Group's GlobalNetworking Strategies service. He can be reached at BruceR@metagroup.com.