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?

KISS

[eric2hill]

Keep it simple. Mission-critical applications should be lean applications that do nothing more than their designated task. In the OO model, you need a main collection of objects that perform very specialized tasks relating directly to the business process.
I'm sure you probably have a good idea of what those processes are right now, and as long as you can isolate them, you're home free. Once isolated, you can quickly/easily wrap them in a traditional GUI, web front end with PHP or Perl, and any number of "other" interfaces such as eMail.
Make sure you're core logic is tested well, and put in shareable modules (DLL's on windows), and use that logic many ways. If you ever have performance problems, it's due to the technology you're using. Just switch to another type of interface (different development tool, etc.) and see how that works out.

Intranet and Internet

[Malduin]

I work in the Client Services department of a fast-growing media company and am also doing the same type of work. However, I started out doing everything web based so that everyone with a decent, later version browser can use our mission critical system. It includes tracking fulfillment status, client relationship management, monitoring, catalogging, and many other management utilities that go with our business. I have been developing this site for a few months now on an intranet server. However, there is a need to outsource some of these utitilies when we outsource our help desk support or employees need the information on road trips. This called for an intranet development server where the development goes on and an internet production server that has the stable functionality of the system and gets updated after each milestone. Personally, I think it's a fairly nice way of implementing a mission critical system but would also like to see what other /.ers think.

BTW - If your curious, I wrote all the server-side stuff in ASP (we're practically married to Microsoft). However, my boss also wants to have a mirrored copy on a Linux server written in PHP so a case like another Code Red incident won't wipe everything out.

Hmmm..

[technos]

Your reference to 'screens' makes me think you're running what amounts to a terminal interface from an AS/400..

In that case, you'd do well with a simple GUI wrapper. Seagull Software sells a decent one. The newer stuff supports what people call a 'web-based' interface, as opposed to just a guified wrapper. The end interface can be as flexible and different as you like, with the capability for users to fall back to the regular old interface when it suits them. Try http://www.as400.ibm.com/developer/tools/web.html# group4 [ibm.com] for a reasonably complete list of 'wrappers'

Mission critical and web-based apps? Nahh...

[Crewd]

I work for a mega-corporation that was affected by Code Red. Many lines of business here depend upon web based applications to do their job. What happened when port 80 was shut down so that Code Red wouldn't spread itself? Mission critical applications were shut down at the same time until they were brought up on ports other than 80. I am glad to say that the traditional client-server app that I run for my line of business what unaffected.

If it's mission critical, stick to traditional client-server!

Crewd

Re:Mission critical and web-based apps? Nahh...

[biglig2]

If it's mission critical, why'd you let there be servers that weren't as patched as patched can be on your network?

Re:Mission critical and web-based apps? Nahh...

[Crewd]

Unfortunately, in the mega-corporation, people don't normally have administrative control over all the servers in the organization. Everything on my network was patched. It's too bad there are incompetent administrators out there that don't patch their machines....

Crewd

web interfaces save here, lose there

[SirSlud]

Code Red deal not withstanding (and c'mon, its not like viruses ONLY affect web services, both in the past, and in the future), the web is an absolutely brutal platform for intelligent, scalable UI. So if you value the accessibility of a web interface enough to go forward with it, remember to get yourself a UI expert who knows web interfaces backwards and forwards. Most traditional UI people will bastardize web conventions, and most programmers with some level of UI will simply not be able to handle finding the right compromises. But a well-thought out, planned and scalable web interface /does/ end up offering some pretty serious advantages, three of which I can think of right now:

a) available through the browser (duh)
b) usually the display layer is done in a high level language, so you save on development time and headaches here over more low level UI platforms (heed what that other guy said above about pulling all the core logic into a tightly formalized set of componants)
c) people are familiar with the web, so some of the tasks they may have to accomplish through your app they will already be familiar with

I recommend using something server-side like PHP or Java to control your display layer .. just remember to keep it seperate from your business logic interface, and you'll thank yourself down the road.

Re:web interfaces save here, lose there

[SirSlud]

oh, and by java, I mean using server-side java to generate your HTML ... I am not endorsing Java's AWT or Swing here (nor should anyone else in their right mind.)

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

Lessions

[bluGill]

"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network."

-Tim Berners-Lee in Technology Review, July 1996

I mention the above cause I'm working with a product now with a web based interface that only runs on ie 5.5 with the latest java upgrades, on windows. Of course many of our customers are unix shops.

the above aside, Java is slow, at least in our implimentation. Running across a 56k modem is an exercise in frustration. I don't know how much of this is just our implimentation, but it is at least something to watch for.

Ask this question: Is there a 20% functionality that the users spend 99% of the time with, and for the other 80% you can give a difficult to use (but quick and easy to impliment) interface. Perhaps your current interface for those who need everything, and web based for the most common things.

What I think is best is a web based interface that users can use when they are working from elsewhere. At the office use your system, when on the road or working from home use the wbe based system which will let you do everything you normally do. For the few things you can't do from the web visit the office once a month.

Identify who is likely to use this. A salemen on a different continet working from a customer site via a satalite connection (long delay) might find the web base system better if implimented right, and might need functionality that everyone else doesn't need. Work from home users probably just want an interface that works on their chosen OS (mac, beos, windows, linux all come to mind, but others are possibal), but is on a fast (ok, dsl) link so speed isn't such a issue.

Once you know who isn't well served by the current interface, then you build one to fit their needs.