Mission Critical Applications and Web Based UIs?

Jonny Quest asks: "I work for a company with an excellent Client-Server based product. Unfortunately it's not 'Web-Based' (whatever that means). Ours is a 'Line-of-Business' app, i.e. it means that those people who use it absolutely depend on it for making money - if the app is down, they can't process their orders, service their clients & employees, etc. at all - mission critical in other words, and they spend ALL day in the app. What's the best UI that any Slashdotter has seen for a 'Web Based' app? Something with a rich user interface and some decent multiscreen handling (the current app has about 200 screens...)?" 'Web-Based', that's such a loaded buzzword, and like most buzzwords no one is really quite clear on what it means. Does it mean HTML+CGI? Does that allow for Java? Cold-Fusion? Internet operation or just Intranet (if it's mission critical, it better be the latter, and even then...)? Would any of you recommend deploying a mission-critical application over the web? If so, how would you do it? What technologies would you use and what is to be avoided at all costs?

Comments

Some Lessons From Financial Apps

[rjsjr]

I've spent the better part of the last six years building, designing, and consulting about web and java mission critical applications for financial markets professionals. With billions of dollars on the line, very impatient users, and fast moving markets, you get just about all the nasty problems possible. There are few hard and fast rules for these types of problems, but here are some tips from my experience:

• Rely on the web for lightweight interface only. Browsers and client side java are notoriously flaky, try to make the web connection a lightweight view on your delegates or model/controllers in a reliable environment. This means no CGI, at a minimum put your environment in mod_perl or ASP (ugh!). Given the complexity you seem to be suggesting (order processing, etc.) it would seem that a java application server (e.g.: weblogic/websphere) or serverlet environment (tomcat/jakarta) is probably in order.
• Recover quickly and gracefully. When the browser dies make it easy for the user to navigate back to their previous interface/state with a minimum of hassle. A bookmark back to their previous position(s) is often nice solution and should work across machines (i.e. don't rely on cookies). Don't let business logic and controllers die just because the view drops off (but you do need to have some cleaning logic to keep from bloating out from bad sessions).
• Stay away from the browser's cutting edge. As tempting as it is to use the newest DHTML, plugin, and other tricks, you usually create far more problems with crashes and compatibility than you solve by more flexible or dynamic interface elements. Understand your users system capabilities and don't overrun their capabilities in HTML version, table sizes, interface speed, or additional features.
• Organize your screens by users's tasks. Its all too easy when writing applications to fall into the trap of checking off functional elements and then throwing this set of screens at the user. Users work far more effeciently if you can analyze their business process and organize a set of screens around their work. This is especially important at an app as big as you mention (200 screens) since the users can end up having to spend all their time finding the right interface to complete the next task. You may end up duplicating many interface elements, but you should be building a modular enough interface to make that inexpensive development wise.
• Build a strong, reliable server environment. Mission critical applications are not to be taken lightly, build a server environment that can recover gracefully from parts failing on the fly. This probably means that your web servers, application servers, and database servers all need to be clustered from the start.
• Emphasize a careful rollout process. As easy as it is to make changes to web applications, developers are tempting to forgoe real versioning and testing and just roll out new changes. If this really is mission critical you have to put a real process around change management, it gets very easy to screw up critical elements without realizing it once you get a pretty large and powerful web application.

So what are some good examples that accomplish these tasks? Well, there aren't too many that I'm really fond of out on the public networks, but the online brokers (etrade, schwab, datek) are a reasonable start. They have lots of information, pretty good workflow, and fairly robust and clear problem handling. Webvan was pretty good when it was around (relatively simple though it was), but there were too many hierarchies to navigate.

Good Luck, Robert Seymour