comments on Rob Hanna's white paper

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

Here are a few comments that I noted while reading Rob's white paper. First his diagram, for reference, slightly edited (the image is also attached). Might consider making more of the arrows bidirectional; the loop from Result to Objective is omitted (comment below).

 

 

1 Objective

 

The label on the "Objective" node was missing.

 

2 Resource, 3 Task, 4 Skill -- No comments.

 

5 Concept
"The concepts object defines the complete set of
terminology used within the environment. Terms defined
here can be used throughout the environment."

 

This is merely a glossary of terms. The notion seems to be that the definitions of terms that are essential to the domain are statements of (all the?) concepts that are essential to the domain. However, this perhaps debatable contention is not explicitly stated.

 

Certainly, it is necessary to master the terminology and the definitions of objects and relations of a field. Many a glib shyster has "passed" on no more substantial skill than that--until they have to actually do or produce something. Typically, a definition in a domain is stated in the sublanguage of a logically prior domain.

 

Other conceptual information is in the Rules, Requirement, Specification, and Design objects, then? What of conceptual information associated with a process, a procedure, or an action?

 

6 Rules-- no comments.

 

7 Action

"Actions [sic] objects include processes, procedures, instructions, and test plans." Nodes in the "human capital" and "physical capital" triads must correspondingly shift scope, and they must also scale insofar is a process is a sequence of procedures (or potentially a sequence of processes).

8 Result
[...]
"While it appears as a terminal node in the model, it can
ultimately link back directly to a new objectives object."

 

The link back is not shown. This could also be represented as one such pyramidal tree atop another, the result of the one above linking to the objective of the one below.

 

In addition, an objective is a desired result. Consequently the successful result of an action has a substantial relationship to the objective which motivates that action. This may be so in a qualified way even when the result differs from the objective, although in a troubleshooting process such a "failure" result links to the objective of a different objective and task, possibly with a different resource.

 

The example of test results falls here. However, the expected results or "pass criterion/criteria" of a test are not the objective of the test. The business objective of testing is to determine whether a product is ready to release and, if not, some indication of what specific additional work is required. (Developers often do additional testing to pin down a bug.)

 

This is a result in the sense of accomplishment. But examples also include scenarios and incident descriptions, and these are not accomplishments. They may be consequences of actions, but those actions are fortuitous, unplanned, not organized systematically with the marshalling of resources etc. to achieve an objective.

 

A scenario may give rise to or motivate or contextualize an action, a task, or even an objective. Does that call for a double-headed arrow between result and action? Between result and task? The consequences of an action or actions may be described in a scenario which may then motivate the formulation of new objectives. Or is some other definition of scenario intended?

 

An incident description may describe consequences of actions, but not purposefully intended results achieving a business objective. It may be akin to negative test results, without the context of a formal test.

 

9 Requirement, 10 Design, 11 Specification -- no comments. (But should it not be "Requirements"?)

 

____________________________________________
The stated purposes:

 

As content developers "We capture information
provided by subject matter experts as it changes. We
then transform it into content and publish it to our users.
Yet when we talk about single-sourcing, most often we
are talking about managing our own content. If we were
able to single source information rather than content we
could get closer to the source and interact directly with
the agents of change within the organization. The
challenge is in finding a way to effectively manage
information as content.
[...]
"Language, format, media, audience, and even derivative
content are all part of the presentation layer. They can
all change according to the needs of our users. The
underlying information however stays the same
regardless of changes to the presentation layer.
[...]
"Experts
argue that accidental reuse is not practical – and this I
would agree is mostly true of content. But it is not
strictly true of information. Information should not
change according to its context.
[...]
The aim is "a model that attempts to
define the shape of information we use to create
documentation".
____________________________________________

 

This statement overreaches a bit. These are information types or metadata category labels for (like it or not) content.

 

When Dick Kittredge's products (cogentex.com) generate fluent text in a variety of languages and output modularities, the non-language data sources are arguably information as distinct from content.

 

Harrisian discourse analysis produces a representation of information in a constrained subject-matter domain.

RHannaModel.tif