Columns

Paul Butterworth, Forté Software Inc.

Paul Butterworth, vice president of software development and chief system architect at Oakland, Calif.-based Forté Software, has overseen the development of Forté's high-end development toolset, the Forté Application Environment, since co-founding the firm in 1991. Butterworth sat down during the recent Forté user conference in San Francisco to answer questions about the firm's technical strategy and the outlook for the high-end development tool arena with Sandra Taylor, an analyst with SPG Analyst Services, Natick, Mass., and a regular contributor to Application Development Trends.

What was the technical vision of the Forté founders in the early days of the company?

In the early 1990s, people could build relatively lightweight applications using "high level" tools, but they could never build really heavyweight, serious applications. They would try to use the early tools, but always had to drop back to C or some other vanilla programming language.

When we started Forté, our plan was to build a high productivity tool suite that could build applications that people couldn't build before -- really large applications or very reliable applications or applications that required very rapid response times. In order to do these applications, we felt you had to be able to build distributed systems.

The distributed systems model was the only way to get the good scalability and the reliability you needed. We also knew that distributed applications were really hard to build and deploy. So part of that initial picture was to make it as easy to build a distributed application as it had been to build a non-distributed application.

How did the industry "experts" respond to this vision at the time?

The reaction was almost always, 'You know you missed the market. PowerBuilder is already out there. There's no way you're going to be a serious player.' So we kept explaining that we weren't trying to solve the same problems (as PowerBuilder). We were trying to solve these other problems. One of the nice things that's happened over the past six years is that we've actually shown that there is this other market. There are people building bigger, more reliable and more complex apps than those addressed by PowerBuilder or Gupta or by the database tools.

One of the reasons that our vision and the resulting products have been consistent is that I don't think we've truly reached our goal yet. We've made it a lot easier to build distributed apps than it used to be, but we haven't yet made it as simple as building a non-distributed app for a single machine. With each release, we get closer.

Can Forté ever reach that goal?

I think so. A lot of it is experience. We're always learning about what people actually do with the tools, what pieces are easy to use and what pieces are hard to use. As we do that, we incorporate the knowledge back into the product. So each release gets easier to use. You see that in elements like the Express "application wizard" we introduced last year and the Conductor workflow engine we announced this year.

Both of these take particular pieces of a problem and make them very simple. If you're using Express, it's definitely as easy to build a distributed application as it is to build a non-distributed app. You do exactly the same work, and we do all the work under the covers to make it a distributed application.

As the Forté product set evolved, did the development group ever realize that a plan wouldn't work and quickly have to shift gears?

Absolutely. One of the reasons we keep making progress and our architecture is stable is that we're willing to throw something away if it's not right. Our repository technology is a good example. We built the first one and didn't get the performance we wanted. So we threw it away before it ever got out of the lab.

We built the second one and we got the performance we needed, but it doesn't provide the breadth of functionality our users are now demanding. So we're now building another generation of that technology to support those expanding requirements.

We're happy to do that. If you're going to architect a piece of software, you'd better be building something that's going to last for 15 years. A successful product will definitely survive that long. Consequently, when you architect these things, you'd better be willing to throw out the pieces that aren't right or the architecture will collapse within a few years.

Forté has outlined some plans for supporting Java. Can the language be used to build large, distributed applications?

Java is obviously important to a lot of customers. These customers break into a couple of camps. There's one camp saying we want to do Java when Java is ready. This camp has tried it out and found it's still a pretty immature technology. If you use it to build really big applications, you're going to suffer at the moment. But thousands of people are working on this technology and that immaturity issue will ultimately go away.

There's another collection of users who have bought into the Java story, but haven't actually tried it yet. Their picture is that all the technology is here now. Well, I think they're going to be a little bit surprised when they try to do big things.

Java actually works pretty well for doing small jobs, for building reasonable client applications, as long as they don't get too big. But it's just not mature enough to do much more than that. We had one customer who initially tried to do it all in Java. With the difficulties, they eventually built the clients in Java and the services in Forté so they could get the reliability, scalability and the like.

Server-side Java is just a matter of time. As long as all the Java players continue to evolve the technology and continue to work on its maturity, we'll get there. If we didn't believe this, we wouldn't have the architecture we're putting in place. Because it's designed to run both Java clients and Java servers. Actually, it's designed so you can mix and match Java and our 4GL on clients and/or servers.

