Intelligence Failures and Bad Information System Design

Update: What timing! Moments after we published this, we saw this column, Intelligence Is a Terrible Thing to Waste, by L. Gordon Crovitz at The Wall Street Journal’s web site. It nicely complements our post and validates a few of our speculations–although we must admit that his column has a catchier title.

In this rather long post we speculate about a possible underlying cause of the “intelligence failure” involving Umar Farouk Abdulmutallab, the Nigerian accused of trying to blow-up Northwest Flight 253 on Christmas Day. Of interest is how he was cleared to fly despite his father notifying U.S. authorities of his–the son’s–extremism and potential for terrorism.

Note that we have absolutely no private information regarding either the incident or government information systems; so, we speculate based upon our knowledge of other large, bureaucratic organizations with rigid, poorly-designed systems.

We realize that incentive problems–which result in the unwillingness of agencies and individuals to share data and information across jurisdictions–and our freedoms and rights constrain the effectiveness of investigative efforts, but for the most part, we’ll ignore those issues to focus on information systems.

Common MIS Issues & Problems

A few weeks ago we wrote Inexpensive but Valuable Web-based MIS. Besides describing those beneficial systems, we mentioned that many so-called “management information systems” are, in fact, merely data-processing and record-keeping systems (for transactions and events).

Such systems rarely provide information–decision-altering content–for the types of strategic decisions made by senior managers, and unfortunately, they may not be well-designed to provide useful tactical information, either. That’s the case if the systems:

1. Produce useless standardized output (reports);
2. Are difficult to fully access or query; or
3. Don’t adapt quickly or well to changes in the environment, operations or institutional knowledge.

In Umar Farouk Abdulmutallab’s case, we suspect that it is the inherent rigidity of the database application and/or the rigidity of the designers’ thought processes that are to blame. (Note that for new information systems, useless standardized reports result when systems designers don’t ask users the correct questions or do ask the right questions, but don’t really understand the replies. See Details Are Not Information for more on this topic. One of our MIS friends often remarks that her key function is to serve as a translator between system users and system developers, and that role is critical but too often ignored. For older systems, irrelevance and obsolescence usually result when the system isn’t easy to change.)

What Went Wrong on Christmas?

When bad things happen, i.e., when someone like Umar Farouk Abdulmutallab squeezes through the detection sieve, it is possible that nothing failed. One must consider that the detection system–the net, the filter, the web–may not have designed to catch everything and that the designer or owner considered a certain level of error or misclassification to be acceptable.  The designer may have concluded that a perfect, error-free system is too expensive to develop and maintain.¹

However, the failure in the Abdulmutallab case was so egregious that it seems far more likely that either the detection system was either incompetently designed or administered.

Now, it is quite possible that a government sentry or sentinel fell asleep or neglected his or her responsibility. In that case, it is both a human error–because a person failed–but also a systemic error because there was no redundancy or backup mitigate such error. However, rather than criticize government employees involved with the nation’s security, we’ll assume that they are earnest, capable, and hard-working as we believe that is true.

In that case, it must be that despite their best efforts, the detection system failed, and one reason for the failure could be the improper design of the government’s information system.

One obvious weakness in the terrorist detection system–and it is by design–is the government’s unwillingness to use conditional probabilities to assess the likelihood that someone is a terrorist, especially if the person is a foreigner and is not protected by our Constitution and Bill of Rights. As we wrote in The Absurdity of Hassling Grandma but not Nidal Hasan, we do blame the government (and President Obama) for maintaining policies and procedures that ignore information, i.e., prior and posterior (conditional) probabilities that someone fits the well-defined profile of a terrorist.

However, other than criticizing his unwillingness to “profile,” we don’t blame President Obama for the failure on Christmas, and we think that it is silly for others to blame him.

We do think that his preferences and mindset for large, centralized, mechanisms–e.g., nationalized health-care, bail-outs, etc–are similar to the problem we discuss below, but in all likelihood, the system predates his tenure.²

