Information Sharing Environment: Architecture

Three sets of ISE Informational Resources

In scenario planning, there are three primary sets of information to be addressed.

1. The broad information "base" - source data spawned by business as usual processes.

This information set can be termed the "outer ring" because it is made up of "business as usual" data that only on occasion might be needed to support Intelligence operations. Private sector organizations as well as governmental and quasi-governmental organizations (e.g., the Port Authority of New York) create billions of rows of data each day, of which only a tiny proportion ever become Intelligence-significant. Therefore, highly selective and agile access is needed, supported by due process.

2. Intelligence activities - reconnaissance, investigations, etc.

The "inner ring" of information to be shared is that generated by Intelligence Community activities. The information produced by Intelligence Community processes generally will be driven by some primary purpose, but the information produced also subsequently become relevant in ways not originally anticipated. Therefore, both first-order and follow-on opportunistic uses need to be facilitated by the ISE.

Note that, although a "data" ISE is important, people-to-people communications via telephone, face-to-face discussions and other "people" communications remain important. Often the data shared via the ISE will be valuable in stimulating people to initiate discussions that otherwise might not occur or that would occur too late.

3. "Finished product" information - packaged Intelligence estimates or other formal documents.

Intelligence studies themselves become information subject to sharing. Although the source information used in preparing finished product documents is presumably drawn from the previous two categories, the authors' hypotheses, conclusions, and guidance may, in effect, constitute new "source" information. Again, this source information may be subject matter for opportunistic reuse.

Who Is the customer?

One has to consider who we are helping by implementing the required ISE - that is, who is the customer? Although Congress and by extension the country is the end beneficiary, the people and organizations within the Intelligence Community are the ISE "customers." The better the ISE works for them, the better they work for us.

Members of the Intelligence Community fall into three broad segments: 1) those performing intelligence operations and various technical services, 2) those performing tactical analysis and investigations, and 3) those performing strategic analysis.

This proposal focuses heavily on the needs of the analyst and investigator although the resulting ISE will serve the entire Intelligence Community's needs as well as those external to it who depend on Intelligence information feeds.

Information suppliers also benefit. Although 9/11 Commission references to breaking down the barriers to "sharing" would seem to imply a "breaking into" recalcitrant information suppliers' "stovepipes," information supplier organizations are themselves frustrated by the difficulties of getting people to use their assets. Indeed, not only do information suppliers want fellow community members and other authorized users to exploit "on the shelf" information, they want guidance and requests for future actions - whether specific collection events or program planning. Therefore, the ISE needs to facilitate "make to order" information requests as well as passive sharing of on the shelf information.

All concerned need the benefits of appropriate security, because the value of the intelligence work products and in some cases the lives of people are jeopardized by weak security. Within the aftermath of 9/11, some people expressed frustration regarding the slow cycle times for people to gain clearances or to gain access to systems. However, there is no "bye" in the legislation with respect to enforcing appropriate information security or protecting personal privacy and civil liberties.

The Intelligence Community has external customers to be served. For example, if there is a question as to whether to permit a foreign student a visa necessary to enroll at a U.S. university or whether a given person should be allowed to board an airplane, the need is for appropriate, timely decisions and rapid communications. Queue build-up is not just a dissatisfier, but a source of risk and cost.

There is a very special, conceptually "external" customer - the domestic law enforcement and judicial community. Although some walls between the Intelligence and law enforcement will come down, proper management of the workflow "join" between the two remains essential to the health and success in their respective missions of both communities.

More specifically, one of the information sharing faults reported by the 9/11 Commission was widespread misunderstanding of the "wall" between Intelligence and domestic law enforcement. Using workflow to bring more clarity, uniformity and expertise to the ISE filtering process is an important remedy. The term "workflow" is intended to include not only automated step-by-step approval processes, but the substantive rules involved.

Helping the analyst with some "special sauce" left from the .com party

In terms of priority, the greatest ISE objective should be to enable the analyst and investigator to span "stovepipes" and to follow information trails and test hypotheses on an efficient, often self-service basis.

To create the needed level of information sharing, some .com-era "special sauces" are suggested - primarily a combination of the OBI (Open Buying on the Internet) model plus "double-ended" workflow, supported by a thoroughly "Internetized" IT architecture.

