Government of Washington, D.C., Office of the Chief Technology Officer (OCTO)

CapStat is a service-oriented architecture (SOA) for multi-jurisdictional emergency response collaboration. This technology infrastructure integrates public safety and emergency response data across the National Capital Region (NCR), which includes the District of Columbia and surrounding counties in Virginia and Maryland.

The overarching goal of this project is to link emergency operation centers (EOCs or 911 call centers) across the NCR. Once linked, this program accelerates communication of real-time incident and event information, as well as speeds recognition of and response to public threat events.

The greatest element of business risk associated with the program was a political one: dealing with dozens of independently managed Emergency Operations Centers (EOCs), each with their own IT groups and systems. OCTO needed to deliver a federated architecture that enabled the sharing of information without dictating the use of specific technology or being intrusive to an EOC’s critical data.

Before this system, a lack of communication existed between systems. Linking Emergency Operation Centers provides real-time data access across various organizations and jurisdictions so officials have access to a unified view of an emergency situation.

This new system provides inter-jurisdictional coordination in the National Capital Region. One benefit of this is the ability to learn about and respond to a Homeland Security threat much faster than without access to real-time, cross-border information.

Short-term goals included the establishment of an organizational and technology infrastructure that improves inter-jurisdictional coordination within the National Capital Region; building and documenting project elements that may be replicated in other parts of the U.S.; and producing demonstrable accomplishments within one year.

Long-term goals include the ability to communicate incidents among the National Capital Region jurisdictions; accelerate communication of real-time incident and event information; speed recognition of and response to public threat events; and allow the user to analyze and present data in a more informative manner, driving key decisions using new, actionable intelligence. This intelligence assembles information from dispersed and unrelated sources so that it may be acted upon.

The District of Columbia and its partners in the surrounding metropolitan areas can significantly improve coordinated response to public safety and homeland security threats.

CapStat provides technological infrastructure to integrate public safety and emergency response data from the District of Columbia and surrounding jurisdictions in Virginia and Maryland. Each jurisdiction in the National Capital Region presently has its own technology structures that make exchanging and sharing data problematic, complicating emergency response and resource coordination. CapStat is interoperable, meaning it solves the problem of incompatible or inconsistent technologies and data structures in different jurisdictions without requiring them to change their technology or adopt a single common solution. CapStat instead allows an emergency manager to obtain and view data from another jurisdiction in his or her own familiar format.

Using innovative technologies, including Enterprise Service Bus (ESB), a powerful search engine, Geographic Information System (GIS) and Web services, CapStat does the following:

• Provides a conduit to securely and effectively move data between individual jurisdictions’ systems;
• Resolves data and technology infrastructure inconsistencies that exist between jurisdictions’ systems;
• Analyzes the data to reveal patterns and trends and provides instant information in a variety of graphic forms;

• Allows queries of jurisdiction databases and internet and provides users with information based on location, time segment or subject matter;

• Notifies emergency responders and other officials of potential problems.

CapStat uses the most advanced information integration technology available to share information across space and time, and it continuously supports the exchange of data among jurisdictions.

The District government has a strong interest in homeland security issues. Dan Thomas, the CapStat Program Manager, took responsibility for preparing the grant proposal for the Department of Homeland Security and for overseeing the execution of the grant. Suzanne Peck, the Chief Technology Officer, officially sponsored the project.

The users have participated throughout the project lifecycle through the National Capital Region Interoperability project. Participants in this parallel project provide information and feedback on requirements, deployment of the system in their jurisdictions, and testing of the system operations.

The greatest challenge to the program was integrating numerous, geographically dispersed sites across the region with a multi-faceted solution that did not compromise site security and operational autonomy. The Sonic ESB provides a distributed, federated for integrating disparate data sources in a secure and reliable way.

Another challenge was to communicate and educate the benefits of an SOA. This was accomplished by continued dialogue with the internal team on the benefits of the SOA and communication of little successes that grew into large successes and benefits for the District and NCR.

CapStat developers use a variety of development tools to support the agile SDLC process. These tools fall into the categories of Integrated Development Environment (IDE), Core Development Tools, Testing Tools and Software Developer Kits (SDKs), and will be elaborated on further.

The base technical environment includes Ecplise, Visual Studio, Rational Application Developer (RAD) and to a lesser extent, DB Visualizer for database related development efforts. These IDE tools provide an application framework and development platform for developing software applications

An extensive set of tools that go above and beyond the IDE platforms were used to support development efforts. These tools include Cruise Control which serves as the continuous integration framework, Subversion which provides source control of component code, Ant/NAnt/Maven that supports auto-build, Mantis which enables issue/bug tracking and task management, XML Spy for XML modeling, editing, debugging, and transform, and miscellaneous open source tools for documentation (JavaDoc, XDoc) and logging (Log4J, Chainsaw).

