Dr. Dobb's | Situational Applications

Situational Applications

When the situation demands faster turnaround than IT can provide

February 01, 2008
URL:http://www.drdobbs.com/database/situational-applications/206102105

Mike Rozlog works at CodeGear and is a co-author to Mastering JBuilder. You can contact him at his blog.

New terms and approaches for describing software development crop up on a regular basis. These days, for instance, "situational applications" and "mashups" are popular terms, as large companies like Microsoft and IBM and smaller companies like Serena are building new environments to enable the building of these applications.

What are situational applications? According to Wikipedia a situational application is software created for a small group of users who have specific needs. These applications usually have few formal requirements, short time frames, and miniscule budgets.

Many companies that are talking about situational applications and mashups are using the message of the late 1980s and early '90s, which is that developers aren't needed and business people can build solutions without IT. Granted, this has been the case, at least to a large extent -- just look at the number of Microsoft Excel-based application/macros out there. But while I'm not against someone learning to extend software, I do worry about the traps that can occur.

If you've been around the software industry for any length of time at all, you're familiar with people creating and extending programs like Lotus 1-2-3 and Excel. The problem that this leads to, however, is that a lot of things get done repeatedly and differently in each department and some extensions are just incorrect. In short, it can turn into a nightmare for IT to get a handle around all of these in-house baked solutions.

But the real question to be asked is why do so many people in an organization need to build or extend applications? The usual answer is that IT has a backlog of things to fix and projects to complete. So when new ideas like situational applications or mashups pop up, it sounds appealing to the business person who has some data and wants to manipulate it, but can't wait for IT to get to the request.

The bottom line is that companies large and small are coming out with new environments to help support these types of applications. But do we need new development environments to accomplish tasks or build applications like this? The answer is "no". Many current application development environments already give most, if not all, of the same functionality of these "new" environments, plus advantages:

Single to multi-tiered applications let developers build complete command-line applications with a single .exe or .DLl, extend the OS Shell, or build a full-on GUI-based application in a single executable.
Multiple database support for enterprise databases like Oracle, Sybase, MSSQL, InterBase, and MySQL.
Ability to mature into a full application with real languages, full support for testing, object orientation, and lifecycle management, so that if it does mature it can be supported from an IT perspective.
Fast development thanks to standard components included in the environment.
Third-party and open source components to do just about anything developers would want to in an application.

The key to situational applications and mashups is to enable as many people as possible to get the job done. Delphi, for example, can help the developers get the job done and it has a full platform to build on, plus the applications can be built with little or no code in hours and days, not weeks and months. As the application grows, it has all the components and tools to continue or it can be discarded after use, without any real overhead or waste.

Here is a quick no-code example (using Delphi) of how you can build a typical situational application; a customer review program for marketing, in this case:

Configure "EMPLOYEE" database in Data Explorer.
Create new VCL Forms Delphi for Win32 or .NET app
Drag "CUSTOMER" table to the form and notice TSQLConnection and TSQLDataSet components added.
Add TDataSetProvider and point it to TSQLDataSet.
Add TClientDataSet and point it to TDataSetProvider.
Add TDataSource and point it to TClientDataSet.
Add TDBGrid and TDBNavigator, then point it to TDataSource.
Set TClientDataSet "Active" property to "True" and note live data at design time.
Run

For inexperienced Delphi developers, this process takes around three minutes. For experienced developers, it would most likely take less than a minute to build.

[Click image to view at full size]

Figure 1: Typical situational application

You now have a running application that is ready to deploy on Window 2000/XP/Vista. In another five minutes, you could add a better interface, a more generic way of pointing to various databases, and create an install program to distribute the application to users.

Environments like Delphi include the ability to enhance the program to support things like Web services, Web enablement, and have advanced tools like a real Windows frameworks, object-oriented language, and support for the latest standards like unit testing and advanced features like UML and static code sudits and metrics, so almost any solution that can be dreamed up can be handled. These environments have been around for years and are standardized on established languages and frameworks so the learning curve is minimal.

There are surely some people who find it fine-and-dandy to build quick situational applications with these environments. However, but our development shop does big projects with lots of requirements and has to be enterprise ready. Again, most of these environments are used in some of the most deployed software in the world, so they can handle projects of any size.

So in the world of situational applications, where the requirement to get a solution done quickly outweighs the design cycle, established tools can make an excellent choice.