Today, the OBI model is most commonly used in B2B buying of indirect (or "non-production") goods. Indirect goods include, for example, widgets used in maintenance, consumables such as miscellaneous chemicals, copier paper, books, PCs and laptops, and so on. For a large company, indirect buying presents substantial problems in managing content, authorizations, pricing, payment, cost accounting and others. To address these in a B2B environment, a buying company might use, say, an Ariba Technologies' eProcurement platform or perhaps an equivalent service from an eBusiness exchange. These eProcurement solutions typically include a capability that enables the user to "punch out" (or round trip) to supplier sites that have implemented the supplier end of the OBI dialog.

What is proposed for the ISE is that the analyst or investigator gain access to the same capabilities that are provided for the "indirect" materials buyer. The analyst would log onto his or her home organization's workflow platform and then would be offered the opportunity to punch out to a number of content holding servers (also described below as staging servers). Once the user selects a destination, the user's home server automatically redirects the user's browser to the selected content server, thereby bringing the user to the content. It simultaneously passes the user's credentials to the content server, providing automated server-to-server handoff and from the user's perspective, single signon.

The user's credentials do more than grant or deny access; the supplier's server also may use the credentials to focus the user on specific content and functionality. For example, the user in "punching out" to an office supply house's server perhaps would be permitted to view and order copier paper and toner, but not PCs or furniture. This is a form of supplier-side workflow that can be very helpful in dealing properly with "need to know" (security parlance) and "want to know" (practical relevance).

The ISE content server's catalog, search and, if applicable, configuration functionality would work as in the B2B world except that the items represented would usually be "information" products (reports, datasets, images, soundbites, spreadsheets, etc.) rather than physical goods. Of course, some ISE catalogs might also list physical artifacts. Through supplier side workflow functionality, the ISE content server would not bring up catalog items with security levels beyond the access granted by the user's credentials - e.g., if the user is cleared for secret, it would not bring up top secret items.

The OBI dialog empowers the Intelligence analyst or investigator, because he or she can "shop" at content sites much like shopping at Barnes and Noble.com or Amazon.com. Note that, typically, the requestor would see catalog entries rather than detailed information content, just as on Barnes and Noble.com the requester does not see the full text of a book at request time. Once the user completes item selection, the content server then automatically redirects the user's browser back to his or her home workflow server, while simultaneously passing back the user's "market basket." Within the user's home server, the transaction would go through home organization workflow - which could range from self-approval to some substantial management, legal and technical review. Note that "self-approval" is not the same as "no approval," because the workflow process would typically collect more reference information from the requestor (e.g., a case or project reference) as well as create an audit trail.

Although need to know would commonly be thought of as something the supplier server should enforce, in fact there are sometimes double-ended authorization needs. The receiving organization may have issues with what is proposed to be brought in to its domain - for example, whether the receiving organization can properly protect and use the information, whether a more or less sanitized version would be preferable, etc. Where applicable, workflow also provides an opportunity to undertake legal review before pushing the approval button. Approval may foreclose various law enforcement or regulatory actions - sometimes a worthwhile tradeoff to avoid a terrorist event, but not so worthy if the information is not critical or if a change in process can protect all options.

Following the electronic delivery of the approved order, the content holder would initiate order fulfillment - either via electronic transfer of the information requested or the physical shipment of paper records or material. If the request was "make to order," the collection activity would be run and then the results delivered.

In requesting new information - e.g., an investigator needs some agency to create new imagery of a U.S. harbor facility - the ISE need is to enable the requestor to deal with sometimes complex choices on a self-service basis. Indeed, just as a customer ordering a laptop can use sophisticated configuration tools in a B2B environment, the ISE ordering process may invoke configurators. With respect to the imagery example cited above, the non-expert interacting with a configurator can express his or her needs in "expert" terms - e.g., to specify time of day/shadow conditions, weather conditions, tide conditions, etc. Often, configuration tools can elicit information in a context that hides security-related aspects of the topic - e.g., what vehicle carries the sensor - and without providing the user with direct access to the internal logic of the tools themselves - enhancing security as well as supporting self-service.

The entire OBI dialog - from the user picking a site to being back at his or her "home" server can take less than a minute or two, plus whatever think time the user requires to locate and select items.

