DISA's NCES aims for enterprise transparency

A high-profile attempt at nudging the Defense Department into a service-oriented architecture (SOA) environment cleared a major hurdle June 19 when the Defense Information Systems Agency’s Net-Centric Enterprise Services program earned approval to enter the production and development phase. NCES officials say the number of users should grow into the millions in the next two years, and the program should achieve initial operating capability by the second quarter of fiscal 2009.

“The potential for NCES is enormous, and it’s addressing the more challenging areas in the government,” said Warren Suss, president of Suss Consulting.

Because each branch of the military built separate enterprise systems, officials are often suspicious of attempts to make the computing environment more agile. Such changes affect how data is consumed and software is designed — changes that aren’t incidental to how organizations do their jobs.

In addition, many military officials are cynical about SOA and its promise to deliver highly accessible data and nimble application development. Blame their suspicion on a hype machine that software vendors and trade publications created by casting SOA as an instant revolution that could single-handedly eliminate obstacles to breaking down technological and cultural barriers to information sharing.

NCES won’t immediately crack open all stovepipes – some of which have already been breached. “If you know where to look, you’re probably going to find it,” said Rebecca Harris, program director of DISA’s Program Executive Office for the Global Information Grid Enterprise Services program. “But if you don’t know where to look, you might be lacking information or a capability that might help you do your job.” That’s where NCES hopes to make its mark.

Are you being served?
NCES is a combination of functions that directly and indirectly support information sharing. “It’s what I would term an information-sharing capability and infrastructure,” Harris said. A basic component of NCES is its SOA foundation, which other organizations can use to construct services.

The idea behind SOA is simple: Don’t create a new system that does everything from checking the weather to weeding the garden. Instead, break up the system into small, self-contained software chunks with standard interfaces. Each chunk is a service, and it performs a basic task. Other software developers can reuse those services so they don’t repeat others’ work. Data is freed from incompatible applications because a data-mediation function helps it move from one service to another. Building new capabilities also is easier because application development relies more on putting together already-assembled building blocks than crafting original code. Ultimately, services could be stitched together during runtime, although experts agree that this is a long-term hope rather than a short-term possibility.

“SOA is really about an architectural style in which I’m trying to separate the applications from the underlying data, where I’m trying to make important parts of my business process visible and using that to drive the software rather than the other way around,” said Frank Petroski, director of integration of data and services at Mitre.

The right size for a service – or, in SOA-speak, its granularity — isn’t difficult to determine, Petroski said. “To the extent that the service matches up against steps of my business process, the granularity is right,” he said. In other words, although it’s possible to theoretically break an application into smaller fractions, each of which could be a different service, business logic prevents that from happening.

Staying with the current strategy would be expensive to maintain, Suss said. “It’s not just expensive, but [the systems] tend to get out of date pretty rapidly,” he said. “And so the government is stuck not only with very expensive systems but also  systems that are not on par with the systems that are available in the commercial marketplace.”

I’m free!
NCES users can take advantage of an NCES-bought data messenger; enterprise service management, a monitoring tool; hosting; and other software and hardware infrastructure elements necessary to create a SOA service.

The Maritime Domain Awareness (MDA) Community of Interest – made up of military and civilian agencies – has already taken advantage of NCES to create a common operating picture via Google Maps of otherwise incompatible shipboard automated identification
signals.

“They’re able to share the information, to subscribe to only that part of the information that they’re interested in,” Harris said.
MDA is consuming NCES computing resources, but the program doesn’t charge users.

Harris is quick to dismiss a question about whether providing free computing resources to customers is a sustainable model. Congress appropriates funding to NCES, and “if we need to buy more CPUs or more servers, we can do that based on demand,” she said.

On the whole, DOD will save resources by using NCES, she added. MDA, for example, didn’t have to buy a data mediation capability to translate between existing Advanced Information Security protocols.

The Defense Travel System also is testing a SOA application that would estimate the total cost of a trip, Harris said. About 500 services are registered on the NCES central SOA registry, she said. Some of them are working components, while others are in development or testing.
DISA is also attempting to solve some of the organizational issues that hinder SOA adoption.

One issue is trusting an application that another organization developed – a problem not only of parochialism but also of security certification and accreditations (C&A). Organizations need to know a service is secure before they incorporate it. However, the official cybersecurity C&A performed by one organization might not be acceptable by another. When it comes to NCES’ SOA foundation, military services so far have been content to examine the C&A documentation, Harris said. But “that process needs to be made more, if you will, suitable for a net-centric environment,” she added.

Harris said an effort called the Federated Development and Certification Environment will develop standards so that organizations can recognize one another’s C&A.

Problems of how to resolve cross-organizational service interdependency also exist. A benefit of SOA is the ability to reuse services so that organizations don’t duplicate efforts. But if one military agency uses the service of another, what are the provider’s and consumer’s responsibilities? Does the consumer now have a say in whether the provider can make changes to that service? Can the provider demand how users can consume its data?

“There are people thinking about that and working that, but we don’t have the total answer yet,” Harris said.

SOA hasn’t made systems engineering obsolete, Petroski said. In a SOA nirvana, services would find one another during runtime, but until then, connecting services must occur when designing them, which means service owners must define their mutual responsibilities. “If I was going to be relying on someone for a critical piece of functionality, I wouldn’t build that until I had a conversation,” he said. This isn’t a problem specific to SOA; it’s endemic to any distributed system, Petroski said.

One unsolved SOA issue is how to enforce a service-level agreement among government organizations, he said. Without an enforceable SLA, how can organizations trust one another enough to start incorporating their services?

“I don’t think anybody has a good answer to that question yet,” Petroski said.

But there’s time to solve these challenges, which include things outside the purview of any one technology program, such as DOD acquisition policy, Suss said. “When we look back 10 years from now, we’ll see this era we’re in today as an era of early transformation,” he said.

Google for government
NCES also supports a direct means for information sharing: searching for it, either via what Harris calls a centralized search engine, a federated search engine or an enterprise catalog for organizations that don’t want to expose their servers to crawl engines but still need to register specific data for sharing.

NCES’ centralized search is the search engine from the intelligence community’s IntelLink. “We call it centralized because it contains the Web content that’s crawled by IntelLink,” Harris added. “It was on the [Secret IP Routed Network], and we adopted that for our uses on that network. But then we stood up an instance of it on the unclassified network.”

Adopting IntelLink’s search engine is indicative of NCES’ overall strategy of reusing existing capabilities whenever possible, Harris said. Air Force Lt. Gen. Charles Croom, DISA’s recently retired commander, said a strategy of adopt-buy-create stresses that building systems from the ground up should be the last option.

Adopting the IntelLink solution required buying products to expand the search capacity. “Usually, if not always, a buy is associated with an adoption,” Harris said. “But the adoption was that we went out and leveraged what someone else had done rather than building it ourselves or going out with a duplicative acquisition,” she added. NCES also did something similar with its Web portal, which is a modified version of the Army Knowledge Online portal.

The federated search brings together existing defense search engines and performs searches using their capabilities.

“As you can imagine, there’s a number of search capabilities across” DOD, Harris said.

The federated search “will go out and send a query out to all those other search engines and then consolidate the results and supply those back to the user.”

The terms federated or centralized can be slightly misleading as they relate to searching, however. NCES users are using both capabilities when they perform a search.

NCES provides other services, too. Two collaboration services are available via the portal, and the program offers networked content delivery as a managed service. Content delivery systems distribute content strategically across networks and try to place it as close to the user as possible.

“We have a wide spectrum of customers,” Harris said. “Depending on your mission area, you may use different capabilities, you may use
some, and you may not use any.”