A Guide to Achieving Success with Service-Oriented Architecture

The Army Human Resources Command had a problem: It was trying to keep track of current HR information for service members deployed worldwide in real time using data that was anything but.

The command, which handles payroll, personnel and other human resources services for the Army, historically has operated with stovepipe applications and records stowed in disparate databases. Before, programmers spent up to two years building complex, point-to-point interfaces to connect applications so they could share data. In many cases, data sharing was done through daily, weekly or monthly batch processing. That meant the applications often used or analyzed out-of-date information, which sometimes caused confusion or resulted in reporting errors.

In the Middle

To solve the issue, the HR Command has been implementing a service-oriented architecture (SOA), taking advantage of middleware and standard protocols such as eXtensible Markup Language to integrate applications and data. SOA lets the Army’s components share information in real time, regardless of the type of database the information resides in or whether the host uses Microsoft Windows, IBM AIX or some other mainframe operating system.

“Applications may speak in different languages and databases use different protocols, but your message broker changes the data on the fly and sends and receives information in the desired format that the applications want,” says Alfred Allen Jr., project development and technical manager for the Army contractor team from Science Applications International Corp. working on the HR Command’s SOA program.

Here are four pointers to keep similar projects on track:

No. 1: Start small to prove proof of concept and build momentum.

At the heart of the Army system is an Enterprise Service Bus. The ESB acts like a traffic cop, managing the flow of communications and allows database information, such as personnel records, to be easily reused by different applications. The result is faster software development, improved business processes and a more cost-effective and efficient IT system, says project manager Stephen Balazs Jr., PMP, who works for Army contractor Science Applications International Corp.

The HR Command pursued a pilot project using five scenarios that showed applications sending and receiving data through the ESB, says retired Lt. Col. Kevin Woods, an Army reservist called to duty to oversee the ESB project for the command. The pilot showed that the technology worked, and through word of mouth, got other people in different parts of the organization to want to pursue SOA for their applications, he says.

In the beginning, Woods says, a big part of his job was marketing and getting people to buy into the project. “You have to do internal marketing and give the proper spin to the project,” he says. “It’s like priming the pump. You run up against agencies who don’t want to put up money for the project, but if you can show a SOA implementation is having success, then they will come to the table and say, ‘Let’s make this happen.’ ”

No. 2: Negotiate funding.

A SOA project touches upon many applications across multiple business units, so the project cannot be paid for through a single source of funding, says Woods, who recently demobilized from reserve duty.

For example, a SOA implementation may connect applications between a business management agency within the Army, such as finance, and a warfighting agency, such as a corps or theater unit. If both groups benefit from the SOA implementation, then they will need to share the costs, he says.

“You have to have flexibility on funding. You will need multiple sources of funding,” says Woods.

No. 3: Show neutrality in office politics.

When working with many organizations within an agency or department to tie systems together, a big fear among users is that they must give up ownership of their applications or data to the IT staff because SOA creates a middleware layer between the applications, Allen says. Be upfront and tell the program organizations that the IT shop has no interest in owning any part of their applications or data, he advises.

“We had to let people know that we weren’t going to be one of the owners,” says Allen. “We were just going to connect them and transmit from one side to the other without us owning either end.”

To keep everyone abreast of the effort, develop a governance process that maps the project in detail and documents how the technology should work, he says.

No. 4: Find knowledgeable help.

The current crop of integration software has been around for more than a decade, and vendors continually refine it. This is mature and proven technology, says Woods. The critical factor is making sure an agency has the right internal or external help to integrate systems.

If the IT team needs help from consultants or contractors, check out the skill sets of would-be contractors thoroughly, Woods says. “If you have consultants who say, ‘I don’t know if I can make this work,’ then change consultants because good consultants can make SOA work,” he says. “They can tie everything together regardless of the SOA technologies that are used.”

The Big Link

The HR Command considers its SOA effort as dovetailing with a broader Defense Department initiative to build an integrated military HR records system: the Defense Integrated Military Human Resources System (DIMHRS). In the past, each military service branch used its own HR and pay systems, which sometimes resulted in inaccurate records of service, such as promotions and transfers, and incorrect pay and benefits. DOD aims to reduce errors by integrating the separate personnel and pay records into DIMHRS.

Not every application used by the Army HR Command is part of the DIMHRS project, but if it turns out an application needs to be connected to the DOD-wide system, the command can do so through the ESB, Allen says.

The command has more than 1,000 business processes and so far has used the ESB to connect 50 apps. Using the bus, building the interfaces takes about 90 days, where previously it took two years, Balazs says.

“Applications used to only talk to each other through complex interfaces that were costly to build, and we’re doing away with that,” Balazs says. “So if anyone gets wounded in Iraq, the data is available on the Enterprise Service Bus to other casualty systems.”