How to prove the value of service-oriented architecture
Connecting state and local government leaders
Service-oriented architecture is an abstract concept that agency leaders often don't fully understand. Here's a real-life example of proving its value.
Offering data Web services is the best way for agencies implementing service-oriented architectures to prove the value of SOA to their organizations, said Dan Pelman, senior information technology manager with the Federal Aviation Administration’s Air Traffic Organization.
Why start with data? “Most times you can abstract data, you can get to it and put something to wrap around it, and share it out and bring it back in,” Pelman told an audience of federal managers at the 10th SOA in E-government Conference on Sept. 16. The conference, held every six months at Mitre headquarters in Mclean, Va., is hosted by the company along with the Federal SOA Community of Practice.
SOA is a flexible set of design principles used during the phases of systems development and integration in computing. A deployed SOA-based architecture should provide a loosely integrated suite of services that can be used in multiple business domains.
Pelman described how the Air Traffic Organization has been able to achieve big returns on its investment in a Web services-based approach via the agency’s National Airspace System. The NAS has layers of data that includes information about an airport’s terrain, buildings, runways, mandates, obstacles in the way of airplanes, rules to avoid those obstacles and other pertinent information.
Related coverage:
Service-based approach could spur application modernization
Air traffic control architecture taxis down the runway
The FAA’s Instrument Procedure Development System takes all that data and supplies it to a two-dimensional, computer-aided design system that holds all of the business rules associated with the data.
“Data, business rules, graphical user interface -- that’s the way we see the world,” Pelman said. “What does your customer care about? The GUI. They want it to look and feel right.”
Once you have these building blocks, you are in a position to serve up layers of data as services.
For example, a flight operations manager requested to access an application behind the firewall without going through the secure virtual private network. “I could have laughed and said, ‘you’re not going to do it,’ " Pelman said. Instead, Pelman asked, “What’s the problem?”
It turned out that after pilots completed their flights, they had to get off their airplanes with their secure, government-issued laptops, find a place to log on and record their hours. Pilots have to record that information immediately. They can't wait. But the system is built into an architecture that allows business layer information to be sent to a GUI through Web services.
Pelman asked the operations manager, “what if I could get you a Blackberry or iPOD where [pilots] could sit in their aircraft and plug in their time or information they needed?” The system knows the flight number and information about the aircrew, so pilots could post their information without having to go through the back-end system.
The flight operations manager had thought he would need a new application, Pelman said. However, in this case, the business rules and datasets were already there. The idea of a linked handheld device was just what the manager needed.
“What he really wanted was a new GUI that was based on the business he was trying to get done,” Pelman said. “He suddenly got excited by SOA for a second” because his problem could be solved and he only had to pay for the GUI. And it would only require a couple of hundred hours worth of work.
“Do you see SOA?” Pelman asked. “Do you see what the possibilities might be?” he said as he implored the enterprise architects present to take up the SOA mantle and deliver it to senior IT and business management.
NEXT STORY: Social media becomes a diplomatic battleground