Intense budgetary pressures are changing the federal government IT environment from one in which individual agencies buy products and services to one in which agencies must work with one another, as well as with contractors and other partners, in new and innovative ways. This new approach will fundamentally change how agencies architect their networks. It will also likely change the career path for many government IT professionals.
The demand for next-generation networks gained new momentum last year when the Office of Management and Budget (OMB) released the Digital Government Strategy, tasking all agencies "to unlock their data sets and services to the public" and function more like data service providers. Since then, the Centers for Medicare and Medicaid Services (CMS), the Department of Homeland Security, the Defense Department and other agencies have been developing new ways -- and new network architectures -- to make their data accessible to the public, industry and other agencies.
The Digital Government Strategy in particular requires agencies to ultimately separate their data from their presentation layers.
For example, CMS supports all Medicare and Medicaid services for 98 million beneficiaries. The initiative to separate the presentation and data layers led the agency to develop a business rules engine that's shared by developers within CMS and industry partners. By implementing a set of business rules as a service, separate from the data, CMS system users can access a single source of truth rather than different permutations. That common rules engine also makes it easier to develop applications.
Implementing such a business rules shared service completely changes the way the network must be structured. The bifurcation of the presentation and data requires a bifurcation of the network as well.
For instance, a network architected to handle client and server communications, where the business logic resides within the application, requires a much different architecture than a network where every application is requesting data from a central core business rules engine. The latter will transmit many thousands -- or millions, potentially -- of small, simple requests across the network from almost any endpoint (contractor, partner or secondary data center). Scale is important. CMS expects to process about 700 TB of claims data by 2015, data accessed via requests from many different end users who can be anywhere within or outside CMS's networks.
Gone are the days of a single network with hub-and-spoke architecture and a single core. The next-generation network is split into two: core and business. We'll discuss business networks later.
But start thinking of dedicated networks using software-defined networking (SDN) and "network functions virtualization," which is the term used for describing the collapsing of switches and routers into virtualized switches and routers.
OMB's Shared Services Strategy, and the follow-on document titled "Common Approach To Enterprise Architecture," requires agencies to separate line-of-business systems (e.g., for financial management) from core mission systems. It also tasks agencies to further separate commodity IT (such as infrastructure and email). That requirement will move agencies more toward virtualized applications, platforms and infrastructure. But it also means that government networks must be easy to modify based on changing directives, interfacing agencies and end user demands. The essence of the new federal architecture is agility.
Because the core network supports many stakeholders, it must be secure, scalable, high bandwidth and reliable while meeting compliance requirements. It's likely to stay somewhat physical, as it will link a variety of third parties: partners, contractors and remote locations. It will require custom processors and code to perform high-efficiency routing and switching.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.