Like a number of other major vendors, Oracle is now positioning itself to offer enterprises as much of the infrastructure 'stack' of technology and services as possible.
The coming of Fusion, both as products and architecture, is inevitably set to change the ground on which applications development has stood for many years, as is its part in the move towards delivery Service Oriented Architectures (SOA). But the company is aware it is now stepping out into uncharted ground, where some of its claims are inevitably based on assumption.
For example, one of the factors Oracle sees as an important plus point for SOA is the potential for significant improvements in applications development cycle times. But this process highlights one of those assumptions. As principal product director Kevin Clugage observed, Oracle has already found customers with experience of changing applications requirements, which would have taken the development team several months to complete, that can now be turned round in a week. "That is 60 per cent to 70 per cent faster development," he said, noting the greater productivity and resultant workload that can ensue. "The business is so happy they say: 'if you can do that, then you can do that, that and that as well'."
But faster development cycles can mean hitting the wall of testing new applications for issues such as interoperability, because testing is a process that takes a finite time to do properly. Clugage was confident this was one of the advantages of code re-use inherent in SOA implementations. "Services, once they're deployed, have been tested and are production ready," he said. "So when you build a composite application you are no longer going to be dragged down by bugs in those services because they have been through multiple testing and deployment cycles. They are rock-solid already, so a composite application where 60 percent is based on existing services reduces your testing requirement by 60 percent."
Here, of course, lies something of an assumption, for when services and applications are put together in a composite, even though the individual components have been tested, the potential still exists for operational problems to be created in the interactions between them. Clugage acknowledged the possibility: "I think time will tell whether they correlate directly or if there is some multiplier effect." Time will also tell, presumably, whether enterprises find that a sufficiently comforting advantage of increased developer productivity.
Oracle's SOA Suite is an example of many major vendors' view that they need to offer as much of the overall stack as possible. The elements have been around for some time as individual components. It includes BPEL Process Manager, which has a BPEL engine for orchestration plus the ability to add features such as a rules engine and workflow. The second part is Business Activity Monitoring, and the third a Web Services Manager, which provides the policies and governance components, as well as security. There is also an Enterprise Service Bus, largely constructed from existing technology elements re-packaged to be consumed as a single component.
According to Rick Schultz, vice president of Fusion Middleware at Oracle, there is more to Oracle's offering than just the desire to lock users in. He denied the notion that Oracle has intentions that lean towards the Highlander Principle - 'there can only be one'. The way he described the company's position is that if a customer wanted to migrate from another company's technology to an Oracle product, the company would make it easy for them with migration paths and technologies.
"But if a customer is heavily invested and does not want to move they can run our products on top. There is no forced migration, that is the point," he said. "Sure, if they want to upgrade and they have surrounded their Apps Server with Oracle technologies they are likely to want to look at Oracle Apps servers, but force them? Certainly not."
Force may not be applied, but having everything the user might need is an obvious marketing lever to be pulled as hard as possible. "It does matter a little which stack users choose because, as you go up the stack, if you use a BPM from someone like IBM you don't have the option, despite the standards, to swap out the application server whereas our BPEL process manager can run under other J2EE applications servers. That is why we say that we include standards but go beyond that, because we actually certify support on these other servers and frameworks," he said.
"There are essentially four players here: SAP, Microsoft, IBM and Oracle. IBM is out of the picture if packaged application functionality is required," he added. "If users are looking for a broad stack where applications and technology work with existing systems they need a hot-pluggable heterogeneous capability, so that rules out Microsoft which only runs on one O/S. It also rules out SAP, which only runs on its own applications stack and integration means connecting one SAP application to another R/3 application. We take a very broad heterogeneous view of what the world looks like inside the enterprise IT environment."
Part of the stack and the overall SOA offering is Fusion, about which there has been some confusion. Schultz acknowledges this, for in the important world of branding, using the same word different ways is at least a different approach.
"We use the word Fusion in three ways," he said. "One is as a code name, but it is actually the brand name of the shipping middleware products. We also use the phrase Fusion Architecture to define the architecture we are building applications on, which captures the best elements of SOA and also Grid. The other way we use it is as Project Fusion, the code name for developing the next generation of applications that brings together the functionality of PeopleSoft, Siebel and the rest. We have shifted away from calling it Project Fusion and now call the applications that are coming out of it as Fusion applications. So we have Fusion middleware shipping now, we have Fusion applications forthcoming in a phased approach, and we have Fusion Architecture, which describes to customers how it all fits together and how they can build applications on the Fusion Architecture."®