SWIF widget core capabilities act in concert to support all aspects of mission planning from target selection to concept of operations development. Target widgets focus on providing planners and analysts the ability to diagram and analyze government, economic, and social entities’ relationships in support of target and capability selection. Planning widgets allow the user to develop multiple courses of action (COAs) and visualize events within the context of the overall plan. Most importantly, third parties are allowed to use SWIF as a framework for developing, as well as hosting, widgets to enrich core capabilities. Existing non-SWIF widgets can be rapidly adapted to integrate into SWIF. However, all widgets within SWIF must undergo the SWIF Governance Process for certification and accreditation (C&A) prior to deployment.
SWIF Widget Governance Process
The SWIF goal is to foster innovation rapidly to field relevant capabilities in order to meet existing and emerging collaborative needs amongst all branches of the military and from disparate security access levels. Currently, new capabilities are subjected to lengthy testing and C&A processes. This necessary, but lengthy, process may take as long as nine months to complete in which time crisis planning needs may be unmet. The SWIF architecture allows for a decoupling of the hosting web-based infrastructure and the widgets where functionality resides. The infrastructure consisting of OWF, SWIF Security Services, and the SWIF database would be subject to the full gamut of C&A review. However, once the infrastructure was certified and accredited, it will only undergo C&A for upgrades—not when new widgets are added. Widgets, on the other hand, would undergo a governance process that would streamline the C&A process based on their capabilities, complexity, and security boundaries.
Widgets are characterized as simple or medium based on their capabilities, complexity and security risk posture in relation to the networks in which they operate and the applications with which they interface. Table 1 delineates the difference between a simple and medium widget category type in SWIF:
Widget approval is dependent upon the residual risks the widget poses to the network in which it operates and the systems it supports. These residual risks are then weighed against mission efficiencies, accuracies and overall improvements the widget creates in specific mission execution.
The widget governance process is streamlined into workflows dependent upon the widget’s profile. The Widget Submission Package of medium widgets will undergo a workflow with more rigorous testing and review as compared to the governance workflow for simple widgets. Both the Simple and Medium Widget Governance Workflows can be seen in Figure 2 with color-coded roles. The Developer role (in blue) is responsible for ensuring the Widget Submission Package is complete and submitted appropriately according to the Widget Submission Package Checklist. The SWIF Project Team/Approval Board role (in light red) is responsible for: reviewing the Widget Submission Package for completeness, functional testing, integration testing, and final approval. Finally, the Security role (in light green) confirms that all Information Assurance (IA) testing is performed appropriately for the widget type. This governance process ensures that widgets are tested properly but without the unnecessary waste of time and effort.
There are a variety of components that make up the SWIF construct. These components include an unstructured database, secure web services, APIs, and banner service.
For data storage, SWIF uses a NoSQL database. The main feature of the NoSQL database that SWIF utilizes is the capability to provide a dynamic schema. Standard relational databases require all field information to be defined ahead of time before data can be entered into the table. Having a dynamic schema allows the operator to insert data into a collection (table in relational database terms) with different fields for the same collection. In other words, a collection is created to which data is entered, but fields are not defined within a collection. This allows a widget to be installed without having to initialize a database to define tables. The simplification of a widget installation enhances the accreditation process because the core system does not have to be changed to install a widget.
SWIF Secure Web Services