News

Successful SOA needs lot of small sub-projects

Christina Torode, Senior News Writer

Mike Kavis, former enterprise architect for Catalina Marketing a $US500 million company, says that midmarket companies should apply the same discipline to SOA projects as larger enterprises bring to theirs. One of those disciplines is learning to develop small projects with long-term goals in mind.

"You have to think in small chunks. You have to win over the business side by proving out one project at a time, and you have to realize that the benefits may not be immediate," said Kavis, now an independent consultant , who offers

Requires Free Membership to View

practical guidance for developing SOA projects and is launching a cloud service and consulting firm as CTO of MDot.

Catalina's service-oriented architecture (SOA) project -- to rewrite a 20-year-old business process application that produced targeted marketing in the form of printed store coupons -- hit a few snags. One major one was a lack of buy-in within IT.

"Our developers didn't understand what the SOA project meant for the business and they felt they were going to be replaced by outside consultants," said Kavis, who was the chief SOA project architect at the time.

In addition, at the start, the SOA team headed by Kavis was not working with business units. The group had to step back and rework its approach with a team that combined a research and development center of excellence, the head of business processes, a person from finance, HR and the chief operating officer.

"We were looking at [SOA] from an IT perspective of replacing an old system, and it really was a business project that should be led by the business side and a complete IT organizational change, [which] we didn't communicate the right way," Kavis said.

For those venturing into SOA waters, Kavis recommends not calling it an SOA project or pushing benefits such as reusability. Instead, talk about the project in terms of better customer experience, employee satisfaction and increased revenue.

Kavis' recommendations are seconded by Aleks Buterman, founding partner of IT consulting company SenseAgility LLC.

"Don't believe anyone that says you can buy our SOA product to create a service-oriented architecture," Buterman said. "SOA is an approach, not a product. And if you do buy an SOA platform, remember that you could be locked into that platform and down the road just have a legacy SOA platform."

Buterman has seen SOA projects lose focus and stall because the team in charge is not documenting project stages and what has been achieved. "SOA is not just one project, it is a continuous process and there will be challenges. So when something comes up, be sure you can show what you've been able to achieve," he said.

And don't let the project take on a life of its own. Governance, regardless of the size of your organization, should be in place so that different departments and IT staff members aren't working in silos.

The majority of midmarket companies deciding to begin SOA initiatives are doing so in a down economy in order to come out ahead of the competition when the turnaround hits, Buterman said.

"If you're looking at SOA for costs savings, and whose not focused on cost savings these days, you will face a large barrier to entry," he said. "You have to invest before you reap the benefits."

Costs vary widely. Many large organizations have spent a minimum of $US3 million to $US4 million a year on their SOA initiatives with some spending $US10 to $US15 million over the last five years, estimated Burton Group analyst Anne Thomas Manes.

Midmarket companies will not be undertaking SOA on such a large scale, but they will be competing against technology vendors and enterprises for SOA experts and developers. Then there is the question of resource availability in general. Midmarket companies may not have the resources to dedicate anyone to a SOA initiative.

Figuring out which business processes and underlying data and applications can be turned into services is only one initial step. Those services then need to be kept in check and tracked. Buterman points out that service usage needs to be enforced so that business units and IT don't go off and create their own services only to find out later that they can't integrate with other services. Many CIOs have wished their developers had a more disciplined approach; CIOs going down the SOA path will have to demand that to succeed.