My dad is a DBA. However, he doesn't design large databases, he doesn't write extremely elaborate multiselect SQLs (I don't think he's ever read a Joe Celko book), and he certainly doesn't care about the latest, greatest news in the world of technology. He's been at the same place for about 15 years , is respected by his co-workers, and makes sure that the rest of his organization gets the information necessary to get their jobs done.

I have another friend who is a programmer. She works with Visual Studio, cranks out form-based apps that attach to data, and basically helps build client/server apps for her organization. The apps she builds are used by lots of people in her organization, thereby she provides value and remains employed.

Neither one of them really cares about the latest battles over Web services standards, about the Microsoft versus Linux/open source wars, about the JCP process, or desktop Linux. They represent a large percentage of the people you meet in typical IT organizations; they make up the teams that develop applications that you use in your organizations. I call them "business developers."

The other primary group in IT development organizations is the "technology elites." These are the architects and senior developers who know how to use UML correctly, who know the latest Java standards, and who can write complex server code with ease. Tools used by this group need to include analysis/design tools, strict standards compliance, automation/generation of redundant things, and most of all - the ability to circumvent the tool and get straight to the code without interference.

Typically this group of technology elites might represent 10% of an IT development organization. They tend to be the ones who make decisions on which tools and technologies to use and drive the technical direction of the company. The fact that you're reading this magazine means there's a high probability that you're a technology elite.

Business developers can create GUIs, write HTML and JavaScript, build workflows, execute services, make maintenance changes, etc. Given a decent set of specs, some existing services to call, and a productive GUI that abstracts the low level, this group can produce lots of applications and contribute huge value to the IT organization. They build the day-in and day-out applications that your employees, customers, and partners run. These developers don't really care if what they build follows the latest industry standards, uses entity beans, or uses the hottest new products, it's their tool and its productivity that is important to them. They just want to get applications out the door; as long as some of the basics are covered, like running on top of a J2EE or servlet engine, they are happy.

The problem is that creating productivity out of a set of industry standards is complicated. Real productivity and automation of development tasks requires an advanced (aka proprietary) framework and an intuitive GUI. Every vendor that has a solution in the Java J2EZ space (Making J2EE easier= J2EZ) has a proprietary solution they're selling. I'm not characterizing this as a bad thing, just a necessary thing and something you need to realize when you go for productivity.

BEA and IBM have made strides in productivity but their solutions only work on their application servers and platforms, and they still miss the mark for the vast majority of business developers. While they do support standards, they fall short of the J2EE promise of platform independence. Smaller vendors build systems that will work on all the major Java platforms. Borland and Compuware (and IBM Rational) have great tools that target all the platforms, but they're geared toward technology elites and model-driven development. M7 and Exadel have built excellent environments for automating Struts/JSP application development, but there are questions on how usable they are for the business developer. Then you have vendors, such as ClearNova, who have solutions based on J2EE but have decided to go for massive productivity by sacrificing some standards support such as Struts.

There are many approaches to application development, and they have to suit the needs of your development organization. If your group is mostly technology elites, there are plenty of tools for you to look at. If you have a mix, then it might mean you need some tools for both groups. If your team is mostly business developers and speed of development and productivity is the name of the game, then a slightly less-standard approach might be in order.