How does Forté differentiate itself in a crowded field of competitors?

There are always competitors. If you don't have competitors coming at you, you're in the wrong market. If you don't think you have competitors, you have problems you don't even understand. We believe we've successfully fended off the first round of challengers. Now that it's clear this is a pretty big market, a lot of the 'big guys' are starting to eye it and are saying 'hey, we can build these kind of tools.'

Is Microsoft one of those 'big guys'?

Microsoft does a lot of marketing on the enterprise side, but they haven't gotten there yet. They continue to make progress, but they continue to make it slowly. I believe they're just working on so many fronts and trying to do so many things at once. Some of our customers have also commented on Microsoft's business model. That model is really the shrink-wrapped model -- we send you the box and the rest is your problem. Well, you simply cannot build big operational systems without really competent support. What happens if your operational system fails and you're calling an 800 number and no one is answering? Or you go through 14 layers of call handlers before getting someone who's actually read the manual? One of the things that we're really proud of ... and have worked hard at ... is the support issue.

Microsoft is doing better on the technology front and is putting a lot of the low-level pieces in place -- transaction managers, messaging systems, things like that. People say "(Microsoft's) Transaction Server's going to be buried in (Microsoft's) operating systems. How is Forté going to compete with that?" Our answer is "we aren't." We're not in the transaction manager business. Our business is building serious operational systems. If you want to use Microsoft's TP monitor to do that, that's okay with us. But if you'd rather use Encina or one of the others, that's okay with us too. We want to provide an environment where you can use those capabilities without having to do all the extra work those kinds of products typically entail.

What are the biggest challenges today facing companies in this market?

Probably our biggest challenge -- actually the biggest challenge for the whole industry -- is where do we get skilled talent. I couch it in engineering terms, but fundamentally, it's where do you get enough skilled sales people, enough skilled marketing people, enough skilled engineering talent? There are people out there, but there aren't enough qualified people to fill all the industry's open slots. Fortunately, we're a really good company. We have a good product and a good software engineering network. We still have to work really hard to get good people, but we can get them. If you don't have those things going for you, you're going to have problems.

The other challenge is not getting complacent. There is a lot of momentum when you start being successful. The danger is that you start believing your own press.

What keeps successful companies from getting complacent?

It's easy to say you're not going to do it. The hard part is not doing it. We spend a lot of time talking with our customers and finding out what they like, what they don't like, what they're really trying to do. The other thing we try to do is get the engineering team to be more receptive to ideas from the outside, to alternative ways to do things, to customer issues. Engineers are notorious for "knowing how to do it right," or at least thinking they know how to do it right.

From the beginning, we spent a huge amount of time working on our engineering culture. I think our engineers are different because we spend a lot of time trying to make them different and much more responsive to customer needs. If we foul up and start doing what a lot of folks do by saying "we're right and our customers are wrong," that's when you suddenly discover the customers are going somewhere else.

The Forté toolset incorporates about 2.5 million lines of code. That's a huge system to maintain and upgrade. What is the Forté development process and do Forté developers use configuration management systems, testing tools and the like?

Absolutely. You need a lot of tools. One of the big issues we have, of course, is release support for our various platforms. With the IBM announcement, that will be 14. One of the things we do that's different from other companies is that we release our software simultaneously on all platforms. And we do that mainly for customer reasons.

Since most of our customers run heterogeneous environments, it would be difficult for them if we delivered one platform today and another platform next month. They would scratch their heads and say, 'well, what do I do with this piece? When do I install?' So when we deliver, the CDs have all the software for all their platforms.

In order to do that, we have a development process, and the process is repeatable and well organized and everybody on the development team knows what it is. As we make changes to the product, we integrate those changes every day. We build on all our platforms and we regression test on all our platforms -- every day. Then our development team uses the new build. If something is wrong, we can not ignore it. It gets fixed.

To make all this happen in an automated fashion, we have an incredibly complex environment. There's close to 200 machines, plus configuration management tools, testing tools, and all the pieces you need to make it work in a reasonably efficient fashion. The process and the tools have served us really well. And it ultimately means that customers get a good solid product.

Most   Popular