Better information systems — VPEC-T

VPEC-T (you ... er ... what?)

This article is about an important approach to business analysis for information systems which has proved itself in the field. The approach covers the vital time before the technologists start working on how to change, acquire or build the system, and it shows why what is done then can determine the success of a system. Here you'll find a description of the heart of a framework for thinking called VPEC-T, backed up with a mind map of a remarkable book about it.

I've been an information systems practitioner for several decades now. For the first few years, it was only the technology that interested me. I can't say I cared much about what the business was doing with the software I built, so long as I could stay late into the night and have a computer to myself. Because that was how it worked way back then. Days were spent coding, making test data sets, hand-calculating expected results and reading code. Nights were for testing and fixing. Sleep? Chuh! Don't make me laugh. Back in the day I was more than once stopped by the police wanting to know what I was doing, while driving home at 4 or 5 a.m. As it was Switzerland, the police always demanded my passport.

IBM/360 The pumpkin was bought for a Halloween party, and I thought it would make a good picture (IPL= Initial Program Load - a bootstrap process we had to do at 00:00

IBM/360. The pumpkin was bought for Halloween, and I thought it would make a good picture (IPL= Initial Program Load - a bootstrap process we had to do at 00:00 under pain of death).

Before long, though, I realized that businesses that paid me were doing some interesting stuff with the information processed in the systems I helped to build. My focus started to move. Then, working as a consultant let me through the doors of hotels, insurance companies, satellite launch vehicle manufacturers, international courier services... and many more. There were striking differences but ...

... common features started to emerge:

Values

The businesses were only interested in information (and the technology to process it) that brought value. Seems obvious, but system developers often didn't give it a thought. And importantly, the value yielded was different to different people in the business.

Policies

The businesses imposed policies on how the information was processed; so did outside regulators in many cases. This affected the design of information systems but often these constraints were not mentioned until late in the implementation of a system. The resulting late stage changes almost invariably decreased the quality of the design and stability of the system.

Events

The businesses only wanted to process information when certain things happened: A customer called; an order was taken; some stock started getting low. But often the computer system didn't know about these happenings until someone started processing something, and even then, to the computer and its operators, it was just data coming in or going out.

System after system in large enterprises were added to meet the needs of specific units, groups, departments or regions. Often there was overlap, and keeping track of where information comes from, goes to and is duplicated became a significant burden and one that grew exponentially. I know this from getting my hands dirty mapping out systems, data flows and system interfaces for clients. I have had to prepare data models for companies wanting to rationalize all these systems, particularly during expansion and mergers.

Working from business events means that the perspective changes. You look at what services are needed to handle those events across the business, instead of what this department does, what that department does and how, if at all, they communicate.