Of all the core development tools, Subversion, Cruise Ctrl and Anr/NAnt/Maven support the critical development function of auto-build that is the basis of CapStat’s agile SDLC. The auto-build function provides integration, regression and status of components on a continuous basis. Nightly auto-build status is reviewed at daily developer stand-up meetings to determine if any components "broke-the-build" and the appropriate course of action for the team to resolve any issues.

The final set of "tools" that developers will utilize through the SDLC will include SDKs, which are the toolkits for integrating various custom and packaged software components within the overall application architecture. SDKs identified include the Java SDK which is a java development tool, the ESRI SDK for GIS integration, the Business Objects SDK for business intelligence integration and potentially the HP Openview SDK for integrated operations management.

Numerous testing practices and tools were employed to ensure quality products given the significance of testing within any IT/IS capability. On the practices side, testing is integrated into the development with developers required to design and build test components before they even begin designing and building functional components. The value in doing this is that developers identify potential failure points with the functional component before coding of these components even starts, which saves time and enhances quality. The test components that are built are used individually by developers and also incorporated into the auto-build process that tests integration and regression. Testing tools include N-unit, J-unit, HTTP-unit, Grinder and J-Meter. Testing tools to be used in the near future will include tools from the Mercury Interactive suite for testing end-to-end application functionality and potential stress/performance issues.

An agile development approach was used that focuses on "use case" requirements, practices test-driven development, schedules shorter fixed-time-iteration development cycles and engages stakeholders consistently through-out the SDLC. To ensure timely and quality results, the development process is formally tracked through daily stand-up meetings and an automated build process that facilitates integration, regression and deployment of application components on a continuous basis.

Throughout the integrated design-build-test phase of development, stakeholders validate requirements and perform hands-on reviews of features as the applications are being designed and built. For instance, over the last 10-week development cycle, stakeholders were engaged at the onset to define and confirm requirements, and then attended design review sessions every two weeks to perform user acceptance testing (UAT), to provide feedback on application functionality/interfaces and to provide sign-off on the finalized application. The results are applications that better support the stakeholder business analytical needs.

The project management methodology includes the normal phases of plan, design, build, test, deploy, however, design-build-test are an integrated phase that aligns with the agile software development approach.

Software quality metrics are used through various stages of the SDLC as follows:

• Integrated Design-Build-Test – Daily metrics on passed/failed components of the auto-build.
• Integrated Design-Build-Test – Number of user acceptance tests passed/failed.
• Deployment – Number of UCs delivered in application release.
• Deployment – Number of users/groups who have received an application release.

The greatest challenge to the program was integrating numerous, geographically dispersed sites across the region with a multi-faceted solution that did not compromise site security and operational autonomy. Team responded by employing open flexible technology accommodating participant technologies with minimal impact.

To achieve the SOA infrastructure for CapStat, the District of Columbia implemented Sonic ESB (enterprise service bus).

The District selected Sonic Software for this project because Sonic ESB was uniquely suited to address the highly distributed and federated nature of the CapStat environment. It also allowed the flexibility of adding Emergency Operation Centers in the future with no additional customization at each site. The extra work of connecting the hubs using other solutions would have been a large undertaking, while connecting Sonic brokers is minimal and linear. Also, Sonic ESB provide a Continuous Availability Architecture (CAA), ensuring that communications between services in the CapStat environment are always available—an absolute must for this public safety service.

Other technologies used include a powerful search engine, Geographic Information System (GIS) and Web services.

CapStat uses a service-oriented architecture (SOA) to connect EOCs across the region. An enterprise service bus (ESB) is used to connect, mediate and control the flow of information across the architecture. Distributed service containers are used to host integration services, such as a transformation service, at remote EOC locations across the NCR. The service containers can be remotely configured, deployed and managed, reducing the need for EOC IT staff to have specific knowledge of the ESB. Additionally, the service containers help ensure reliability across the system, and can also host communication brokers where and when messaging horsepower is required to scale the system.

CapStat uses XML to communicate between EOCs, leveraging a common XML format within the bus that can be easily transformed to the formats used by individual EOCs. Because of this, an innate ability to move from one platform to another without consequence is assured, so each jurisdiction could use its existing technology without being forced to change over to anything new.

Sonic ESB, as part of the SOA Suite, gives the District of Columbia the ability to effectively publish exchange data between EOC sites distributed across multiple jurisdictions, making this a model for other local governments seeking to enhance public safety.

Seven

The developers are .NET, J2EE and general application and enterprise application integration (EAI) architects.

Software training was provided to the development team on FastSearch and Sonic ESB, through their respective vendors.

It took 30 days to build the SOA, however the duration of the CapStat project is a full calendar year.

Yes

If yes, please explain why.

Yes. Obtain formal commitment from external organizations at initial stage in project.