The Air Force encounters turbulence of the digital kind when it underestimates the complexity of moving the service to a single network.
The U.S. Air Force’s migration to a new enterprise network known as AFNET will be at least two years late in completion because the project turned out to be more complicated than planners anticipated.
The move to AFNET was designed to eliminate costly and increasingly difficult-to-maintain stand-alone legacy networks at 27 of the Air Force’s bases and major commands and consolidate the service under one global network. AFNET also includes the creation of regional processing centers located at Scott Air Force Base, Illinois; Wright-Patterson Air Force Base, Ohio; and Joint Base Andrews in Maryland, just outside of Washington, D.C. And, while the service has begun to see some benefits from the migration, the project is not expected to be finished until sometime in 2014.
“We underestimated the complexity of trying to do the migration with all those different standards,” admits Markus Rogers, director of network architecture with the Air Force Network Integration Center (AFNIC), Scott Air Force Base. AFNIC has been tasked with being the central unit responsible for all aspects of the project, including technology, training and acquisition; work began in 2008.
At first, AFNIC developed what can best be described as a false sense of accomplishment when it began the AFNET migration in the offices of one of the Air Force’s major commands, the Air Mobility Command. “We started with them because they had already consolidated, and we wanted to use the lessons learned from their consolidation in our process moving forward. And, we were very successful with that command,” indicates Rogers.
However, the success was to be short-lived, or as Rogers puts it, “We underestimated then how much harder it was going to be to move to the next command, which was the Air Education and Training Command [AETC].” The difference here, he continues, is that the AETC had not yet consolidated its network, “and that was something we had not planned for when we began the migration. That was the cause for some of the initial delays that we had,” he explains. The primary lesson learned was, “Don’t underestimate the complexity, and while everyone would say, ‘Yes, we are not standard, we know that and this is going to fix it,’ I would say that we did not know how nonstandard we really were,” Rogers says. As a result, the AFNET migration, which was to have been completed by the end of 2012, now is expected to be completed by March 2014 at the earliest.
In addition to the technology challenges, a cultural change was required, which Rogers admits also was vastly underestimated. He says that prior to AFNET, the bases and major commands managed their networks and infrastructure very independently. “They had built it to meet their requirements, and it was managed to meet individual requirements. However, when we stand up the AFNET, they now become a part of that Air Force network, and they no longer have their own standard that they have to meet. They now have to fall in line with the Air Force standard, and that cultural change was much more difficult than originally expected,” he says. For the most part, he considers much of the cultural resistance to have been overcome, and part of the credit goes to a key AFNET component, the Enterprise Service Desk (ESD).
Considered the centralized help desk for the entire AFNET, the ESD replaces the local help desks at bases and major commands. Now, AFNET users have one number to call for help, and, just as they do in private and public sector network operations centers, a trouble ticket is issued and tracked as part of the resolution process.
While the AFNET ESD has resulted in some significant efficiencies in handling trouble ticket items, and AFNIC has begun to see an overall reduction in the number of those trouble tickets, Rogers admits that some consideration is being given to returning some limited help desk functions to local bases and commands. “When the ESD was first stood up, bases and commands lost all their permissions, and you had to go to the ESD, and they would help. There’s been an understanding since then that this is not the most effective way to work the service desk, and there’s been some discussion of providing permissions down to the base/command level—limited permissions, but in very certain areas to allow local personnel to resolve some of these issues in a timely and more cost-effective method than trying to do everything centrally,” he explains.
Rogers explains that much of the reason for the delay can be traced to the three-phase process that must take place at each base and major command as part of the AFNET migration. In the first phase, AFNIC personnel travel to the individual facility and begin a preparation process that includes meetings with key personnel. “The second phase is what we call our user migration. This is when we come to a base, and this is the visible part of the activity, because this is where we move the users’ cheese, so to speak. They are now taken out of their legacy network, and they are put into the AFNET. That activity generally takes one to two months on average per facility, depending on the size,” he explains.
The final phase of a facility’s migration to AFNET also can be the most troublesome. “The part that is often overlooked in this process, and that is driving some of the longer periods of time to do the migration, is what we call legacy shutdown. This is where we actually migrate those legacy servers. That’s a period of time that’s very invisible to most users, but that goes on for approximately six months after we migrate a major command and as much as two to three months at a major base,” Rogers says. Along with the servers supporting legacy applications, servers supporting specialized functions and mission-specific applications are attached to AFNET for the first time, and at that point, the facility’s local network is turned off.
Rogers says as of early May, the AFNET migration has been completed at seven major commands: the AETC; Air Force Reserve Command; Air Mobility Command; Air Force Global Strike Command; Pacific Air Forces; U.S. Air Forces in Europe; and Air Force Space Command. He notes the process is considered totally complete only when the legacy networks are shut down at the major command domains. To date, this has occurred only at the Air Force Reserve Command.
In recent years, the Base Closure and Realignment process has forced many single-service military bases to become joint bases, supporting the activities of two or more defense services simultaneously. Rogers says that the move to joint bases also has caused some delays in the AFNET migration. “A lot of that is the coordination, because one service is usually in charge of that one area, but network connectivity is usually maintained by that service. So, the Air Force will run its own network, the Navy will run its own network, but that infrastructure may not necessarily be owned or run by the Air Force. That coordination between them has been challenging at times,” he admits.
Candidly, Rogers believes it is possible the Air Force may encounter even more unexpected challenges as the AFNET migration branches out to other facilities before the expected completion of the project, resulting in further delays. “Every time we start another command or start another base, we essentially have to re-learn a lot of what we learned before,” he explains. And, while there are many similarities between the stand-alone networks at Air Force facilities, it is the differences—and dealing with those differences—that complicate matters, he adds.
Lest anyone lose sight of why the AFNET migration is happening, Rogers says, all it requires is looking at some of the tangible results of the work done so far. “We’ve had a net reduction of 2,603 servers over the last four years that the Air Force no longer has to support,” he notes, and adds that in some cases, standardization has allowed AFNIC to consolidate the functions of several legacy servers into only one AFNET server. In addition, AFNET has helped elevate the level of cybersecurity on the service’s networks because bases and commands no longer depend primarily on their own network connections. Rogers adds that standardization has made it easier and faster for AFNIC to patch and deal with network vulnerabilities as they are uncovered.