Is it enough to be a Lotus Domino developer? That kind of question haunts developers of all types -- Java, Visual Basic, C++ -- but it seems to hit Domino developers the hardest. It takes on additional poignancy in an economy in which businesses are more conscious of expenses.

Being a Domino developer is unlike developing in any other language. I cut my teeth on dBASE III 1.0 (remember Ashton-Tate?) in the early days of PCs. Back then, if you knew dBASE III and Lotus 1-2-3, you were in rare company. Add a word processor program such as DisplayWrite III or WordPerfect, and you could work in just about any Help desk.

Today, I can't imagine taking a resume seriously if it lists only three applications and an OS or two.

So, is it enough to list just Domino development on your application? What does it mean to be a Domino developer, anyway?

First, you need to have what any good developer has: the ability to help people articulate requirements they didn't even know they had. You have to turn those requirements into a database design, the equivalent of an RDBMS's database schema. For most traditional Notes applications, the next step is to design the forms. That can be complicated. If the form has to acquire data from Oracle, you might get away with a simple @DbLookup. You might have to write a complex SELECT statement and use the @DbCommand. Certainly, there are Domino applications that have no such requirements, but almost every Domino application I deploy now has moderate-to-complex data integration.

The Domino developer must understand the impact the application will have on the server infrastructure. That translates into performance and capacity management skills. A couple of years ago, you might have been able to put an application onto a server and watch what happened. CIOs frown on that practice now. And you don't want to know what happens to your career if your Domino application issues a SELECT statement that buries your SQL Server.

So far, I've discussed the skills necessary for a typical client-server application. That's a good foundation, and I remember those days fondly. Now, it's all about high-availability, scalable, high-function Web applications. It isn't nearly enough to have a Web site. In many cases, the Web site is the business. That means, at a minimum, you have to know HTML. Domino Designer works, but it isn't flexible enough to be the only tool you use to create a Web application. That means using passthru HTML, cascading style sheets, frames -- the works.

HTML is only the start. Validation formulas aren't enough; you have to plan for high capacity, and one way to do that is make the browser do as much of the work as possible. The Domino developer has to understand JavaScript and its implications to different browser vendors and versions.

At this point, you can make pretty forms that scale well on the Web. Of course, that isn't enough, either. Now you have to share data, and that means knowing XML. If you use XML, you need good negotiating skills, because you're likely to be working with people outside your company. How do you set up the security for the data exchange? How do you satisfy your partner's data needs without compromising your competitive advantage? Unless you're in a large company that can afford to hire a lot of people, you'll have to deal with those issues.

In all likelihood, you'll encapsulate your business logic in some object layer. That usually means Microsoft COM or some form of Java. That's a whole world of development knowledge, but it's just another day of developing my Domino Web site.

Being a Domino developer can mean you also handle generic database design, SQL, capacity management, HTML, JavaScript, XML, business negotiation, and Microsoft COM and/or Java. You might also be an expert in JSPs, WebSphere, or any number of cutting-edge technologies. You might even be an expert in multiple operating systems.

It just might be enough to be a Domino developer after all!