Santa Clara, Calif. -- Perhaps the proper, sensible reaction to realizing the ramifications of what it will take to implement a service-oriented architecture is sheer terror.
And then you do it anyway.
Jeff Davies, director of software architecture and standards at broadband supplier Covad Communications Group Inc., went through pretty much that process himself before putting together his company's SOA. During his presentation at BEAWorld, he made it clear that SOA is not for the timid or faint of heart.
"It's frightening in a lot of ways," he said. "You could keep going down the point-to-point path and telling your business it's really hard to do this SOA stuff and that's the safe way to play it."
Yet when looking at a customer relationship management overhaul back in 2004, Davies decided not to play it safe. Instead he chose to go down what he fully expected to be a long, arduous path.
"You have to make the case to your executive that there's a benefit to doing things the right way, to building an architecture without silos," he said.
SOA did not disappoint him in terms of degree of difficulty. Davies presented his SOA game plan in January 2004 and it took eight months before Covad rolled out its first Web service. Most of Covad's application stack still remains outside the budding SOA.
"It'll probably be the end of 2006 before we get all of the architecture on SOA," Davies said.
He pointed out that a three-year migration is pretty quick, crediting Covad's less-than-hulking size -- 1,100 employees -- and CEO-level backing as critical factors in getting it done in a expedient manner.
"I rolled the execs first and that made all the difference," he said.
Chief among his recommendations for any company seeking to implement SOA is to be prepared for it to cause problems from the outset.
"Everything this touches initially is going to blow out timelines," Davies said.
He also recommended starting small, though he admits Covad jumped into SOA with long-running customer relationship processes. Part of that had to do with the technology Davies had at his fingertips.
He was using BEA's WebLogic Integration software, which he characterized as "optimized for long-running processes." In the coming months he plans to switch over to BEA's new AquaLogic enterprise service bus to create a more nimble messaging infrastructure.
The ESB will also enable him to reduce dependency on a hardware load balancer, which currently has to be rebooted every time one of the servers in the loop needs to be rebooted. Of course, he expected increased latency going into the conversion.
"XML will always be slower than direct EJB [Enterprise JavaBeans] to EJB," he said. "Then again EJB isn't all that fast in the first place. Ultimately, I want the flexibility and I'm willing to pay a certain price for it."
That "speed tradeoff" becomes inevitable when crossing multiple machine boundaries. Davies offered some straightforward advice to those who want to optimize service performance.
"Don't write a chatty interface, cross as few machine boundaries as possible," he said.
Most of all, he cautioned that SOA requires more brainpower than technology. It requires IT shops to adjust their mindset and that can take years. He noted that in particular EJB programmers will find SOA a non-intuitive way of designing applications.
The upside is that adjusting the corporate mindset doesn't require a massive cash outlay for new products. Davies argued that new gear should only be added when a glaring need arises.
"If you approach SOA from a technology point of view, you've captured about one-tenth of it," he said.