Today's keynote is being given by an FBI CTO who spent most of his career at NSA - interesting cross over. He made an interesting observation about how line workers view updates from IT - they fear that new technology coming from IT will be less capable than what they have now. That's hardly unique to FBI - and it's part of a large scale issue in IT shops: there's a lot more slavish following of analysts (especially the useless ones) and fads than there is examination of actual needs.

One item I noticed he hit on as being important to him - SOA. The thing about SOA that makes me skeptical is that it means all things to all people. It's like OO 15 years ago, or the visions being pushed by the OMG a decade ago. Universal answers never are - but C level IT folks always seem to be willing to drink the koolaid.

Oof. In a discussion of network security we just got treated to "buzzword bingo", where the buzzwords are all security agency specific. There's a real issue afoot there though - in any secure environment, how do you make data available to people in an appropriate manner? For instance - some data might need to be shielded for reasons having to do with trial rules. Others might have to be shielded based on which foreign governments are or are not allowed to have access. That all sounds like "why do I care?" for business folks but - with the advent of SarbOx rules, it actually has deeper meaning than a lot of us might like.

Here's another issue that will resonate with business people - the simple volume of structured (and unstructured) data washing though systems. Consider a product marketer or product manager - how the heck do you figure out what the competition is up to? For that matter, how do you figure out who the competition even is? Unlike the FBI/NSA problems, it's nearly all open data - but the fact that it can be found doesn't mean that it will be found. And here's where the FBI guy relates it to his problems:

When the military captured Hussein, they used social (or network) analysis to do so. The tools were pretty simple - large sheets of paper and markers. Now consider a hostage taking (something the FBI deals with). In such cases, they don't have a long time to find the person - it's literally life and death, and time matters a lot. Being able to drive that kind of analysis quickly using decent tools would help them a lot. To relate this back to what seems to be a trivial issue (at least when compared to kidnapping), consider a product team trying to determine which of a set of desirable features to implement for the next release of a product. There may be (say) 10 possible features of interest, but - given the size and capability of the team, combined with the desired delivery schedule, only (say) 3 can be delivered.

How do you make those calls? Market research to determine sales impact? Interviewing existing customers in order to extrapolate general market demand? What about extending the delivery time out so that more could be done? What about hiring more staff so that we could accomplish more? These are all calls that are made with insufficient data, and they need to be made decisively. In my work, I make those sorts of calls all the time, and I'm never entirely certain that I've made the right ones.