Note that in the B2B world, the OBI process also feeds important follow-on supply chain functions such as receiving, inventory management and perhaps invoicing/payment (e.g., if the receiving agency pays for shipping, missions, etc). For the Intelligence Community, one of the key ISE follow-on issues is inventory "putaway" strategy. For example, having ordered needed information, does the analyst accumulate the information on his/her laptop, is it put away in a team server, is it read and then electronically shredded, etc.? Pre and post-approval workflow provides a proactive opportunity to make such information management decisions.

This model supports the automatic generation of audit trails. At each step, the systems involved would record the transactions as they occur - including denied ones - for later followup, if needed.

Although what is described above is agency to agency "punchout," the model is highly adaptable to agency to private sector punchout (and vice versa). For example, if an agency needs to obtain shipping data from a 3rd party logistics firm or patient data from a hospital, the two-ended workflow described above creates opportunities to do so, while also addressing privacy or other regulatory issues involved. (Today, many companies and eBusiness intemerdiaries support one or more variants of the OBI dialog although almost certainly not directed at information of potential intelligence interest). For more background on the OBI model and the various implementations see OBIdialog1).

Overall, the OBI dialog emphasizes human judgment with respect to evaluating and selecting content, while letting machines do server-to-server routing, single sign-on and content transfer.

"Production-oriented" XML-enabled information sharing

The eBusiness approach to "direct materials" (or "production") buying follows different models from "indirect materials" purchasing, and the ISE needs to implement the "production" B2B models as well as indirect ones.

Some of today's most intensive eBusiness relationships exploit automated, hands off EDI or XML equivalent data exchanges - such as the supply chain linkages between an automotive manufacturer and its Tier 1 suppliers. Given suitable setup, EDI and its updated XML equivalents can provide efficient and tireless execution of structured information exchanges. Because of the need for substantial transaction volume to justify setup, probably 80% or so of all "production" B2B transactions come in the form of a very short list of standard transactions - purchase orders, releases, ship notices, invoices and a few others. "Onboarding" new transaction types and trading partners can be burdensome, so production eBusiness solutions have some of the pluses and minuses of railroads - enormous carrying power, but an inability to deliver beyond the end of the track.

A somewhat new offering - "Web Services" - enables automated processes to "call" one another in order to push or pull information and to exercise update and query functionality. Although startup effort is still required, the effort is somewhat less than with older methods and the number of people who can create web services is rapidly growing - certainly beyond the number of EDI experts.

A specific "case" will relate the production B2B model and more specifically Web Services "calls" to the 9/11 situation. - using a hypothetical example of Web Services event-driven information "push." As readers will recall, although on 9/11 the various radars worked (mostly) well in physically tracking the aircraft involved, several aircraft were in effect not tracked - because of ISE breakdowns.

Assume that, instead, on 9/11, an air traffic controller could click on a "this aircraft is perhaps hijacked" alarm within the ATC (air traffic control) system. Further, assume that, once invoked, the alarm would then "wake up" a sleeping pre-defined Web Service or set of services that then automatically extracts and, until told to stop, pushes "skin tracking" data updates regarding the designated aircraft to the appropriate air defense system or, if needed, to multiple systems. The receiving system would of course need a Web Services receptor process to receive the "call" and also the ability to put the data to use. Given this capability, the controller would provide - once - the essential human judgment - "this aircraft is in potential jeopardy" - triggering the system to take care of the "who do I tell?" - using preset and tested automated directory information - and "what do I tell them? - by pushing its predefined data payload to the receiving system. As long as the raw data providers held up (in this case the radars themselves), the aircraft would have been continuously tracked and essential busy people would not have to push the data themselves.

Of course, this hypothetical scenario was not feasible on 9/11, because it was not programmed (an assertion that relies on descriptions published in the 9/11 Commission report, not on firsthand information about then-existing systems capabilities). Moreover, 2001 was "early days" for Web Services. Since 2001, technology has moved on - indeed, faster than effective adoption.

What makes this and other scenarios for production-oriented information exchange more readily implemented is that, since 9/11, advances in technology and doctrine have reduced the up front investment required. The need is therefore to identify, prioritize, reduce to a scenario and then implement real world web services dialogs to expand the range of prepackaged information sharing solutions Although web services are "new," they can be grafted onto systems that, in Internet years, are older than dirt.

