Case Study: How D.C. Successfully Integrated Technology

"Worst to First" is the rallying cry in the Office of the Chief Technology Officer in Washington, D.C., which now has one of the best technology infrastructures in the country.

Six years ago, Washington, D.C., was plagued with one of the worst technology infrastructures in the country. Today, it can boast one of the best, with a long list of enviable improvements: Many of its once-pokey public services—including drivers’ licensing, tax refunds, policing and snow removal—are now being handled electronically, and intragovernment communications and collaboration have advanced considerably.

In fact, progress has been so dramatic that in 2003—and again in 2005—the District of Columbia received the coveted Best of the Web award from the Center for Digital Government. The BOW awards represent just a few of the many national and international accolades D.C. received for city delivery of services over the Internet.


While “Worst to First” has become the rallying cry at the Office of the Chief Technology Officer (OCTO) in Washington, D.C., we are not resting on our laurels. Major challenges lie ahead, as District government is not yet a fully integrated data enterprise.

Before OCTO, IT investment in the District helped preserve dysfunctional agency data silos by granting agencies proprietary interests in their own data. Now, however, OCTO has devised a strategy that integrates multi-agency data, while preserving legacy data investments. OCTO dubs its strategy the District Enterprise Integration Stack (DEIS).

This new data and application integration model incorporates an array of enterprise application tools, data warehouses, portal frameworks and Web services. DEIS consists of four layers with cumulative functionality.

Level One defines stovepiped legacy application data from 66 District agencies. Level Two allows District agencies to tap into this districtwide legacy data and communicate with each other as needed. Level Three permits interagency collaboration to solve critical citywide problems in areas such as public safety and human services. Level Four invites the public in, offering a common data look and feel so that citizens—and the city employees who serve them—can easily navigate city government services.

While several years from fully achieving this vision, the city is already reaping extraordinary rewards from the DEIS architecture. Citywide adoption rates for integrated applications are up, operational costs are down and agency resistance to change is dissolving. Perhaps the most significant achievement is that residents now frequently comment on the ease with which they complete routine transactions with their government.

Modern municipal enterprises are typically mixes of highly complex and heterogeneous IT environments. It’s challenging to explain, much less execute, service-oriented, integrated citywide applications.

OCTO met this challenge by organizing the city’s entire application-level enterprise into the four-tier District Enterprise Integration Stack. DEIS takes data elements from low-level sources and passes them up the “stack” to make them more usable and sharable throughout the enterprise. It’s this ability to free data from its original single-agency constraints that makes DEIS so powerful.

Layer One: Starting From Sprawl

During the citywide year 2000 (Y2K) upgrade in 1998 through 1999, OCTO identified 390 critical agency applications—not counting miscellaneous ad-hoc systems. The District’s legacy applications had grown, randomly and separately, for 30 years within 66 city agencies, and there often was little documentation.

Initially, OCTO tried to tackle the problem of enterprise data accessibility through product standardization. But standardizing products could not really solve the problem of how to align new applications with mission-critical legacy systems. How, for example, would the city’s new state-of-the-art enterprise resource planning (ERP) systems— back-office systems like human resources (HR) and procurement—interoperate with the somewhat dated, but still reliable, general ledger financial system?

Instead, OCTO adopted emerging enterprise application integration (EAI) tools. These tools are sets of brokers, connectors and middleware that use Extensible Markup Language (XML) to connect existing legacy IT systems.

While Web browsers take data and make it accessible to consumers, EAI takes data from one set of servers and makes it accessible to applications on other servers. OCTO’s objective was to give the city’s highly decentralized IT environment a common communication highway through EAI.

Taking advantage of EAI integration capacities, OCTO linked data from the new ERP applications with critical inherited applications like the general ledger system. The solution worked so well for administrative services that it was extended to human services and customer management initiatives.

Anticipating increased demand for integration, OCTO negotiated an “all you can eat” EAI license from one software vendor, essentially driving the cost of EAI software for successive DEIS initiatives down to zero.

Layer One of the DEIS divides legacy applications from the city’s 66 agencies into nine functional clusters: administrative, financial, human services, education, public safety, motorists, property, customer service and transportation. Each has its own EAI broker, which manages the data dictionary for its functional area.

These dictionaries are the Rosetta stones of DEIS. They permit legacy applications to communicate with one another, even though each speaks a different language. They automate multi-agency data communications for the first time, and save thousands of hours monthly in error-prone duplicative data entry and point-to-point communications.

