Iona Plans To Ride ESB To Recovery

After a major reorganization, Iona Technologies is trying to regain its footing by rolling out a set of products that help IT organizations create an Enterprise Service Bus architecture. ESBs are proving to be vital tools for creating service-oriented architectures. In an interview with CRN Editor in Chief Michael Vizard, Iona CTO Eric Newcomer explains why Iona will soon be a force in enterprise computing again.

CRN: What happened to Iona that caused the shakeup?

Newcomer: I've been here for about five years and when I joined, Iona was really doing pretty well with about 20 [percent] to 30 percent growth, and the big challenge was to find the next product to keep the company going. We made a lot of attempts at it but didn't really find anything. [We] kind of caught with a lot of R&D and marketing/sales expense associated with getting something new off the ground when the industry collapse occurred and revenues kind of dropped on the product side. That pretty much took away the ongoing income that we've had available for investment in new products.

Then the management team was completely changed at that time. The board pretty much switched out the CEO, the COO and a former CFO, who had been doing business development. Our founder, Chris Horn, came back in, who was the original CEO. Kevin Amelia took on the chairman of the board role, and he's a former CFO at Sun [Microsystems], who had started his own company and then decided to take a more active role in Iona. They rebuilt the management team and we had a new COO, new sales VP, new marketing VP and reorganized the company. The first order of business was just to shore [up] the CORBA business. The CORBA product line--that's still our bread and butter. And second order of business was to look around at the various projects that we had going on. We really had a bit of everything going on. We had some B2B work, some EAI work, a Web services toolkit, a mobile middleware product and a project that's become an ESB offering in the last couple of months.

CRN: How are you doing today?

Newcomer: For the last couple of quarters, we've had good results that are stable with a run rate of about $75 million a year and a staff of 350 people. We feel we're in a good position to keep the core business going, keep it profitable and find a little bit of money to invest in some new projects around the extensible ESB. We also have a mobile middleware product for the emerging wireless market. That one's a little farther behind in development than the ESB is.

CRN: For years, Iona has been tightly coupled with CORBA, which is now considered a legacy middleware architecture. Is that market dead?

Newcomer: That's like saying that CICS is not relevant anymore but it's very widely deployed. I wouldn't pretend that CORBA is as big as the CICS market, but there is market out there.

There are a lot of customers that run big parts of the business using CORBA. The telecommunications industry has a tremendous installed base of CORBA. We're seeing some opportunities in the government for command and control around missile control systems, Department of Homeland Security projects and the intelligence community. There are a lot of applications where JMS [Java Messaging Service] is not fast enough. It's not a glamorous market, it's not a growth market, but there's a fit where other technologies like Java just can't cut it for performance or control reasons.

CRN: How do you link Web services to CORBA applications?

Newcomer: We see people looking to Web services to enable their CORBA systems, which is certainly one area of business for us where we can bridge between CORBA and the Web services market in general. Web services are a little bit different than previous technologies because it doesn't really completely replace everything. It's an XML layer that's compatible with almost any kind of software that's out there. There are Web services for CORBA, so there's a little bit less of the rip-out-everything-and-replace-it kind of mentality.

CRN: How does CORBA participate in a larger service-oriented architecture?

Newcomer: Service-oriented architecture is something that has been around for six or more years, and certainly here at Iona we have a number of customers who have been investing in that for a long time and have done service-oriented architecture based on CORBA. But it's never really hit the mainstream until Web services came along. Web services really make it much more affordable and much easier to implement a service-oriented architecture. Now you can think about a service-oriented architecture as something independent of the product that you're using.

CRN: How does an ESB product fit into that model?

Newcomer: ESB is a technology that's kind of grown up and around the service-enablement aspect of Web services.

Fundamentally, the ESB is a transport or the connectivity glue that allows different services to connect to each other and uses the Web service development environment to create those services. For a long time, we were a little bit unsure of categorizing our product as an ESB because all of the ESB vendors tend to have a different definition of an ESB depending on the product that they have. Fundamentally, it's just the connectivity between services that the bus provides. An ESB product typically includes the enablement piece where you can create services, enable them and define them.

CRN: How will Iona differentiate itself in this space?

Newcomer: We call it an extensible ESB, meaning that we provide features beyond what some of the other ESBs on the market provide. Our customers really need to close the gap for mission-critical applications. So we're targeting the enterprise side of ESB, which is where we've been working in our CORBA products for a while in terms of providing high performance, high reliability and high availability. One particular aspect that we feel differentiates us from the competition is that we are transport-neutral.

Some of the other ESB products that are out there depend on a particular transport such as JMS or IBM's MQ Series transport. We don't have such a requirement. We really sit on top of any transport that might already exist in the enterprise. But if a company needs a transport, we can provide them that. We're also more focused on enabling a lot of the legacy environments that companies have that need to work in the modern [service-oriented architecture] environment. Many companies have a lot applications written using a lot of other technologies that need to participate in the new world of Web services and service-oriented architectures.

CRN: What's your take on the process by which Web services standards are evolving?

Newcomer: Unfortunately, we don't really have anyone in the industry in control of the standards and their evolution. I worked for a couple of years on the Web services architecture working group at W3C. I was one of the editors of that spec and, personally, I was very interested in trying to define an architecture for Web services so we'd have a little bit of guidance for the industry about what specification made sense. But that effort failed. Maybe one of the reasons it failed [was] it was a little too soon. I think that maybe the biggest problem is we don't have a single organization really driving the definition and the architecture of Web services. In separate spaces, you have vendors working on specs separately and you don't really have anyone pulling them all together. That's creating some issues. Some of it does stem from vendor politics. What you get are specifications that are technically very similar but backed by different communities because there's still some idea that vendors need to compete over who controls the specifications. What you'd ideally like is the vendor community to view specifications as something neutral and that you would compete on the basis of how you implement the specifications instead of who controls them.