Another convenient, canned information sharing capability is RSS (really simple syndication) "push." For ad hoc intelligence teams, keeping blogs to record "stream of consciousness" process and progress data and using RSS to "syndicate" that data offers a very powerful sharing environment (and, undoubtedly one already in use). Although RSS is thought of in connection with blogs, there is no major barrier to using it to "syndicate" (share) data from any system, presuming suitable data extractor processes are created.

Automated email also provides important capabilities to push data, share alarms, etc. although if overused it is so agile and tireless as to verge on being a chaos generator.

Finally, there is a vast amount of comparatively static data that can be "syndicated" through mass moves. As an example, there is a growing body of data regarding various transportation artifacts - for example, a blend of geographic, facility and activity data characterize a railroad - that can be periodically distributed as massive file transfers.

What are the prerequisites for implementation?

The "repurposing" of B2B approaches to information sharing depend on various infrastructure additions and investments. These are as follows:

Internet Access

The users and servers need to be accessible via the Internet or, in a fall back way, to an Intranet. Perhaps there are some members of the Intelligence Community still using "green screen" systems that might need upgrading. In all likelihood, this prerequisite is not a huge barrier, but the exceptional cases need to be addressed. Note that various handheld devices need to be able to participate in the Internet ISE, and as these acquire advanced capability - e.g., biometrics - they become very powerful tools.

"Staging" servers - integration with current systems

Information sharing is very much akin to a physical product supply chain - there are manufacturing sites at the originating end and product consumers at the far end, and the two ends need to be interconnected. Although sometimes "factory direct to consumer" processes fit, more often the physical supply chain requires intermediaries. In somewhat different terms, the 9/11 Commission Report highlighted weaknesses of the "factory to consumer" model. In place of "factory direct to consumer," what is proposed is the creation of information "staging" servers that are akin to physical product "distribution centers."

The ISE must span hundreds of "inner ring" systems, each of which manufactures information in its own way. Additionally, there are millions of sources in the quasi-private and private sectors, and some are of sufficient relevance to the ISE to be integrated. Given the number of information manufacturers, a "factory direct to consumer" process architecture will not suffice.

In the discussion regarding 9/11 remedies (e.g., the Markle Foundation study referenced in the 9/11 Commission Report), there was expressed the notion that the solution is to "bypass" the application logic of individual transaction application and instead directly access the underlying database. Indeed, application bypass eliminates the need for the intelligence analyst or investigator to wade through the user interfaces of dozens or even hundreds of complex systems. Also, the intelligence analyst or investigator rarely wants to exercise a given system's mainstream functionality and navigation - e.g., to use a governmental Hazmat permitting system to issue a Hazmat permit - so learning the system is valueless. Somehow, the application level does need to be bypassed.

However, bypassing the application layer to retrieve data directly from the database has its own limitations and risks, because often the application's logic is needed to glue together the "finished" transaction and to insure that the data is properly versioned. Indeed, the database may be even less friendly than the unfriendly application logic being bypassed. Bypass is even more risky if doing updates to the data base, and even read-only queries may (and often should) update audit logs.

The "third way" proposed here is to implement ISE "staging" sites that incorporate data feeds from one or more - usually more - information "manufacturing" systems. The data extracts will include provision to pull together the data as a "finished" product. Within the staging site, the imported data will be organized and to some small degree transformed. Some data will be, to use distribution center terminology, "cross-docked" - brought in the receiving door to the staging server and then split apart and immediately pushed out the shipping door to multiple information consumer sites. For less structured situations, query environments and search would provide customers with needed access and navigation mechanisms, including access to OBI-related catalogs and configurators.

If feeds from multiple systems are merged to feed a single staging site, there must be some minimal level of ETL capability - extract, transform and load. In performing ETL, what is important is that no information be lost through aggregation or transformation and that no time to market be lost by trying to create idealized navigation structures or storage structures.

To know what is in the staging site - and, especially, to support the OBI dialog, what is important is to generate (automatically) catalog item descriptions. For example, if the staging site includes 100,000 agent reports of a given type, the system would generate a catalog of at least 100,000 line item descriptions made up of generally descriptive information - date, agency, etc. plus an arbitrary item ID. In some cases, the process might generate be multiple entries per item - e,g., one entry that omits sensitive details such as collection "means" and another with a higher classification that includes more sensitive data.

