The Springboard Twist: Deductive Business Logic

One of the things you may discover is that business analysts and project managers often fail to draw parallels between the conceptual basis for software development and any other fields of study. As a humble (huh), and reasonably well rounded individual, I couldn’t help but notice one striking parallel between how software projects are driven and something you rarely hear about within IT circles: Logic.

No - not programming logic. No not EPROMS. I’m talking about the branch of philosophy called Logic. You know - that thing at which the fictional characters Sherlock Holmes, Mr. Spock, and Mr. Data excelled. Believe it or not, there is a parallel between the logical notions of induction and deduction and the IT problem of how to arrive at business value through the process of software development.

Call me kooky, but I think there really such things as inductive and deductive business logic, and if you want to find out which logical form gets you to business value nirvana more easily, then keep reading.

Induction and Deduction

There are two major branches of logic: Induction and Deduction. Induction is the logical process of using specific facts, observations, or Instances to derive general principles. Indeed - inductive logic provides much of the logical foundation for the Scientific Method - in which scientists develop theories based on specific, direct observations. Deduction, on the other hand, is the process of drawing inferences by reasoning from general principles to specific facts or instances.

So, in Inductive logic, the starting point is that of specific facts, observations, and instances, and the goal is to derive general principles of reality given these facts. In deductive logic, the starting point is knowledge (or assumptions) about existing General Principles or rules about reality (such as the law of gravity, or the Pythagorean theorem) and determining what specific facts must follow given these rules (what will happen if I let go of this pen? What is the length of side of a triangle with two other sides having lengths of 3 inches and 5 inches?)

If you were to draw a simple diagram with General Principles in one box above a second box to represent Specific Instances, then Inductive logic is the process of reasoning from the bottom up to the top. Deduction, in this model is a top-down reasoning process. The terms “top-down” and “bottom-up” appear in other fields as well. In cognitive psychology and neuropsychology, top-down processes are also called “Effortful, Executive, or Schema-Driven” processes, while bottom-up processes are known as “Automatic, or Data-Driven” processes.

Applying Logic to the business of Software Development

Most businesses see software as a necessary, strategic imperitive. Software is the one thing that can provide competetitve advantage while potentially providing real savings to the business.

Unfortunately, too many businesses struggle with how to generate real business value from the process of software development. This struggle has real costs - wasted time, incomplete and imprecise requirements, and a general disconnection between the business purpose of performing development, and the specific things that get developed

In my experience, it has helped to apply a bit of logic to the whole process as follows. First, let’s draw the parallel

Deductive Business Logic is the process of drawing inferences by reasoning from a Business Vision to Specific Processes or Implementations that achieve the vision.

Inductive Business Logic is the process of reasoning from specific Processes or Implementations to derive a Business Vision.

Note how the the notion of inductive and deductive logic from the previous graph maps into business logic of software development. These are “isomorphic concepts” meaning they have the same logical structure.

The Deductive route is Top-Down: Driving the project from Business Vision toward implementation. The emphasis here is on the Business Vision, and allows direct mapping of Business Value to specific implementations and processes.

The Inductive route is Bottom-Up: Driving the project from implementation, and attempting to map to or derive a business vision from this activity. The emphasis here is on the implementation, and this process provides no clear mapping to a business vision without additional top-down work.

One method is not necessarily better than the other. It’s my opinion that, whenever possible, you should drive things Deductively, since that it places more emphasis on meeting the Business Vision. In my experience, it can help get a project on track if you ask your project team: Is this initiative being driven deductively or inductively (Top-Down or Bottom-Up), or are we sleepwalking through the project? The answer to this question can help you adjust the project so you can achieve the business vision for your project - and arrive at the business value your project stakeholder are demanding.