Service-oriented architecture (SOA) can be used to integrate different systems and produce "a single version of the truth," but aligning the people processes can be as complex or even more complex than resolving the technical issues.
Getting all the people to agree on business processes was a time-consuming task in developing an SOA project linking project management and accounting applications at Babcock Power Sales Inc., explained Scott Duckworth, who was in charge of IT management for the project.
He offers insights into the people process alignment issues for SOA projects based on experience creating an SOA-based system for the Danvers, Mass.-based engineering, manufacturing, construction company serving the energy and waste management industries.
Making sure every department was working with the same metrics for tracking time and money spent on projects was the goal of the SOA implementation that deployed an enterprise project management integration appliance from SOALogix Inc. While the appliance handled the software integration relatively quickly, people process alignment took time. Getting the previous manual processes for project management converted into SOA-based automated business process required resolving issues between departments, some of which ultimately had to be decided by top management.
Executive buy-in for the SOA project was one of the key advantages Duckworth had in working through these issues, he recalled.
"I had top management buy-in," he said, "which is critical to getting a project like this to work and be successful. You need senior management buy-in right from the start, and you need them there every now and then making the decisions when you come to an impasse where you've got three or four groups arguing about how this is going to go."
Sarbox and SOA
Top management had a vested interest in the SOA implementation because accurate accounting of project management costs is critical in the post-Sarbanes-Oxley business world that requires detailed reporting and holds executives legally accountable, he explained.
"Sarbanes-Oxley made poor project management a crime," Duckworth said. "Now, we're responsible if we don't manage projects to budgets and schedules."
What Babcock Power needed was a uniform way of making calculations, so that all those involved in a construction project were working with the same numbers.
"Essentially for this to work corporate wide," Duckworth said, "there needs to be one way to get a single version of the truth. We have to decide which way is the best way for everybody to follow."
This is important because in discussing project status a situation can get confused if everyone has as different idea of where a project stands.
Duckworth offers a hypothetical example of the problem: "I have a five-year project. I'm two years into the project and I'm 50 percent spent. Am I a half -year ahead of schedule because I'm half way finished? Or am I way behind schedule because that half spent only represents a quarter of what I'm going to need to spend?"
In a Sarbox world, this sort of confusion is no longer acceptable, which is why Babcock Power management saw the SOA implementation as critical to their business.
Mapping business processes
Problems with the implementation had more to do with defining terms so that every department was talking about the same items when they appeared on project management schedules and reports, Duckworth explained. The goal is to have a "single view of the truth" that everyone agrees on so there is no confusion when project management status reports are given to the management and excutive levels.
From the technology side, the linking of project management and accounting systems was relatively straightforward, the IT manager said.
"This is very much doable no matter what the systems are," Duckworth said of the application integration side of the project. "It's all about engineering your architecture and processes, then following through on it."
Resolving the people process issues, however, was time consuming, he recalled.
"The development was not speedy and the reason it was not speedy was there has to be a tremendous amount of discovery to make sure that you get everything in line," Duckworth said. "We had to modify some in-house processes."
Modifying in-house processes required going back to an old fashioned white board and diagramming how pieces of paper moved through departments in the manual process. Duckworth describes standing at the white board and asking departmental users: "How does this paper get from here to here to here?"
Finding a single version of the truth in these departmental processes also required defining terms and determining one standard way to calculate how time and money are being spent on projects.
"You find out they are using different definitions or, worse yet, calculations for scheduled performance index (SPI) or cost performance index (CPI)," Duckworth said.
Canonical data models
At times the only way to get one standard way of defining a term was for management to join the meeting and take the lead in deciding the issue, he said.
"During the discovery, there were a lot of sacred cows that came to the front and had to be slaughtered," he said.
Having top management buy-in for the SOA project made it possible to get departmental cooperation in working through issues and resolving them so that everyone agreed on one set of definitions for calculating performance and cost, Duckworth said.
With all the terms defined and the initial applications up and running, the IT people can now take advantage of SOA agility when business processes inevitably change.
"The beauty of SOA is there's this level of abstration that SOA provides that allows us to actually change our process and just go in and make a few tweaks to the SOA code or the appliance and have it work.
Duckworth sees SOA as ideally suited for a business climate where the only constant is change.
"That why you're going to see SOA really take off in the next few years," he said. "It's because at a canonical level it's one more level of abstraction away from what actually goes on, so you're able to make changes within the structure and the system, and then just go up and make one change at the SOA level and it will accommodate all those lower level changes."