Note: If you’re already familiar with branch networking and Virtual Desktop Infrastructure, you may wish to skip ahead to the next article on Branch Networking with Scanners and Peripherals, or Practical Applications of Networking in and Beyond the Branch.
“The Networked Branch” is a topic that’s been getting a lot of hype in the banking community lately – but why now? What about it is different from the way branches have always been run?
After all, bank branches – and the computers inside them – have been connected to “networks” of one sort or another for decades.
In short, the type of branch networks and the scope of the data that’s sent over them have both evolved dramatically in the past 10 to 20 years – and in the process, opened the doors to astounding new efficiency gains at the teller window and beyond.
In this article, we will attempt to answer the following questions, for those new to the concept or who are in the beginning stages of exploring their branch networking options:
- What is a networked – or Virtual Desktop — teller station, and how is it different from a regular teller station?
- What advantages are gained from using a virtual environment?
- What kinds of IT challenges will be experienced by using this type of environment in my branches?
- Will connectivity be an issue?
Introduction: How We Got Here
The term “networking” is often used by the mainstream media to describe an important change in the way modern bank branches are run – but that’s a bit of a misnomer, because the network itself is not what’s new or interesting. For those who possess some familiarity with the IT side of things, the exciting part is the move toward Virtual Desktop Infrastructure, also commonly called “VDI,” or simply “virtual machines” and “virtual environments.”
To be more specific, let’s turn back the clock 20 years and look at a bank branch circa 1998. In all likelihood, such a branch would be operating in a networked environment – just a much different kind of network than what we’d see today. A common arrangement would comprise a standalone PC at each teller window, with most of the transaction processing and other work taking place locally on that machine. Each PC would periodically post updates to a central server with key transaction data and other information. This has commonly been known as a “thick client” environment.
Eventually, some banks began setting up servers inside individual branches that would collect information from the tellers’ PCs in real time and store it for transmission to the main data center. (This arrangement was known as a Client Server architecture; in today’s parlance, it might simply be called a Local Area Network, or LAN.) The teller workstations were still standalone PCs, though, and most of the work continued to be done right there at the front line. The branch servers allowed the LAN to keep running reliably, regardless of the connection to the central office.
As network reliability and bandwidth improved, it became feasible to have the individual workstations communicate with a central server in real time – and to use Virtual Desktop Infrastructure rather than having a full-fledged PC at each teller window. This means all the applications reside on the server, and instances are called up in a virtual environment on the workstation. This is what is commonly referred to as a “thin client” environment. The boldest financial institutions may have started making this transition in the mid-2000s, with the practice becoming more common over the intervening decade.
While there have been modest changes to the configurations of the networks themselves over the years, the big story has been the shift to virtual desktops because of the network reliability, speed, and bandwidth available today. In essence, more data can be pushed through a bigger pipe at faster speeds, with more uptime reliability to the connection.
What’s the difference between a virtual desktop workstation and a regular teller station?
In simple terms, the difference is where the “brain” of the computer is located. Try thinking about it as the difference between watching a movie on your home DVD player or streaming it using a Google Chromecast or similar device.To watch the DVD, you would need a moderately complex device that can read the disc, convert it to a displayable signal, and ultimately transmit it to your television. Just as importantly, you’d need a physical copy of the movie. If you wanted to play the movie on two screens, you’d need two DVD players and two copies of the movie; if you wanted to play it on 100 screens, you’d need 100 DVD players and 100 copies of the movie. (If the analogy isn’t clear, the “DVD player” is your teller station’s PC, and the “copy of the movie” is the teller software.)
If you stream the movie, you only need one “copy” of it on a central server, no matter how many screens it’s being played on. The streaming device mostly acts as a pass-through for commands going upstream and video going downstream, so all it needs is some very rudimentary computing power, and a way to receive and execute commands.
A networked branch works using the same principle: A central server – usually located outside the branch at a data center – runs all the important software and handles the transactions, while the teller uses a barebones workstation whose main purpose is to funnel information back and forth to the server.
As we mentioned earlier, until recently, the “DVD player method” was the usual way to run a branch, where every teller station had its own standalone computer running its own software. As Internet bandwidth and uptime have become less of a constraint, networking has in turn become much more practical. As you hopefully noticed in the above example, it offers some very clear-cut advantages over the standalone environment.
What are the advantages of running a virtual environment in your branch?
The two main benefits of a virtual environment are, in simplest terms, cost and security. Cost, because the individual machines used by the tellers are less expensive and easier to maintain from an IT perspective; and security, because each workstation is very limited in what it can do on its own. As those familiar with virtual environments, such as Citrix, can attest, the “real” computer in such a setup is the central server, with the workstation simply acting as a go-between that transfers and displays information .
To illustrate the benefits of this cost and control, let’s look at the possible failure points in a centralized setup versus a distributed one. (If it helps, think of this part in terms of using 100 standalone DVD players versus streaming a movie to 100 screens.)
If you’re using the standalone approach, what happens if one of the machines malfunctions or there’s a problem with its software? You’d need to diagnose and troubleshoot that specific device individually with its added complexities in having to run multiple programs, drivers, APIs, etc. With the centralized approach, there is little to no local software to have hang-ups, and few things that can go wrong with the device.
The crux of it is: It is much easier to operate one physical machine running hundreds of virtual instances than it is to maintain hundreds of individual machines separately.
Then there’s the matter of security. What if a computer was stolen? With a standalone setup, you’d lose the device and whatever data was on it. With networking, you’d lose a cheap barebones machine; you’d still have access to the same software – and, very importantly, whoever stole the device WOULDN’T have any of your data, just a piece of hardware that was mostly useless to them.
The same principles behind a movie-streaming service therefore apply to networked devices in a branch: The fewer “moving parts” there are on the front end, the less that tends to go wrong. If your bank is using standalone workstations at each teller window, it is at the mercy of the whims of each individual machine and each individual operator – you’re essentially running a help desk for hundreds (if not thousands) of users. In a Citrix or similar virtual environment, the whole teller workstation is “on rails,” taking operator error and front-end technical problems mostly out of the picture.
The most likely problem would be trouble with the central server or the network connection itself – but from an IT perspective and with built-in redundancy in the system, there is less risk of downtime, and it’s much easier to address a problem one time at the source, rather than hundreds of times on each individual workstation in the network. Similarly, most software updates, patches, and security measures can be handled centrally on the server, rather than pushed out to every branch and every workstation individually.
What are the IT challenges of a virtual environment?
One concern when exploring a virtual branch environment for the first time is depending entirely on an Internet connection to work without fail. No one wants to be completely at the mercy of a third party to conduct their day-to-day business.
Yet, think of how many businesses in general already rely on the Internet for critical tasks on a daily basis, from ordering supplies, to booking appointments, to running the website, to accepting payments, to operating the VOIP phone systems, and more. It’s almost all of them!
For that matter, even a bank branch running a “traditional” desktop environment with standalone PCs faces serious, potentially paralyzing problems if its external network connection goes down. In that respect, using a virtual environment does not expose you to a much higher chance of failure than other setups you might be using today.
Back in the days of dial-up and DSL, network reliability was a legitimate concern – in fact, in many parts of the world, it still is. In North America, though, fiber-optic broadband networks have advanced to the point where reliability isn’t an issue, even in the more rural and remote areas of the country. See our case study on Security First Bank, a regional bank with branches in dozens of small towns across South Dakota and Nebraska, for an example of networking under extreme distance and infrastructure conditions.
In addition, it’s usually possible to add redundancy to your network connections when your business really depends on it. Many ISPs offer a service called Multi-Protocol Label Switching, or MPLS. In simplified terms, this is built-in redundancy that re-routes Internet traffic through an alternate path when the most direct connection is interrupted. Some banks will also employ a second ISP connection as a backup, in the event of an outage on the main service. In the worst case, networked branches will have provisions in place (such as a backup in-branch server) that allow them to operate offline during an outage, and then upload the backlog of transactions in batch format once the disruption is resolved.
In short, the connection from your ISP is generally not a major source of worry when you’re running branches virtually. In 2018, we are fortunate to be in a position where reliability and uptime CAN very nearly be taken for granted – and can be nearly 100% ensured with a few precautions.
The other part of networking that might take some getting used to is how the individual workstations are operated; this is usually accomplished with a virtual desktop system, such as Citrix or VMWare. While this has become a fairly common practice in the corporate world, it may represent a sizeable project if it involves changing operating systems, for instance.
A big difference between this type of environment and a more traditional one, though, is that the workstations are designed to work as a pass-through, with little or nothing installed on them. That’s usually fine, as far as your core banking systems are concerned, since that software is written with various operating systems in mind, including virtual desktop environments. It can become difficult, however, when it comes to external devices that MUST be plugged in directly to the barebones box itself. In the specific case of check processing, the way the raw images are handled presents a serious challenge, as we will explain in the next article.
Fortunately, we’ve developed ways for our check scanners and printers to get around these limitations and “drive themselves” within a virtual desktop environment. Read on to find out more.
