<<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 (sic) 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.">>
You can find this at:
http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1321526,00.html?track=NL-110&ad=651138&asrc=EM_NLN_4046358&uid=5532089
Gervas
