In-Depth

Q & A:

• By Jack Vaughan
• May 29, 2001

You're coming out of a user conference. What have your users been doing that surprised you?

We found a lot of customers who were looking at much more expansive use of the Web across their organizations. A lot of customers have been building 'one-off' projects, maybe part of a Web group or part of an IT organization, but it seems like there's a huge up-tick in the number who are looking at making their Web software infrastructure much more broad and expansive in terms of the applications that they're going to build and in the systems that they're going to buy and implement across their organization. Certainly, we see a lot more interest in business-to-business commerce using XML and HTTP to integrate systems across the 'Net. Those are some of the things that I picked up on.

What do you see going on with the Open Source Movement? Is it a threat to the application server eventually?

We've spent a lot of time looking at the impact of open source on our marketplace, on the Internet as a whole, and very clearly it's having a significant impact. I think, over time, the closer your technology is to being a commodity, the more appropriate it is to be something that's open source. The more strategic the technology, or the more value-add in the technology, the less likely it is to be under a pure open source model.

Corporations' desire to have commercial software and to have a vendor relationship around that commercial software hasn't changed at all. What we are seeing change is customer expectations about their ability to impact the evolution of the software - their ability to have visibility into the technology in a way that, historically, vendors were unwilling to do.

When we've thought about this, we've thought about how we take advantage of our customer base - hundreds of thousands of developers who've got great skills in working with our platform. How do we take advantage of those skills to drive our technology forward? With the Internet and the ability to have instant communication, it actually becomes very easy to do.

Are people these days developing on Windows and deploying on Linux?

Currently, visual tools that people use are predominantly on Windows, and I think that will continue to be the case. I don't think it's necessarily that they're going to be thinking about it as deploying Linux applications, because no one is deploying Linux applications.

In some ways, the appeal of Linux is not that it's an app platform like Windows NT systems services provide an app platform. It's just commodity plumbing for what you need to host your Web systems. It's low cost, you can scale it in clusters like a commodity, there are a lot of people who know how to work with it and administer it, and it's reliable and robust.

People aren't thinking about how to add value to Linux, by, for example, adding a new widget to make the Linux desktop better. They're just saying this is a great, reliable server platform for Web systems. The products that they're interested in on that platform are the popular commercial application server products and database products. I think they'll do well there.

Is this at the expense more of Windows NT than, say, Solaris?

Yes, I think it is. The appeal of NT is it's a commodity-priced product, roughly speaking. You're not talking about hundreds of thousands or tens of thousands of dollars - you're talking about thousands of dollars. It runs on commodity hardware and a mix of different types of hardware. It's got a lot of the features that are needed for the Internet built in. For Linux as well, that certainly is the appeal. The only things that need to change to make that overlap more direct is making sure that the user interface and manageability of the systems are on par with what people get from NT.

The next version of NT [Windows 2000] will eventually have a lot of middleware and pseudo-application server capabilities inside it. How do you see that playing out?

You're referring to COM+ and the message queuing and transaction server, that kind of stuff? The interesting thing about that is that it's been in NT for a couple of years. It's been in NT through service packs, but also in the commercial versions now, and the core pieces - at least MTS and MSMQ - have a basic COM infrastructure. Microsoft has been successful in getting the top tier of its customer base to start working with and building to that. I think, though, that there are a couple of things to note. One is that the vast majority of apps built for the Internet - built on Web application servers, deployed on browsers and so on - don't take advantage of that level of infrastructure. They simply don't need to. It's sort of like the 80-20 rule. In the prior computing eras, 80% of the software was built with desktop tools like Visual Basic or Pascal, and then there was a smaller percentage that were implemented in things like C++.

We've talked for a long time about systems like CORBA, DCOM, message queue systems, etc. and they haven't got mass appeal. You can't go to a developers' conference and find gobs of people implementing on top of them. It's on people's radar, but there's just not enormous traction there.

In the Internet space, once you start getting into Internet applications, you're dealing with software that's deployed outside your corporation - in fact, it's deployed with the entire purpose of integrating with your business partners, customers and other things. In that situation, all of those standards and all of these architectures that have emerged collapse on themselves because they're built on binary protocols and on high-latency networks where you can rely on controlling the platform that you're using to integrate your software.

On the Internet you have low-latency networks, you have no control over the platforms that your customers and suppliers use, and you have this flat protocol, HTTP, which is what's used to enable the Web. In that new universe, in some ways, we're going to have to build what I call XML Internet middleware from scratch.

