|
|
| Home - CEO Spotlight - Jan 05 Issue |
CEO Spotlight: Chris Horn, IONA Technologies |
By Angel Mehta, Managing Director, Sterling-Hoffman Executive Search
Angel Mehta: How did you come to found IONA; what is the history / background?
Chris Horn: The company was formed in February 1991 as a “spin-out” company from Trinity College Dublin in Ireland. During the 1980s the Department of Computer Science at Trinity collaborated with a number of major European OEM and software houses, with partial funding from the European Union’s ESPRIT program, on pragmatic distributed systems research. Our practical experience of building middleware during that time laid the foundations for IONA. In addition, the Object Management Group was formed in 1989, and we quickly realized that much of our prior 8-year experience of distributed systems, and object technology, could be applicable in that new forum. Sean Baker, Annrai O’Toole and I co-founded IONA, with myself as the CEO and Chairman.
Angel Mehta: How has the integration / middleware market evolved since the mid-nineties when it built up steam?
Chris Horn: It is kind of ironic…In the early ‘90s when we founded IONA, there had already been a number of proprietary middleware products from e.g. IBM (and MQSeries); AT&T (Tuxedo); and Digital (MessageQ). The OMG CORBA initiative in 1990 was the second attempt to define a standard middleware environment for the industry; the first of course being the earlier OSF DCE. Over a decade later, we still don’t really yet have a common agreed standard middleware environment for the industry – if anything, particularly from the practitioners’ perspectives, it’s even worse. We still have most of the technologies from the early ‘90s (although Dec MessageQ and OSF DCE have both largely disappeared) but now we have J2EE (including JMS and related technologies): Web services (a range of complementary or alternative or competing standards, depending with whom you engage); yet further proprietary products such as the TIBCO bus; and still a feeling amongst a fair number of respected experts in the industry that perhaps the current standards initiatives are over-engineered and we need a return to cleaner, elegant and more dynamic designs.
It reminds me of the early days of the railroad industry, when there were so many different gauges. Now perhaps the middleware industry is moving towards a “common gauge” – Web services, and there even so remain respected doubters – but there are at least two remaining major challenges. We perhaps have agreed on a gauge, but we also need to agree on the design of the couplings between wagons – we’ve perhaps fixed the lower level middleware protocol issues, but there are still battles over the higher-level standards. Secondly, once you lay down a railroad, and start running your trains over it, you need to have a very very good business case indeed as to why on earth in the near term you would want to rip out that railroad and lay down a new one just because there’s a shiny new standard gauge.
Angel Mehta: What have been some of the key challenges for IONA as a result of the market changes in integration over the last 4 years?
Chris Horn: Like everyone, the key challenge for IONA after the bubble burst has been sheer survival. The market conditions have been torrid since early 2001, although there is now some optimism that a more considered market might be emerging. Our challenge has been to focus on what we are good at – enterprise systems integration – and to reduce our involvement in peripheral business activities.
Angel Mehta: How has IONA adjusted its strategy to cope with those challenges? How does IONA today differentiate itself from webMethods, TIBCO, or the other major Integration Software players?
Chris Horn: Like the rest of the middleware industry, we are investing considerably in Web services. However, we recognize that enterprise customers have already invested considerable sums in middleware over the last decade – be it from us or from the other players – and they need very good business reasons indeed to adopt Web services now – particularly if doing so involves replacement of existing deployed infrastructure. I suspect that one or two of the other vendors in the industry are just beginning to wake up to this cold reality.
Our view – and what our customers, new prospects and industry analysts tell us – is that the enterprise sector requires middleware with multiple-protocol, multiple-middleware capabilities: an extensible enterprise service bus. Perhaps the middleware industry in general still has much to learn from the Internet: the scaling of the Internet; how thirty years ago there were a bunch of deployed proprietary (SNA, DECnet..) and standards-based (X.25..) network protocols, and how a federated inter-net needed to be built to solve the issue; how the Internet then unlocked so much potential, including the development of the World Wide Web; and how extensibility is so important, and why XML is so much better than HTML.
Given these lessons, why is middleware frequently limited in scale? Why isn’t middleware more extensible? Why can’t customers leverage their “sub-nets” of middleware in which they have already invested considerably?
|
|
|
