Applications Knowledge: ‘Innie’ or ‘Outie’?

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:

• Programs were written in COBOL.
• Programs were run in-house on a mainframe.
• Very few applications existed; usually deposit accounting, loan accounting and perhaps general ledger.
• Most bank functions were manual.
• Terminal devices were character-based dumb terminals, typewriter terminals and a few impact printers.
• Large quantities of green bar paper were used for reporting.
• Specialized reports required a programmer to design, write and implement a program, often taking months to complete.
• Data processing was seen as among the “black arts,” difficult to deal with and communicated in foreign languages.

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:

• Systems are developed by a vendor to be run in-house or by a service bureau. In most cases, the program code is not made available to the bank.
• Programs (collectively “systems”) are run on multiple vendors’ platforms both in-house and outsourced.
• Application counts have exploded from a handful to a hundred or more.
• Most banking functions have been automated.
• Virtually all applications use some form of graphical interface.
• Very few paper reports exist; most reports are accessed on line or from an optical system.
• Specialized reports can be produced via specialized report writers that many users have mastered.
• IT is seen as among the “black arts,” difficult to deal with and communicated in foreign languages.

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:

• Asset liability management – risk management or finance
• Consumer loan origination – retail bank or consumer lending
• Commercial loan servicing – loan operations

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.

1. Application knowledge belongs to the IT group if they designed and developed the application.
2. Application knowledge belongs to the group that is the heaviest user of a system provided by a third party.
3. Application knowledge belongs to IT for those applications used by many bank organizational units.

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.

• Make sure this part of their jobs is identified in their job descriptions.
• Make their command of the application a part of their evaluation.
• Make training resources (that’s budget dollars for the uninitiated) available.
• Encourage attainment of certifications in the application if available.
• Require attendance at recurring user meetings to network with other users.

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.
-caf