There's a new set of requirements. Just as Windows 2000 is hitting the market with a heavy infrastructure that is geared toward inside a corporation and, likewise, with things like J2EE hitting the market this year with an inside-the-corporation focus, the most sophisticated customers want to go beyond that and integrate apps and build distributed apps across the Internet. That presents a different set of challenges.

Microsoft Active Server Pages (ASP) at one time seemed like the most logical competitor to ColdFusion, and you seem to have successfully repelled that onslaught. What are the advantages vs. the ASP solution that you offer?

You have to step back. At one level, the CFML language and programming model, which is a feature of our application server, competes with the Active Server Pages model. And I think that what has allowed us to be successful is that our basic model for programming the Web and for rapidly designing and building Web systems is much better designed explicitly for Internet systems, whereas the Microsoft model is an evolutionary model from their existing programming language, tools and infrastructure set. I think that's continued to make Allaire's platform very compelling for companies and individuals who are focused on the Web.

I think more importantly, though, that what has continued to make our platform very, very successful is that we've continued to add a lot of services and value on top of that core approach. So when you look at, say, ColdFusion 4.0 or 4.5, there's a lot of technology that the customer is interested in that has nothing to do with the language and the programming model. For instance, clustering and failover services are just part of the [ColdFusion] app server. ASP does not put that in. You don't have a really robust form of clustering and failover services as just part of the ASP environment. That's one example.

Another example would be advanced security APIs that make it easy to do registration systems, membership databases, and user login and access control. A lot of things that people tend to build over and over in the Web space, we build that stuff into our app server. We also take a lot of the primary problems that people have like integrating Internet protocols, FTP E-mail and other protocols they're going to use on the back end of their application, and build higher level components that are much easier to use than having to go down and build your own custom objects and script those. We've just continued to pack a lot of productivity punch into the environment for users.

Along those lines, I think ASP was supposed to kill you, Java was supposed to kill you and JavaScript was supposed to kill you, yet you've thrived in the face of that. What's the secret?

What we're finding is that in companies there's a pyramid of project types and developer skill sets. The pyramid has a large percentage of people who are in that Web development category who are responsible for rapid development and deployment of Web systems. It's a huge percentage of what people have to do. When we look at the pyramid, we see that in some ways you have a hierarchy where you have your lowest level infrastructure, your transaction infrastructure, and it very much should be implemented in Java, and we're seeing traction for that. We're embracing that and building that into our platform so that we can be very attractive to that developer and skill set. And then there's this huge percentage of people who are assembling and building applications, integrating those with dynamic content, HTML and XML, and there something like ColdFusion's markup language becomes extremely compelling.

What has allowed us to survive in some sense, and our secret, if you will, is understanding the relationship between all these different constituencies and designing the appropriate technology for them.

It took everyone except Microsoft and Allaire three years to figure out that you needed a page-based script, plus HTML, plus objects on a server model for building Web applications. JSP only [recently] became a reference spec. The rest of the industry has finally kind of figured that out.

What advances are you seeing in Internet components?

Internet components will eventually look more like traditional components with objects and things like that. You will have XML components and those will oftentimes encapsulate things like Java underneath.

Say I am a Web site, and I have a relationship with another Web site that has an online catalog. Let's say I'm a vertical portal, an Italian food-lovers' Web site, and I want to be able to resell cookbooks from Amazon.com. How does Amazon.com expose to me, the other Web site owner, a component that I can use that provides the Amazon catalog and order processing engine? How do I do that? You do that with XML and HTTP. So I have my Web site, and when a user wants to get a list of books, I want to make a remote call, similar to how RPC mechanisms work, to the Amazon.com Internet site, and query the catalog and then get the contents back and render them for my customer.

I would call these XML Internet components. This is the cutting edge, I think, of distributed software in the Internet arena. And we're putting a huge investment into this for the next year. XML Internet components will be a significant event.

Your name and your brother's name is on the door - that's unique these days.

One nice thing about the name of the company is that to people the word "Allaire" doesn't have a lot of meaning. It's not like "super-net-pro" or some silly name. That's worked out for us.

I think, ultimately, that we believe that our vision and what we're trying to get done is very important. If people want to associate that with our products and company, I think that's fine. A lot of companies have their IPO and people leave; that's clearly not what we're up to. In fact, if you look at the history of the company, and you look at how we've grown, we've been methodical, pragmatic and we haven't over-invested. We haven't tried to be a thousand people overnight, and we haven't tried to overachieve when it wasn't feasible or possible. We've just consistently plugged away at our vision, and delivered products and value to customers.