Catalog and search capability plus OBI single signon can enable analysts and investigators to exploit diverse sites without having to deal with either of the "unfriendly" extremes - navigating complex applications or working with raw database access.

In framing this proposal, terms such as "staging" site were very deliberately used, while more familiar terms such as "portal" or "data warehouse" were very deliberately avoided as being too "retail" and often overly engineered. Typical portals can trap the analyst in needless complexity, while investing in "arts and crafts" features delays rollout. As with a physical distribution center, the functionality and decor of a "staging" site would be strictly and minimally functional. Such a site can certainly be implemented using portal or business data warehouse technology, but not employing a portal or business intelligence "cubes" mindset.

Search engine environments

The intelligence analyst's best friend is search. Indeed, search is vital to the ISE, because with information being distributed across many servers and originating in many more sources, there is a need to assimilate diverse data as well as create a means to discover it.

Search engines do not depend on orderly, uniform data or well-formed queries - otherwise Google and the others would still be at the incubator stage. Search engines happily deal with millions of servers and trillions of bytes of data - the rawer, the better, because to the search engine even the most finely crafted web site is just a string of data waiting to be indexed. To feed search, data from the various systems involved in ISE should be extracted for both import into staging areas and to feed search, but there may be advantages to pulling additional data just for search.

Putting the data into a form that supports search requires low to no investment in database design, and of course the government has extensive access to search engine capabilities. Search results typically include brief descriptive text (20 words or so) as well as links. Analysts often are interested in "factoids" that contribute to some larger picture rather than full text reports, so if the source data is diced into small strings, the search engine results can sometimes become the "result" as well as identifying a link to the source document or transaction.

Therefore, to support ISE, what is needed is a network of ICE-focused search environments. Just as "staging servers" would not align one-for-one with source systems, search engines might span domains that do not align with either.

Some thought and filtering customization is needed to deal with security, privacy and civil liberties. As an example, if the data being searched involves Hazmat permits, probably most are unclassified, but perhaps a few are classified or even highly classified, while others perhaps require some other protections - e.g., of trade secrets. Therefore, when the search engine generates hits, it needs to filter out any that exceed the security classification of person doing the query and of course to advise the user of the security classification of both the search results listing and of the source item to which a search item links. These can differ - for example, early in the life cycle of the first "stealth" fighter, mere references to "stealth" would be highly classified even though the link might be to a data sheet describing some non-classified commercial component used in the aircraft.

Directory services, broadly defined

The Intelligence Reform Act specifies the implementation of directory services "to locate people and information." Although directories are often thought of as mere "lists," directory services are themselves complex application environments that also depend on servers, information sharing, "search" and change management.

Directory - People

For finding Intelligence Community members, there is a short proposal description and a longer one.

The short proposal regarding "people" directory services is to leverage the above ISE proposal - e.g., to leverage OBI, staging servers, and search. To implement the directory, the steps would be to 1) identify source systems "manufacturing" people-related data, 2) extract the appropriate data, 3) put it in one or more staging sites, and 4) provide both query and search to enable Intelligence Community members to locate one another. As noted above, search not only becomes a means to locate links, but within the 20 or so characters returned can also approximate a "white pages" directory.

The process described can deal with large numbers of people and people-related records - five or ten million rows of data is trivial to a search engine, and it will not choke on noisy data although to a degree it will expose some of that noise to users.

There is, of course a somewhat longer story...

Presumably the prime customer for such a people directory is an analyst or investigator working on somewhat challenging locator problems - e.g., looking for a trusted set of eyes in zip code 99999, ideally someone with a certain perspective and skill set.

Various processes and systems "manufacture" and hold data about the people in the Intelligence Community. The resulting databases are almost certainly not coherent: for example, the human resources/payroll views of people and the various telephone systems and space management systems views of people (e.g. , who has an extension on a given PBX, who has a seat in a building) probably diverge, and each system has a claim to being "truth." For example, the HR system may list a phone number for a person, but if the PBX view differs, it is probably truth because the PBX robotically controls phone call routing.

