Software as a Theme Park

By: Jim Nasr, MBA
HHS Entrepreneur in Residence

As technology folk, we too often speak a lingo and at a tempo that leaves many people outside our profession confused and too embarrassed to ask questions. The words sound comprehensible—“Our big data APIs abstract access and decouple the data source…”—but often the communication falls flat.

However, comprehension of key concepts and their interconnectedness by the people who use the technology is critical to making good enterprise decisions. You need to be able to communicate those key concepts to stakeholders to get buy in, to get correct implementation, and to effectively maintain systems.

Our challenge in public health is twofold. We need to know how to effectively communicate software decisions and direction to a large customer base of physicians, epidemiologists and public health experts, and we need to ensure that direction can be efficiently implemented by a large number of disparate implementers working on unconnected, separately funded, contract-based projects.

Luckily, software, as with other abstract topics, can be modeled to simpler, physical metaphors that are generally understood and easily visualized. So, for instance, imagine conceiving interoperable software as playgrounds in a contiguous theme park.

You pass through the turnstiles—the API Gatewayexternal icon in our software world—to get in. You get an identifying park wristband—OAuth2external icon session or application token—that allows you access to most attractions within (of course, you need a premium pass to get to certain things…). Before you get on any ride, or enter any playground, we’ll check the wristband to make sure you’re in the right place and are tall enough to get on the rides.

Each playground offers something a little different: roller coasters, racing tracks, lazy lake, Ferris wheel and so on. Yet, all playgrounds are connected via linked walking trails or a monorail, are served by the same power grid, have the same security staff and the same set of restaurants and souvenir vendors. Even the playgrounds that are under construction and cordoned off are clearly labeled and their perimeter is visible to the naked eye.

So, to our Software Theme Park (below):

Figure 1: Proposed Software Theme Park

Figure 1: Proposed Software Theme Park

The playgrounds represent software functions. These functions are primarily composed of interoperable, repurposable services, largely built on open source software, deployed as Docker containersexternal icon. The goal is to have non-redundant functions that can be meshed up in different combinations and permutations to serve a larger context—an “application” (e.g. automatically validate and route incoming infectious disease messages based on business rules and machine learning). The color coding represents function ownership; in certain cases, more than one group or center owns a function—represented by the patterned colors.

The Software Theme Park is a living document which we expect to evolve with more playgrounds to be added in the future and possibly removal or consolidation of others. Key is interoperability between the playgrounds. That is achieved through deployment of standard contract definition services, regulated through the API Gateway.

As with a real Theme Park, there’s more to our software edition than just what’s on the surface. A foundation is needed to support all the fun. As shown below, we see the foundation as two additional interconnected layers beneath the functional areas: software blueprint and DevOpsexternal icon layers. The blueprint layer specifies the software components supporting the functions. The DevOps layer facilitates building, automating and deploying software in this manner.

Figure 2: Composition of the Software Theme Park

Figure 2: Composition of the Software Theme Park

Does this way of conceiving software implementation for an enterprise create issues? Most definitely. The first and the biggest problem is cultural.

Many larger organizations, including almost all government agencies that I am aware of, are used to building software as a monolithic—a large comfort zone where you rule the kingdom. Build or buy to meet specific needs at the time, without much regard for conceiving the solution with greater utility or modularity. Empirically, that leads to tremendous redundancy and a laundry list of (literally) thousands of “systems” that create long-term dependencies and stifle innovation. The lion’s share of IT budgets is spent in maintaining these “systems”. The collateral damage is more than just financial however, as much of the time and attention of key people in the organization is spent on the weary.

So, the one Software Theme Park is no easy ride if your starting point is dozens or (frighteningly) hundreds of disparate, disconnected playgrounds disguised as their own mini-theme parks. Some sacred cows have to be put to pasture. Others forgotten as an illusion.

What we have seen though is that the initial heavy carry is worth the effort. Clarity is power. Once achieved, it’s much easier to reverse the wheels of inertia.


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.

Page last reviewed: November 15, 2019