Oracle and SAP AG's distinctly different approaches to service-oriented architecture (SOA) encapsulate a major...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
problem faced by IT organizations the world over: whether to go with a packaged application provider or a middleware provider to meet their SOA requirements.
Cambridge, Mass.-based Forrester Research Inc. interviewed 53 early adopters of the SOA approach and in a new report concluded that most are proceeding with caution, concentrating their initial efforts mainly on internal systems. But perhaps more telling is the fact that most of the interviewees still aren't sure whether to standardize on an applications platform provider, like SAP or Microsoft, or a middleware provider like Oracle or IBM.
Experts point out that Oracle is focusing its SOA efforts on building an open infrastructure with its Java-based Fusion middleware offering. Alternately, SAP, with its NetWeaver application platform, is focusing its ongoing SOA initiative on making it easier for customers to deploy and customize various SAP packaged applications.
"SAP's primary goal is to make sure that their applications are supported and their partners are supported," said Forrester analyst R. "Ray" Wang. "Oracle's framework is definitely a lot more open in the sense that the standards adoption is much more open, but the applications being built on top of the middleware have yet to be proven."
Wang added that for folks mulling SOA, it may not necessarily be a question of deciding which vendor's approach is best, but rather a question of determining how many SOA ecosystems they can support. For example, he said, large companies with many suppliers and partners may have to support two or three SOA ecosystems over the long term.
Looking ahead, Wang said he expects the major vendors in the space to work toward somewhat greater levels of interoperability. Oracle is already working closely with IBM and Microsoft with SAP, he said.
"The [vendor] that can deliver on all four platforms is going to win," Wang said.
Web services and the road less traveled
Companies starting down a path toward SOA should expect the entire project to take at least 15 years to complete, but those same firms can begin realizing the benefits of SOA within the first six months, says Anne Thomas Manes, a vice president and research director with Midvale, Utah-based Burton Group.
"People who think that SOA is a six-month project are disillusioned because they're getting nowhere," Manes said. "You can start to see benefits from SOA within six months, but really what you're doing during that time is integration using Web services technology. That's not the same thing as SOA."
SOA, Manes explained, is about identifying replication, eliminating duplicate implementations of functionality and ultimately removing application silos so that all systems share what they need to share at the core level.
"If you go through your systems and identify all of the duplicated functionality and replace that with services, you no longer ever have to do integration," Manes said. "Integration is about bridging those silos. SOA is all about breaking them down."
But not all SOA initiatives begin with integration through Web services, according to Steve Garone, a research partner with Ideas International in Rye Brook, N.Y. Garone said companies can get to SOA without using the specific technologies and standards associated with Web services -- though it's not a very popular approach.
"The [SOA] concept doesn't specify specific protocols or standards or anything else," Garone said. "Most people begin with the Web services standards [they're] familiar with, so it's a logical next step to take the services that you build and have them operate within the context of an SOA."
The first thing to do before beginning any SOA project is to make sure that everyone at the company, particularly upper management and IT, is on the same page about the project's requirements, Garone explained.
The analyst said that both IT and the business side should be clear on the firm's entire application portfolio and infrastructure profiles so that they can decide together exactly how far they want to proliferate SOA throughout the organization. He added that the task of auditing those systems alone can take a very long time.
"It's a very good idea to have somebody from within the IT department who has credibility with upper management champion SOA throughout the organization," Garone said.
When firms begin implementing SOA or doing integration via Web services, analysts agree that it's also important to start small.
"By small, I mean something that is easily definable within the organization," Garone said. "Starting small and starting on something that you can quickly and thoroughly understand and define is a prerequisite for being successful with an SOA project."
Forrester's Wang agreed, adding that companies should start with projects that are "easier to get into SOA."
"A lot of people are doing self-service on the employee self-service side, or partner/customer self-service enablement," Wang said. "Those are things that are pretty tangible."
Picking the right vendors
Whether a firm is considering Oracle, SAP, IBM, Microsoft or all of the above for its SOA needs, the first thing it should do is get the candidates to prove their worth in very specific ways, experts say.
This process goes beyond a simple examination of the SOA-related products and services these vendors provide. Rather, the vendor needs to be able to demonstrate that it can support the firm's entire environment as it moves forward to SOA, Garone said.
"You need to make sure that you work with vendors who can cover all of the major elements technologically that sit within your IT infrastructure, including software and hardware," he advised.
Achieving SOA can be a very difficult and lengthy process, but one that's well worth it, Garone added.
"If properly implemented the benefits of SOA far outweigh the costs in most cases," he said.
Dig Deeper on Microservices and DevOps