There are other versions of truth - for example, that manufactured by physical access control management processes - e.g., the DOD's work toward propagating a universal access card and access management process - and that from financial control processes - e.g., from credit card/procurement card views. Also, as biometrics - such as online verifiable fingerprint artifacts - are collected and aligned with identities, they become ingredients of such a people view. Further, there are systems directories of users in, for example, Novell or Microsoft directory systems and there are additional people views in application-level directories/access control function - e.g., within SAP Enterprise.

Further complicating matters, the Intelligence Community is not a closed set. There are various non-governmental members - contractors, people on loan from agencies outside the Intelligence Community or from other governments. There are boundary shifts - e.g., a state police investigator (or entire team) might shift from investigating auto insurance fraud to terrorist prevention and by reassignment become de facto part of the Intelligence Community.

Although there is a natural inclination for organizations to discard variants of "truth," - for example, to concentrate on phone lists, but ignore email or user names, or vice versa - the lesson of the Internet is to accept and exploit the untidiness of multi-dimensional views in order to maximize information value. Search can help users deal with these variants. The top dog in search has shifted over time - with Google being today's top dog in terms of "share," but the real winner is search itself.

As described above, a comprehensive people directory probably need a "front end" to impose workflow, security filtering, and audit trails on utilization of such a powerful directory.

Directory - Information

In a sense, the proposal above satisfies this requirement. Its entire purpose is to enable the analyst or investigator to shop conveniently for information, perhaps from sources that the analyst never knew existed. However, to go beyond what is described above, there is an opportunity to add directory-related functionality based on work being done within the eBusiness community to streamline trading partner "on boarding"- to resuscitate an unloved .com term.

Within the IT community, the telephone-originated notion of "white pages" and "yellow pages" carried over into various IT directory functions. For example, those defining the standard for Web Services published three distinct standards - SOAP, WSDL and UDDI - the last being Universal Description, Discovery and Integration. UDDI is a sort of "yellow ages" - not only describing a "who" but providing some "what we do and how we do it" information. (SOAP is the protocol used within the web services itself, while WSDL describes in executable detail the "how-to" of the service.) Various groups are using, extending or replacing UDDI, but almost any eBusiness environment needs to provide the "discovery" needed to find services. Although ISE is about finding information, not "services," in today's object-oriented systems world services = information.

Within the eBusiness community, the ebXML group has worked at streamlining discovery with a goal of enabling hands-off implementation of complex trading relationships. This is especially, although not exclusively, beneficial to medium and small companies (www.ebXML.com and www.oasis-open.org). The ebXML standard therefore provides registries and other features that assist not only in "advertising" trading interests, but in providing sufficient machine-actionable setup information to permit automated transistion from discovery to trading. Looking ahead, the ISE could grow to incorporate thousands of points of integration, and implementing ebXML registries and other features could facilitate the "onboarding" process.

As with almost everything proposed above, the U.S. Government is active in this arena, so what is proposed is repackaging capabilities that are already accessible.
Note that 20% of the information-sharing interfaces will probably generate 80% of the value, so low level solutions should not be neglected if they speed implementation.

Checklist: Does the above align with the ISE requirements?

The above ISE proposals - centered on OBI plus various other XML-facilitated exchanges - address the requirements as follows. (The smaller boldface text is quoted from the Intelligence Reform Act of 2004.)

(A) offer the means to connect existing systems, where appropriate, avoids any single point of failure, and allows users to share information among agencies, between levels of government, and, as appropriate, with the private sector;

Yes, although whether a single point of failure is present has to do with physical implementation. As discussed below, there are gaps that need to be filled because few of the affected governmental systems are likely to support OBI, "Web Services" or RSS syndication. The tools and techniques are used by many private sector players although in a different context. For example, many large companies support the OBI model, either as seller, buyer or both, but probably not today set up to access information relevant to an Intelligence analyst or investigator. To "repurpose" the various capabilities described is feasible, but may require some torque.

(B) ensures direct and continuous online electronic access to information,

Yes, subject to physical implementation, server backup strategies, etc.

(C) facilitates the availability of information in a form and manner that facilitates its use in analysis, investigations and operations;

Yes although it is heavily weighted toward analysis and investigations rather than "operations."

(D) builds upon existing systems capabilities currently in use across the Government;

Yes although as described below there would be some prerequisite "front ending" work.

(E) employs an information access approach that controls access to data rather than just systems and networks, without sacrificing security;

