R.S. asks: >.Gentlemen, >I'm getting lost. >What does it mean "front end switch"?
The common vernacular in this particular field is to describe that front-end system as an "ATM switch" (for example). "Switch" should not be taken *too* literally, though. But "transaction processing" is a bit too strong, generally speaking, so it's not a good term either. (I prefer something like "front-end queuing system," but there's probably no perfect term.) The system of record with the "correct" bank balance is the back-end. Basically if the back-end is down the front-end stands in to provide a more limited set of services. (That "negative file" described elsewhere in this thread is an excellent example.) There might also be a lower withdrawal limit, funds transfer between accounts may not be available, account balances might not be available, etc. Some organizations refer to this reduced service set as "degrade mode." (We used to describe a bank branch that way when the network connection to the home office was down -- degrade mode would apply, and the teller could provide up to maybe $100 in cash per customer. The branch IT systems and back office systems were engineered to work around the unreliable network connections.) When the back-end comes back up it works with the front-end to reconcile whatever happened during the outage. That probably means some account holders have overdrawn their accounts, and so part of the reconciliation includes getting those accounts over into whatever exception processing the bank has in such cases. There's also probably more fraud, so that falls into another exception bucket. Now it's not THAT hard for a bank to move away from a physically separate front-end toward a logical (virtualized) one. I've pointed out earlier the many reasons driving the trend to simplify. Another one is that this ATM switch function is peculiar to one channel. Banks and other financial service companies are seeing their channels multiply. So they can either buy more front-ends -- which have always been a second-best option even in the best of circumstances anyway. Or they can improve their back-ends to deliver something much closer to continuous service. Or at least they can place the front-ends logically on shared, highly available infrastructure rather than maintain separate boxes with alien software. If the only high service level business involves the ATM cards, that's one thing. But that's not a good description for modern, integrated banking in most countries, and it certainly isn't the trend. Said another way, if the global trading applications for stock exchanges require 24 hour SLAs -- and an awful lot of banks have global investment arms -- what good does it do for those applications to have a front-end ATM switch? Absolutely nothing of course -- a channel-specific switch offers no benefit to other business channels -- and the only value the ATM switch provided was to fix the SLA for core banking, and only for a limited set of services, and only with higher rates of exception (read: more expensive) processing. So if you improve the SLA for one class of applications, you're probably also improving it for others, and the others get the improvements essentially for free. (Well, this is true for IBM mainframes. It's much, much less true with distributed systems.) Then it becomes tough for any business to justify spending money on a front-end when the improved SLA on the back-end is "free." Whether you're seeing these particular trends at your bank or not is interesting, but from an industry view I think this is a reasonable (and unsurprising) generalization. (Certainly the biggest application provider in this market, ACI Worldwide, recognizes these trends.) And you shouldn't be surprised when you start to see these trends hitting your bank in the coming years if they haven't already. There's an awful lot of pressure in the banking industry to gain efficiencies, reduce costs, and improve service levels. The alternative I suppose is that you could shift the back-end logically over to the front-end. But in the case of IBM System z and HP NonStop, the back-end is a heck of a lot bigger with a far richer function set. System z is a broad scope application hosting environment for general business applications using an increasingly wide variety of middleware, programming languages, run-times, etc. That just isn't HP NonStop: never was, and, with each passing year, ever decreasing. So if (when?) you're going to move one side to the other, there's only one realistic direction here. Make sense? I really don't think this is surprising or that this line of thought is particularly profound. It's just common sense. I don't think this is even surprising to HP, which seems to be attempting to reposition HP NonStop in the role of a front-end queuing system for distributed systems, to fix SLAs for a limited set of services using a dual-platform strategy. Of course you can do that with a System z mainframe, too -- most people here are probably doing this already, whether you've thought about it quite this way or not -- and I think there are some strong arguments why z is a better idea. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
