Simple and Lasting Ideas on Managing Information Systems
Years ago, when I was a student I was assigned a textbook. It was an introduction to Business Computer Systems. The author’s—David M. Kroenke—books were (and still are) used in undergraduate computer information systems and master’s level business courses in management information systems.
This post is about something that I learned from that author that I have come back to time and again. I found it to be a simple and lasting idea that I have built upon over the years.
Not a Model, Just a List with Details
What I found in that textbook was a description of the components of a business computer system. Kroenke was careful not to call this listing of items a model although he might have easily done so. He could have created model depictions like the model of a profession or an IT governance model. Instead, he kept his list simple and elegant. And, keeping it as a list didn’t introduce the risk of confusion through a graphical depiction like a concept chart.
What’s in the List?
Kroenke’s list, the components of a business computer system, included:
- Computer equipment or hardware
- Programs
- Data
- Procedures
- Personnel
With Kroenke, computer equipment included a discussion of input, process, output and storage. For programs, there was just system and application1. Data included input, process, output and stored (not storage like hardware). Procedures were system use (the users) and system operation (the operators). Finally, personnel were system developers, operators, users and clientele. This list is so simple and easy to build upon.
How I Use it
Over the years, I have used this list as a tool to better understand IT. A few years ago, I needed to understand a class of software associated with business rules. I discovered that this software took two forms. One form utilized previously defined business rules in a running system whereas the other form extracted them, imagined them if you like, by reading source code and reverse engineering the main idea. To help me deeply understand rules software, I used the Kroenke list of components in a checklist manner.
Where did the software run? This told me if the software ran on mainframe, distributed or PCs. What data is used and where is it stored? I discovered that rules were stored in a keyed file or database for access. Other data was extracted from the source programs. How were procedures impacted? Business rules had a big impact on procedures. When the business changed the rules changed not the programs themselves. Having rules accessed by software meant having rules administrators to manage them. Procedures changed significantly because of the software. What about the impact on people? Business rules involved learning new programming skills. For those who had old systems replaced by new ones facilitated by business rules extraction, they needed to find a new role with the replacement system or find a new job.
I will explore other useful models in the weeks to come. Do you have a model that you have used time and time again in your work?
Note1
When exploring a new kind of software and you want to answer the question—“where does this software fit into the big picture?” see IDC’s Worldwide Software Taxonomy. In 2016, Henry D. Morris made the update in July. The IDC publication number was US41572216. IDC updates it annually and you can generally find at least the table of contents on the web without requiring payment. Kroenke listed two kinds—system and application. IDC lists (1) Applications, (2) Application Development and Deployment and (3) System Infrastructure Software as its top categories.