The objective is to find the objective. You read that right.

I read this paper last week: Charles J. Hitch. On the Choice of Objectives in Systems Studies. Technical Report P-1955, The RAND Corporation, March 1960. (pdf) (notes).

It's not a hard-math or hard-science journal article, rather just an Old Systems Analyst explaining the casual brutality of how high-level objectives are typically very vague (think: what is the objective of a nation?) but are necessary on some level in order to derive lower-level objectives (think: what kind of defense systems does a nation require?).

As systems engineers, one of our key jobs is to figure out what the hell it is that a stakeholder wants. Stakeholders know quite a bit about what they want, but not everything, and some of the things they think they want they can't put into words, or one thing conflicts with another, etc. So part of the job is helping the stakeholder figure out what the stakeholder wants, which involves some understanding of what the stakeholder's stakeholders want, and so on. (Never mind that I decided to skip an important part of the definition: who or what are the stakeholders—a major unasked question will arrive with its own answers anyway, later, at a more inconvenient time in the life cycle when you thought you were done.)

The obvious thing that system developers try to do is just receive the objectives from on high, Moses-style. Hitch explains three reasons that doesn't work:

1. Impossible to define appropriate objectives without knowing about the feasibility and cost of achieving them, which is derived from the analysis itself
2. High-level objectives tend be non-existent or so vague or literary as to be non-operational.
3. Objectives are multiple and conflicting, and alternative means of satisfying any one are likely to produce substantial and differential spillover effects on others.

So what does the analyst do? If he can't find anyone to give him acceptable objectives, where does he obtain them? The only answer I have is that learning about objectives is one of the chief objects of this kind of analysis. We must learn to look at objectives as critically and as professionally as we look at our models and our other inputs. We may, of course, begin with tentative objectives, but we must expect to modify or replace them as we learn about the systems we are studying -- and related systems. The feedback on objectives may in some cases be the most important result of our study.

It's hard work to figure out what the point of a system is. But it's the most important work. It's a fork in the road you can't come back to later.