For example, the Mayor’s Call Center uses a custom EAI adapter to connect its software to the customer service broker. That broker, in turn, translates these requests electronically into a format that’s understood by the fulfillment system at the Department of Public Works.

And the public sees the benefits. A broken streetlight is fixed. A pothole is filled. Uncollected trash is picked up.

City managers see the benefits as well. The Public Works application automatically reaches out to close a service request at the Call Center when a complaint has been handled, so repeat complaints are minimized and hundreds of hours of duplicative data entry are eliminated. Citizens can now track the status of their service requests on the government’s Web site. Standing alone, Layer One of DEIS is a model of government responsiveness.

Layer Two: Intelligence on Tap

The Enterprise Service Bus (ESB), the heart of Layer Two, is message-oriented middleware that allows software applications to subscribe to information stored in other software applications. The ESB in Layer Two provides a communications channel through which individual systems can “talk” (even though they may not be aware that their partner systems exist). The Call Center information, for example, is now updated every six seconds and is available to any system that has permission to subscribe from the ESB.

In this second level, the communication between systems is not as tightly coupled and controlled as it is in Level One. For example, if the police department wants to subscribe to information about streetlight repairs, this can be done through the ESB, without seeking anyone’s permission. If, however, the police department wanted to close streetlight repair tickets in the Citywide Call Center, it would have to connect lower in the DEIS stack as part of the Customer Service Broker.

Layer Two publishes data to the ESB primarily through an Extract-Transform-Load (ETL) capability. ETLs serve as on-ramps to the ESB from the agency brokers. Because privacy of personal data is critical to many government programs, OCTO put the on-ramps under the governance of agency clusters to avoid compromising data confidentiality.

Properly executed, the separation of tiers allows the city to have the best of both worlds. Inside the Public Safety cluster, for example, the police and courts share crime information freely. But by the time the data reaches Level Two, it is filtered, so that only summary statistical data—not crime victim names and addresses—are available.

The ESB populates the D.C. Stat Enterprise Data Warehouse. This warehouse, driven by a citywide license for the Business Objects suite, is the repository of information at the citywide level, and it’s used for cross-agency business intelligence as well as for the city administrator’s enterprise decision-making dashboard. The city administrator’s mandate to publish District agency performance information to the D.C. Stat system has supplied enormous incentive for agencies to participate in citywide integration efforts.

Layer Three: Applying the Power

In Level Three, DEIS’s formidable power to improve government service increases exponentially. The application of enterprise integration strategy across city services achieves substantial cost economies and service-level improvements.

The District has defined nine major services modernization programs (SMPs), each one corresponding to one of the nine EAI brokers described in Layer One and each covering a critical area of the District’s core business responsibilities. SMPs go beyond defining agency legacy data to each other (Level One) or sharing that data (Level Two). Each SMP powers a set of major multi-agency applications designed to automate work in that service area, regardless of how many agencies need to collaborate.

The District’s nine SMPs are at very different stages of their life cycles. The first SMP, the Administrative Services Modernization Program (ASMP), includes modules for procurement, HR, agency performance management, payroll and property management. It is almost complete after two and a half years of development.

The second SMP, for human services (HSMP), is rolling out its first modules. HSMP includes citywide human service case management, claims and complaints adjudication, benefits eligibility and benefits enrollment.

The next two SMPs, safety and property, are completing their planning phases. Requirements have been defined, and each system has a fully fleshed-out architecture, but the city is just beginning development of cornerstone applications, such as police records management and centralized real property data.

The advantage of launching these nine programs within the DEIS stack is the ability to create applications that work across agency boundaries. Take human services, for example. Ask any city or state about its worst administrative horror stories, and human services will usually rank as number one.

When the District’s HSMP system is fully functioning, the benefits application system will interact with the case management system. Both, in turn, will be able to work seamlessly with the disbursement system being planned within the Financial Services Modernization Program (FSMP). The capacity to present a single face of government to both clients and caseworkers is possible only through the groundwork laid in Layers One and Two.

While the SMPs represent great technological sophistication, ultimately, applying technology is not the most important work these programs accomplish. Even more valuable is the chance for District and agency leaders to conduct a rigorous examination of their business processes.

When agencies truly understand what their neighboring agencies are doing and the efficiencies they can gain from working together, their resistance to change dissolves. Then agencies see the structural data flexibility oriented in Layers One and Two as a vital resource to help them reach their own re-engineering goals.

Increasing interagency collaboration and efficiencies are valuable benefits of technology. But the direct payoff for citizens comes into play in Level Four, the public face of DEIS.

Layer Four: Bringing It All Together

