Government of Washington, D.C.
I. Project Information
Company and division name:
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
Brief explanation of the goals of the project:
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.
Brief description of the business risks involved:
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.
Brief description of how the system helps users:
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
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,
II. Organizational Objectives
What short- and long-term benefits did the organization achieve from
the project? Did the solution meet the projected goals for saving time and money?
How were benefits measured? Was the system mission critical to the organization?
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
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
Describe the business purpose of the new system.
The District of Columbia and its partners in the surrounding metropolitan areas
can significantly improve coordinated response to public safety and homeland
Describe the features of the new system.
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.
Explain the functions of the new system.
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
- Resolves data and technology infrastructure inconsistencies that exist between
- 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.
Who were the internal sponsors of the project? Which officials or
groups were opposed to developing the application? Why?
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.
Were users of the system involved in the project during the planning
and development phases? If so, how?
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.
What were the greatest challenges in completing this project? How
were they overcome?
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
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.
Were the goals changed as the project progressed? If so, what were
the changes and why were they made?
Goals remained the same but specific data/Web services changed to accommodate
the interests of the stakeholders and availability. CAD 911 data is not available
in the project timeframe.
Please indicate the Innovator Award category as listed below.
Describe how productivity tools or techniques were used in the project.
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
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.
Were testing tools used during development? If so, when were they
used? Was the testing cost-effective?
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.
Was a formal or informal software development life-cycle methodology
employed? If yes, please describe it.
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.
What formal or informal project management methodologies and/or tools
were used to manage the project? If used, please describe how.
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.
Were software quality metrics used? If so, what were they, and did
using them significantly help the project?
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
What were the major technical challenges that had to be overcome to
complete the project successfully? How did the team respond to those challenges?
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
What software tools, including databases, operating systems and all
development tools, were selected for the project? Why were they selected over
competing tools? What process was used to select development tools and software
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.
Describe the overall system architecture. Were elements of the technical
infrastructure put in place to support the new system? Please describe.
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.
What characteristics of the tools and technologies used were most
important in achieving the business purposes of the system?
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
VI. Project Team
What was the size of the development team?
Describe the software development experience of the team members.
The developers are .NET, J2EE and general application and enterprise application
integration (EAI) architects.
What was the composition and skill level of the team? Did development
teams require training to work with the technology?
Software training was provided to the development team on FastSearch and Sonic
ESB, through their respective vendors.
How many person-months/days did the project take, and over what calendar
time frame? Was a formal schedule created at the start of the project? Did the
project stay on schedule?
It took 30 days to build the SOA, however the duration of the CapStat
project is a full calendar year.
Did management and the user community consider the project a success?
If you had to do the project over again, would you do anything differently?
If yes, please explain why.
Yes. Obtain formal commitment from external organizations at initial stage