So, despite the system handicapped by the unwillingness to profile, if the intelligence failure was not President Obama’s fault (and not former President Bush’s fault) and it is not the fault of those manning the systems, than who or what is to blame?  We suggest that the reader consider a poorly-designed, overly-rigid database/information system.

Too Rigid

By definition, in an overly-rigid information system, both the input and output functions may be less flexible and user-friendly than required. Given the federal government’s penchant for large, centralized, standardized solutions, it is easy for us to believe that such an information system (or systems) has (have) been employed in the war against terrorism and that such systems increase the likelihood of “intelligence failures” and terrorists evading detection.

Rigid Input: Round Holes, Square Pegs and Worse

Consider the idiom of “putting a square peg in a round hole.” For databases that means that certain facts that should be recorded may not be easily categorized into available fields because proper, descriptive fields do not exist (and cannot be easily added). For example, consider census or EEOC forms where there is no appropriate box to check: where it is required to select a single “nationality” or “race” when you are 1/16 of this and 1/8 of that, et. al.

If such metaphorical “square pegs” could consistently be jammed into “round holes,” there would not be an issue because users would likely have developed heuristics (rules-of-thumb) to create well-formed substitutions and work-arounds. In all likelihood, those rules or mappings would not be formalized in any official manual or documentation, but they would be well-known and transmitted during both formal and informal training sessions.

Unfortunately, real-life is often not so simple, because the so-called “square pegs” may not be of, say, uniform size, color, and shape.

In fact, other than certain fields like names and addresses, we suspect that many of the facts that should be recorded can’t be easily or succinctly described in a word or two–that they are more nuanced and qualitative and graduated and require lengthier, usually subjective descriptions. Actually, they may not be very different than blog posts, and we would hope that writers and recorders of those posts would have the flexibility to create new fields and categories on-the-fly–like we do every time we add a new tag or category.

Unfortunately, we suspect that leads to many “coding” errors and inconsistencies and extremely long descriptions of fields (to prevent such “errors”.) We also suspect that it leads to too much oversight; many layers of approval by superiors (and therefore much editing and changing); and overly-restrictive input policies, e.g., “he doesn’t have the permission or authority to write that.”

Moreover, we also suspect that these problems are exacerbated when investigators and field agents aren’t involved in the information system design process.

Rigid Output

Other problems with rigid, poorly-designed systems include (1) not providing useful, standardized output or (2) not having the capacity for users to easily search and access stored data for ad hoc queries.

Note again that we have no knowledge of actual, routine TSA, FBI, CIA, and Homeland Security reports, and if we did, we probably couldn’t write anything.

1. Too Centralized and Uniform

That being said, we could imagine that there are different levels of security clearance, and that access to the data could be overly-restricted based upon those clearances. In particular, we could imagine that unverified and unsubstantiated reports are among the least generally-accessible data–until they are verified, reviewed or accepted by the bureaucracy, regardless of whether that involves a single agency or an over-seeing umbrella group.

BUT those unsubstantiated reports are the ones that are most likely to provide information about new terrorists like Abdulmutallab, (and that is the problem with treating foreigners who are threats to our national security as criminals rather than enemy combatants.) If our hunch is correct, then one should expect future “intelligence failures” to arise in similar situations.

Moreover, if our hunch is correct, then a centralized, database administrator’s (rather arbitrary) rules–or worse, some lawyer’s rules–substitute for the individual knowledge and discretion of various field agents and supervisors.³ As such, fields agents may not have the opportunity to synthesize the information until it is too late. (It’s a case of the perfect being the enemy of the good.)

Unfortunately, that problem is exacerbated once those rules and policies are set. Later administrators may be unwilling to “rock the boat” and initiate worthwhile changes because there is a chance of being blamed for subsequent failures but little chance of being rewarded for success. (Those accolades would most likely go to the “eagle-eyed” agent who noticed something was wrong.) By the way, as we often argue, it is difficult to categorize such a choice–not to act–as irresponsible behavior, especially when it is induced by poorly-designed policies and a lack of managerial discipline. That’s why it is a bureaucracy, after all.

