Developing Forward Looking Software at CDC

By: Jim Nasr, MBA
HHS Entrepreneur in Residence

Unbeknownst to the casual observer, the Centers for Disease Control and Prevention (CDC) is actually a quite large developer of software. Such software supports the collection, management and analysis of public health data that we as a nation rely on in the form of recommendations for healthier living and preparedness for emerging diseases.

A number of underlying currents have led us at CDC to reconsider what it takes architecturally (or holistically) to build quality software to serve our needs now and in the future. These currents include: the state of our existing application portfolio, desire for intra and inter agency application interoperability, federal mandates, trends in public health, as well as emerging technology standards that enable richer innovation and ultimately better citizen interaction.

CDC is at heart a data organization—enabling “open data” supports its mission and in many ways aligns to the larger federal direction for open data initiatives. Our hypothesis for building forward looking software at CDC is that if open data is the mission then standard Application Programming Interfaces (APIs) to software and supporting modern DevOps are critical—king—and the way we have built software in the past is not the way to proceed to meet this mission.

We believe that a micro-services architectural style for development, with particular focus on using proven open source and uncoupled technologies, is the way to build forward looking software. Micro-services is a variation of the relatively mature services oriented architecture approach, where services are designed to be loosely coupled, small (ideally atomic functionality) and have a bounded context.

A micro-services approach displaces the complexity of software development—smaller, simpler, business domain driven software components that interact in a distributed manner in a more complex assembly (DevOps). This bring opportunities and challenges. In the long-term, if executed well, we reap the benefits of reusable software components, reduced domain-driven application development, and leverage a common, albeit tricky, DevOps infrastructure that supports multiple applications and initiatives. In theory, this reduces the cumulative cost of building software at the portfolio level.

The example below shows how a “traditional” siloed application may be reconceived in the micro-services architectural style:

To the faint of heart and…ahem…the rational, coming from a world of building software in the traditional manner of siloed applications, large code bases, and coupled functionality and technologies, micro-services may seem a bridge too far. Perhaps.

Is continuing in the same manner of building applications the answer? How about relying on one or more vendor “platforms”? Is there a way to mitigate risk with micro-services? My 2¢: no, no and yes.

To mitigate risk in pursuing micro-services development, and to prove critical concepts and educate ourselves, we need to start small. There are large challenges and lessons to be absorbed—the least of which is the implementation of the technologies involved. There are important culture (people), process and organizational changes needed—critical enablers for success.

We plan to use an internal R&D—Accelerator—Team in our charge to start small and lay the foundation for building forward looking software using micro-services. For more details, stay tuned for my next blog coming soon: “The Role of an Accelerator Team in Building Micro-services.”

If you have any comments or questions about this blog, we invite you to submit your feedback to surveillancepractice@cdc.gov with the subject line as the title of this blog.