Yes.

(F) facilitates the sharing of information at and across all levels of security;

Yes, and in some probably offers better security than today.

(G) provides directory services, or the functional equivalent, for locating people and information;

Yes, although this complex subject is further described below.

(H) Incorporates protections for individuals' privacy and civil liberties;

Yes, and it is particularly helpful in avoiding vast information dragnets and instead relies on very focused information access. The processes defined all incorporate forms of workflow that can be used to filter out inappropriate information access to to implement due process as a natural extension of the process.

(I)   incorporates strong mechanisms to enhance accountability and facilitate oversight, including audits, authentication and access controls."

Yes, and in particular the OBI dialog is a compliance officer's best friend.

Conclusion

It is important to move ahead quickly to implement an improved Information Sharing Environment (ISE) across the Intelligence Community, as required by the Intelligence Reform and Terrorist Prevention Act of 2004. The ISE is one dimension of a much more extensive "reform" effort, so a lot is at risk if the ISE cannot support the overall purposes of the Act.

This proposal focuses heavily on the ISE customer - particularly the Intelligence analyst and investigator. The goal of a better ISE is not a better ISE, but to improve the effectiveness and efficiency of this set of customers in pursuing leads and hypotheses across "stovepipe" information sources. To that end, what is proposed is a blend of Internet technology, B2B eBusiness techniques, Search, and supply chain techniques, all repackaged to address the ISE need.

The pluses are that the suggested approach builds on real-world experience. Since eBusiness incorporates "arms-length" relationships as well as a need to satisfy customers, its techniques are amenable to implementing security and privacy filtering without undue burden. Almost everything described is in active and often heavy use.

Some further advantages are that what is proposed is "modular" and decentralized. Because it is modular, ISE implementation could be fast-tracked with respect to certain groups, certain types of information or certain sharing processes. It can evolve as technology changes, and it does not force adoption of a standard technology architecture - e.g., Linux, Microsoft and Unix environments can readily be mixed. Although data grooming and data quality are both important and helpful, it can survive dirty and conflicting data.

For the analysts and investigators who are "shopping" for information, what is suggested is a "repurposing" of the OBI model (offered by various eProcurement software suppliers under various trade names and technology variants). The benefit would be an enhancement of "self-service" information retrieval and of the ordering of more information - e.g., to request collection missions. The OBI model would be coupled with "double-ended" workflow - with appropriate filtering at the content supplier end (e.g., should this be released to this user at this time?) and at the content consumer end (do we want this information?). At both workflow stages, the requirements of security, privacy and due process can be addressed within the natural flow of the approval process..

For alarms and what in B2B terms can be termed "production" information sharing - repetitive, standardized data exchanges, what is suggested is implementation of machine-to-machine (and process-to-process) Web Services calls as well as mass data transfers. Web Services now calls offer a widely accessible means to "join" two systems in some structured way to address data synchronization, alarm and monitoring scenarios.

To finesse the barriers created by needing to access hundreds of different systems, what is proposed is to create "staging" services - extracting information from various systems and putting it into what in supply chain terms could be thought of as a distribution center. Like a physical distribution center, there would be a lot of inventory, a lot of doors, put-away and picking and search processes, but nothing fancy.

For discovery, what is proposed is heavy use of search engine capabilities - for information and for people. The staging areas would support query as well.

The minuses of this proposal are primarily the need to accept some of the annoyances and uncertainties of the Internet information-sharing environment. For example, "search" will often turn up thousands of irrelevant hits, and the underlying source data will retain whatever warts and inconsistencies that are carried over from the source systems. It will also take a lot of work to refine and implement what is described - moving from concept to reality is a substantial step. The OBI dialog, although standardized in the .com days, does not have a modern, standardized version - the proprietary variants used today are quasi-standards and probably a modern standard should be created.

For the working Intelligence analyst, the tradeoff is between having powerful information access - and dealing with some data hairballs - versus waiting for some other alternative that is perhaps neater. However, the 9/11 experience did not validate "neat," it validated quick.

Given wartime conditions, I suggest that action is appropriate.

                                                                      Fulton Wilcox
                                                                      Senior Partner
                                                                      Colts Neck Solutions LLC

For further information, email customer.service@coltsnecksolutions.com.