So, rigid policies self-perpetuate and information, hunches, and rumors are not passed along.

2. Searchable? We Doubt It.

As we have repeatedly mentioned, much of this post is mere speculation. A few of our conjectures are projections based upon our own experiences. Given that, we could imagine that investigators, analysts, and agents cannot query or search the entire database (if it exists in one place).

Most likely, they receive exported subsets of the data, and those subset do not arrive immediately upon request. (The decision to grant the request is probably made by a database manager or administrator and may require detailed specifications and possibly multiple approvals–a whole process. Again, that’s why it is a bureaucracy.)

Now, we’re not sure of the benefits of such a bureaucracy and suspect that such processes continue to exist because “that’s how we’ve always done it,” which could be translated as “we don’t know any better.”

Regardless, there are costs to such procedures. Besides the possible lack of timeliness, there is a reduced opportunity of discovering anything–patterns, what not–accidentally or serendipitously. When a subset or export is requested and justified it must be completely specified; so, the requester needs to know exactly what he or she plans to investigate before completing a request and there is little chance of expanding or redirecting the investigation without re-submitting requests for additional fields.

In addition, if the entire database is not fully-searchable, then investigators are less likely to find matches and patterns across fields. Recall our criticism above: with rigid input fields, and varying “square pegs,” agents in different locations and departments may input similar facts in different fields. If some of those fields are not available and searchable, then investigators will get fewer hits and matches and that will reduce the chance of making connections and discoveries.

Our Recommendation

So. the diligent reader, who has made it to this point, may ask: if your hypotheses and speculations are correct, then what’s your solution? (Alternatively, they may note that the sellers of hammers tend to see a lot of nails.)

We reply with a rhetorical question: why can’t such systems or conglomerations of systems be more like the web and blogosphere? By that we mean why can’t they be unfettered, completely-searchable, accept responsible comments and questions, and even permit writers with varying degrees of credibility to post entries. (If the government already has such a system, then kudos to it.)

Why not decentralize the process and empower security investigators, analysts, and agents to use their idiosyncratic beliefs, opinions, information, experiences, positions, and knowledge to identify problems and to adapt the database as threats and knowledge change?⁴

We imagine a mini-version of the internet (with the ability to search the entire internet, too), where individual agencies publish blogs and news reports for themselves and other agencies. (Geez, they could even sign-up for each others’ feeds.

Of course, such a system would need to be at least as secure as on-line banking, but more private, but all such systems must be.

Note, also, that nothing precludes the running or harvesting of routine reports from such sites. That’s what search engines and their bots and a host of sites already do. They standardize the output of many disparate systems. In fact, our recommendation does not require any new or advanced technology–just the application of existing platforms that are freely and readily available to anyone with a few bucks and an internet connection.

Granted, it’s on a much larger scale than our blog, but it need not be expensive.⁵ Moreover, we suspect that access to existing systems could be incorporated easier via web apps than through custom programming forays that attempt to merge or consolidate existing databases.  For example, every Google query searches millions of MySQL and MSSQL databases all with slightly different structures and fields.

Maybe we’re wrong, maybe we’re right. However, even if our diagnosis is correct, we doubt that the government would act on our recommendation. It would most likely try a centralized “fix” of the identified problems or would try a pilot-program that (due to its limited nature) would be destined to fail. In that case, hoping for continued good luck might be the most reasonable and viable strategy.

In closing, note that we are not disparaging the efforts of our fellow citizens or the nation’s allies in their defense of our country and way of life. Instead, if our speculations are correct (or nearly so) we are recommending a change in strategy and tactics so that their earnest effort yields more productive results.

As usual with long posts, we’ll likely make corrections and edits that clarify our prose during the next few days.

Copyright © 2010 Spero Consulting.

---

Footnotes: