Net-centricity

I received a forwarded email from a colleague entitled "DoD seeks net-centricity help." I found a copy here. It seems from this article, at least, that they do in fact have a problem articulating their message. I also suspect they aren't talking to the right...vendors. Mr. Montemarano is sparse on specifics and fails to bound the problem. I know it's just a syndicated news article, but it's the message I received. (Ironic, isn't it?) What do you want me to consider? He says he wants vendors to offer pub/sub. Ok, great. Done. But, what about security? Presumably that is important to DoD. What about the Army's mobile, ad-hoc requirements for FCS? Net-centricity is a broad concept. Some argue that it also frames the problem in terms of technology and not people. There is certainly something to that. As a career student of computer-supportive cooperative work (CSCW) and human-computer interaction (HCI), I usually defend that position. (Consider the case here, where news with the wrong message has been successfully syndicated to a wide audience. Tech did it's job.) But sometimes it is just about the technology and I think that is the case with DoD net-centricity in the way I infer here. I would agree that vendors are not implementing what Mr. Montemarano seems to need. DARPA invented the Internet. It was an amazing technical feat. Communication-wise it was about as complicated as "Hi." But DARPA must have become a one-hit wonder in the telecom domain. What Mr. Montemarano wants is Web 2.0. And he can have it. Want is not happening is that no one is seriously considering how to get Web 2.0 done in what are rigidly constrained environments inside DoD. And O' Reilly's original essay on Web 2.0 isn't without flaws. "Wisdom of Crowds" can also lead to "Group Think" and gross disinformation. Mr. Montemarano, my name is Kevin Curry. I work for a company called Bridgeborn. We have offices in Virginia Beach, VA, Arlington, VA, and Savannah, GA. Give me a call.

On Addressability of Data on the Web

I don't understand data sharing solutions that require centralization of data stores. Centralization is an organizational artifact, not a technical one. "The way to solve this is...everyone stop putting you data there and start putting it here." By the very nature of the web, this requirement will never be fully satisfied. There will always be something not in the "master database" that is relevant. And how do you consume data from multiple sources, i.e., multiple perspectives (ex., operational, financial, organizational)? Centralization is seldom even possible, by design, in classified environments and highly improbable when sharing data potentially leads to losing your budget. If data exists on the web and needs to be shared then the way to share is clearly pub/sub; to syndicate query results over HTTP. Probably, but not necessarily, XML will be used to carry data. Technically this should be a no-brainer. Wrap database stored procedures with methods on a Web Service and point to them with URLs. Everything we share on the web we share over HTTP using URLs for addressability. Addresses are fundamental to how data is managed in computers down to the hardware. Why should data on the web be any different? They aren't:

[Note: These links are illustrative. They don't work]

• GetConsumerOpNodesByCountOfIER
  Returns an Xml Node containing the list of Consumer Operational Nodes and their IER counts, ordered by count
• GetConsumerSysEntitiesByCountOfIER
  Returns an Xml Node containing the list of unique System Entities ordered by number of IERS for which the SysEntity is used as a Consumer
• GetConsumerSysNodesByCountOfIER
  Returns an Xml Node containing the list of Consumer System Nodes and their IER counts, ordered by count
• GetMissionThreads
  Returns an Xml Node containing the list of unique Mission Threads
• GetMissionThreadsByCount
  Returns an Xml Node containing the list of unique Mission Threads by count of threads
• GetMissionThreadsForOpNode
  Returns an Xml Node containing the list of unique Mission Threads in which the given OpNode participates.
• GetOpActivities
  Returns an Xml Node containing the list of unique Operational Activities

The results of these queries are usable by both people and software.

Sidebar: Just like hardware, data addresses aren't particularly people-friendly. Look to the ideas behind semantic web to help with that.

Form-driven Editors and Language as Cognitive Artifacts

I was recently noodling in an Access database, creating queries. By default the "New Query" dialog steers users to a form-driven editor. It takes a couple of clicks to get to a text editor for writing SQL.

When writing SQL, at least, I'd much prefer the text editor by default. The reason is that the form editor slows me down at a very fundamental level. It's not as if I'm a coder with a chip on my shoulder about graphical code generators. Far from it. I can think of at least two that are quite handy at what they do [1, 2]. But with a language like SQL it's always going to be easier to learn how to speak the language than learn how to use a proprietary GUI. Even if Access was the only database technology I ever used (which is not the case), I know intrinsically that SQL is the right way to query a database and a form editor is the wrong way to query a database. The reason is that the act of querying a database is, at its core, an act of language expression. Filling in a form and dragging boxes around are acts of interaction that get in the way of expression...of me telling the computer what I want it to do.

This must be the inherent lesson from Donald Norman's theories on cognitive artifacts. It's interesting that I found this article by him just now. It says:

"And of all the artifacts that have aided cognition, the most important is the development of writing, or more properly, of notational systems: number systems, writing, calendars, notational systems for mathematics, engineering, music and dance."