Technological wonders are meaningless if government doesn’t work directly for its citizens. And this axiom is doubly true in the District, a city that has long been notorious for poor public services. Consequently, OCTO has adopted a crystal-clear set of operating tenets for IT interactions with constituents:

• A single point of entry. All citizen requests must be routed to a central point of entry so that citizens are not left to wander helplessly among 66 agencies to find what they need.

• Guaranteed closure. Every citizen must be assured that his or her request, once submitted, will be fulfilled, no matter which agency or how many agencies are involved in the transaction.

• Benign service delivery. OCTO’s charge is to make dealing with government as positive as possible.

How did we deliver on these promises? In the first three layers of DEIS, OCTO worked from the inside of government out. For the final layer, OCTO had to flip the point of view, looking at the business of government from the outside in.

Citizens come into contact with government by one or more of six routes. They walk into an office; telephone an office or call center; send mail; send e-mail; use the District’s Web site; and/or submit information through a wireless device, which is rare.

The fourth layer of DEIS serves as a common gateway for all six of these customer channels. This layer provides services to constituents and serves as an information resource for employees. Information must be consistent, accurate and up-to-date for both employees and citizens.

To deal with this challenge, OCTO began with an enterprise license for a Web portal. The portal framework presents data and applications from the DEIS stack, whether the customer walks into an office, calls the call center or checks the Web. All channels of information remain consistent, up-to-date and accessible.

When the integration plan is complete, every District customer service representative will have access to the same information and transactional applications at their computers. And constituents will see the same data and applications on their computers via Imagine a day when residents can walk into virtually any government office—from the Department of Motor Vehicles to Tax and Revenue—to register their business, order bulk trash pickups and pay property taxes, all at the same time!

The last features of the fourth layer are Web services that allow citizens to track their transactions across multiple agencies. Let’s say a neighborhood group wants to throw a summer block party. In the District, a simple block party requires permits or licenses from five city agencies. Today, these agencies have no way to coordinate with one another, and the neighborhood group has no clear way to navigate among them. They have to start, track and finish five transactions with five agencies for a single event.

The Level Four Web services of DEIS connect all agencies in the city, creating a one-stop-shop for constituents. The District is creating a simple set of services that allow different applications and agencies to coordinate data and services about commonly used people, places, things and processes.

Three of these services—people, places and processes—are in pilot mode. An example of a “people” service is a single sign-on Web service that allows residents to log onto all their applications at one time through an enterprise Lightweight Directory Access Protocol directory.

The most popular “place” Web service is address verification, which allows an application to check an address against the citywide geographic information system and suggest corrections to prevent entry of incorrect addresses into our enterprise systems.

The third pilot is a “process” service. The service request workflow Web service (tied to the Customer Service Modernization Program broker) allows users to track their service requests across agency boundaries. When adapted to block parties, this Web service will allow the neighborhood group to submit a party permit request just once. The Web service will automatically route the request to all five agencies and e-mail the requester once all necessary permits are approved.

The service-oriented architecture of Level Four—and DEIS generally—fulfills OCTO’s three promises of single point of entry, guaranteed closure and benign service delivery.

Older urban areas like Washington, D.C., are full of inherited silos. In this kind of environment, an enterprise integration strategy isn’t just a technology project. It’s a critical part of the city’s commitment to modernize the way it governs and conducts its business. It’s the way to travel from “worst to first.”

Lessons Learned

The story of Washington, D.C.’s District Enterprise Integration Stack is a complicated one that involves necessary comparisons with the processes that preceded it. However, two lessons stand out:

• Leaders intent on modernizing government must learn to work with legacy data systems. No matter how outmoded legacy information technologies appear to be, they have been—and can still be—reliable workhorses. The latest bells and whistles are always tempting, but policy-makers must choose IT investments with municipal objectives in mind.

• Evolving applications from the private sector promise to revolutionize government effectiveness and efficiency. What the public sector can draw from the operations of the private sector holds great promise for improving municipal operations and service delivery.

How Washington, D.C., Integrated Its Technology Infrastructure

The Goal: To devise a strategy that truly integrates multi-agency data—while preserving legacy data investments—and frees data from its original single-agency constraints.

The Solution: Take data elements from low-level sources and pass them up the “stack” to make them more usable and sharable throughout the enterprise.

The Technology: Enterprise application-integration tools.

Christina Fleps also contributed to this article.

Suzanne Peck is Chief Technology Officer for the District of Columbia Government. Jamey Harvey is the Deputy Chief Technology Officer responsible for citywide government integration. Christina Fleps is the chief business writer for OCTO.

Oct 31 2006