Tools for building composite applications with the service-oriented architecture (SOA) approach are a sticking point with Mark Taber, the new CEO of Active Endpoints, Inc., the ActiveBPEL vendor.
Available SOA tools, while comprehensive, are more than the average coder can quickly learn to use, he argues, saying, "As a result projects get stuck." Having been an executive working with enterprise architects on SOA at DataPower and then at IBM after it was acquired, he isn't faulting vendors with comprehensive tools for SOA orchestration, but he says a new approach is needed to get SOA development unstuck.
Basing his argument for a different approach to SOA tooling on experience working with enterprise architects during the past five years, he said the irony is that the basic infrastructure for SOA is in place at many companies, but it is being under-utilized.
"I worked closely with enterprise architects just getting the infrastructure in place," he said.
But the current situation is a little like having a Ferrari, but not knowing how to drive.
"Most companies now at this point have the infrastructure and they have Web services," Taber said. "But almost without exception the infrastructure is just sitting there and SOA adoption has been pretty small. Lines of business project teams aren't using that infrastructure. That's what I mean when I say things have gotten stuck."
The fundamental problem as he views it is that the current vendor tools are comprehensive and useful for the enterprise architect and a few SOA-savvy programmers working in a center of excellence. But the coders on line-of-business project teams don't know how to use the tools and, under deadline pressures to build applications, don't have time to learn to use them, he said.
"The tools that the vendors are bringing are pretty hard to use," Taber said. "They have pretty steep learning curves associated with them. So we're expecting your VB 6 developer to understand a very complex area and we're expecting them to devote the next 90 days to learn some pretty sophisticated tool to get it done. They just don't have the time."
Taber said he has watched several of the popular solutions to this problem come to grief. Building a center of excellence sounds good, but he said he has witnessed two problems with it. First, there are not enough developers in the center of excellence to handle the demand for SOA development within a large organization, and so a backlog of projects grows. Also in some corporate cultures, the center of excellence programmers are viewed with suspicion by line-of-business IT people who don't want coders from headquarters coming in and taking over their project.
The result in Taber's experience is that projects are done the old fashioned way without making use of existing Web services and with limited or no code reuse.
He does not advocate reorganizing IT departments to solve the problem, but he argues that simpler tools would help line of business developers adopt the SOA approach.
"I think the BPM vendors and the system vendors all have pretty good technology and it's extremely comprehensive, but it's not usable yet for that project team, the line of business guy, the VB developer," he said. "So there's a huge impedance mismatch out there between real life, what people have to do to get their jobs done and the technologies that are available."
Taber said he came to Active Endpoints because he believes tools relying on the Business Process Engineering Language (BPEL) standard as well as the emerging BPEL4People specification will make composite application development interoperate in heterogeneous corporate environments, but he wants to make the tools easier for line of business coders to work with, even if it means the initial applications are not 100 percent pure SOA.
"Maybe it will be more basic solutions with 80 percent of the functionality and 20 percent of the complexity," he said.
But in commonality with the advocates of guerilla SOA, he said it is better to have limited projects making use of an organization's existing Web services infrastructure, than to discourage line-of-business coders from making any use of it at all.
It would be better than the current situation, where Taber said, "There's not a lot of service orchestration going on."