My fellow GonzoBanker writers get nervous when I emote about organizational issues. They sincerely believe I should stick to the “techie” articles – the articles used by many bank executives as a cheaper, more effective remedy for insomnia. Be that as it may, my many years leading technology organizations gives me license to weigh in on this issue.
Where should applications knowledge reside? Many banks have simplified their response by putting all applications knowledge within the information technology function – an “innie.” Others have swung the other direction and ensured applications knowledge is maintained outside the IT organization – an “outie.” Understanding a bit of history will help your perspective on the issue.
In the IT Stone Age, circa 1960s and 1970s, banking systems were custom developed by the in-house data processing staff. Do you remember the days when IT was called data processing? Characteristics of these systems included:
At this stage in the developing role of technology, all applications knowledge was housed in the data processing function. Of course, this made all the sense in the world. A programmer and perhaps an analyst worked with the business area to gather requirements and design outputs. Their work ultimately became the computer systems used to process deposit or loan accounts. Their depth of knowledge was unmatched in the bank, and they could be relied on to answer any question about the application. Not surprisingly, one of the most important risk management concerns of bank management was to ensure these key staff members were not run over by a truck. If they were, their knowledge would be lost forever – documentation of these systems was woefully lacking.
Contrast the data processing approach to today’s information technology approach. Its characteristics include:
Contrasted to the Stone Age, today’s picture is different in two very important aspects:
• Very little application programming is performed by the IT group.
Well fine, but without being architects, how can IT staff members gain the level of knowledge required to support an organization’s systems? How can we expect them to answer detailed user questions?
• The number of applications has ballooned from a few to hundreds.
Is it fair to expect the relatively small group that makes up IT to be “experts” in so many systems?
At this point you have likely determined my bias for where applications knowledge should reside, but hold on – you may be wrong.
Given this change in how technology is delivered in the modern bank, several factors must be taken into account when making the “innie-outie” decision.
1. Where was the system written?
If the IT group wrote a specialized application for the commercial lending group, by all means, IT should provide support for the product. So give this one to information technology.
2. Who are the most intensive users of the system?
Support for a specific application should be the responsibility of the group that uses it most. Take the teller system as an example. Assuming your bank is using one of the commercially available products or one provided by your core system provider, the retail bank or branch system are the heavy users. Some other examples:
3. What about applications that are used across the organization?
This case is not as clear-cut as the first two. First, determine if there is a place in the organization that houses the heaviest users. If there is, make that group responsible for the application. However, consider the image system used to store system reports. Virtually everyone in the bank uses this system. This would be a good case for placing support into a centralized group, such as IT.
Let’s recap the rules for clarity.
You can now more easily determine where application knowledge should reside. Observing a few guidelines will make success more likely:
For every system/application, identify the primary and backup individual responsible for knowledge of the application.
GonzoBankers, this is not as tough as it may seem. I know that for some organizations, this will be pure heresy. Relax, IT folks. Give up a little control and put the knowledge where it belongs.