We tend to think in terms of things and issues with which we are familiar. With interoperability, and also integration, we must make a conscious, concerted, and diligent effort to think about and identify the processes that lead to, support, or inhibit I&I. The definition and discussion described above is only a start for this effort. It will require thinking through those relevant facts about interacting systems that cause the problems occurring in the Fleet.
Following are some guidelines to aid this process. But these are only guidelines; they cannot replace good solid engineering know how and analysis.
Think Process, not Product
For Interoperability and Integration, we must think primarily about how things are being done when we build and integrate systems, and only peripherally about what is being done. We must, of course, keep in mind the what, but it is essential to determine how all the systems are designed and developed. We must understand the data content, for example, but it is essential for I&I to know how the data are structured, how they are formatted, and how they are communicated. Likewise it is important to understand how interacting or potentially interacting systems truly do interact—that is how are the factors implemented that make the interface, and how this implementation is relayed to interfacing systems.
As an example of this type of how versus what thinking, the I&I analyst will consider not the specific coordinate system of tracks in a program, but are there proper methods for sending and receiving track data with appropriate conversion and normalization conventions between systems that share them.
Think I&I, not Individual System
It is also important to think about interoperability and integration as issues themselves rather than about the characteristics of a particular system. For example, we want to think not about the tracks in a system such as ACDS, but rather how will other systems see the targets these tracks represent when transmitted to them and how will they be able to resolve the differences in track coordinates caused by different coordinate systems, gridlock, time differences, and similar issues between systems.
Note, for example, that there is no Category listed in the Appendix for Requirements. This is not to say that requirements are not important or that they may not be added as a Category, but they are primarily an element of a particular system. They specify what the system will do, how it will perform, and even some of the interfaces it must meet. But the system’s requirements are not intrinsically I&I risk concerns.
Short Term Goals
For the near term (through November 2000) some temporary alternatives may be taken to show an initial TRIMS capability during program reviews. This can be considered an expedient for an initial (alpha) test or proof of concept.
This short-term tool can be developed, but it will be sparsely populated. To do this we will temporarily defer the Knowledge Base development, make some intelligent assumptions for Templates and Questions, load them into TRIMS, and reserve the right to change them later after more complete analysis. It should only be considered an interim measure and not the solution. We must still follow the discipline of developing a full Knowledge Base and the resulting Templates
For this short-term approach, the attached Appendix has some suggested Categories and a few sample Templates. These can be used as a starting base. A consensus from the I&I team can be used to modify this initial set. To do this it would be most efficient to assign specific areas of I&I issues to selected people for the initial cut. When that is completed, the entire team can provide inputs and Questions.