Disposable Applications

In the early 90's, the company that I worked for had 3 different application platform strategies:
1. Purchase large, off-the-shelf (OTS) packaged apps
2. Build applications that were core to the business (Core)
3. Build rapid apps for non-core or non-long-living applications (Non-Core)

Back in those days, we used PowerBuilder for #2 (Core). PowerBuilder gave us enough structured techniques to build fairly complex business applications. It recognized the number one use case in business apps: Capture user information, Save it, Make it available to others. Surprisingly, this DB intensive technique could be used on a high percentage of problems. It stunk at workflow / groupware - but luckily this is when Lotus Notes was emerging. Now we had a tool that could rapidly create collaboration environments for non-structured data. We could also use the people in the company who couldn't code worth a shit (and we couldn't fire) to actually get something done. Yes, we called this people "Notes Programmers". And we had a ton of them.

Generally speaking, we considered the Notes team to be creating 'Disposable Applications'. The people were cheap, the licensing was cheap enough, and the throughput was high. We allowed them to knock out small applications - and they did - they churned through them. Then an interesting thing happened... our users started telling us that they wanted the new application to be done in Notes (not PowerBuilder). "What? You want it in Notes??? Those are the idiot programmers that we couldn't fire." I thought to myself.

An interesting dynamic had occurred. Our users realized a handful of things:
1. The Notes team delivered applications faster than the PowerBuilder team.
2. The Notes team didn't make the users feel like technical idiots; thus they became friends with the team.
3. On occasion, the users would make small changes to the Notes applications themselves.
4. The users realized that in addition to collecting, storing and retrieving data, virtually all business processes involve workflow and collaboration. In fact, the collaboration was often more important than the structured data.

I have the unique opportunity of seeing lots of service oriented offerings. Virtually all of them are of the 'PowerBuilder' classification. Most of them start off by integrating into Eclipse or Visual Studio. Ok - with this as a starting point you have already determined that you aren't a disposable application. The next thing that I see is that vendors expect people to understand XML Schema. This again, precludes the disposable community. Should they know XSLT? Nope. BPEL? Hell no. XQuery? Uh... No.

In order to create a Disposable Application environment around a service oriented infrastructure, one thing is absolutely necessary:
- The developer / author shouldn't have to know anything about SOA. No Exceptions.

Most talented engineers hate environments like Lotus Notes. They roll their eyes thinking about scripting hell, inability to enforce uniform constraints and business logic, inability to leverage a common data model and perhaps most significant, it allows dumb shits to look smart.

Talented engineers would much rather create a distributed state machine leveraging a set of 30 WS-Protocols across a messaging infrastructure that leverages a VM that facilitates heap size manipulation, while programming to a set of 17,000 classes that represent the "enterprise API". And oddly, customers are preferring to buy packaged applications that are already fully developed over having custom apps built. Who'd have guessed that one?

So, you ask, am I in favor of disposable applications? Hell yes. It may hurt your ego but it will be kind to your wallet. The real trick is to determine how to design a service network to facilitate disposable applications. It should be possible to create a constrained and structured set of services that contain the end development environment enough to allow 'power users' to do their thing. Then, it is off to the races.