On the last trip I was fortunate to sit next to a Web 2.0 evangelist (that’s not their official title, but what they end up doing frequently) for one of our larger clients. In our conversation, we talked about lines of businesses using Web 2.0 technology — mostly mashup stuff — to build their own disposable applications.
The Deal with the IT Department
In the main, most IT in large companies is farmed out to the IT department. This is good and bad:
- Food because centralizing on the IT department gives you, the company, more of a chance to control costs and comply with regulations.
- Bad because the IT department becomes a bottle-neck and (more than likely) moves implementation time from week to months.
In times of cost-cutting and compliance, the good often wins over the bad. In “looser” times, the bad of slowness drives the company mad.
FileMaker and Hypercard
In days of yore, we had FileMaker and Hypercard, two rapid application development platforms that relied more on right-click programming that keyboard programming.
In the last few years, I had the “pleasure” of “writing” an application in FileMaker. As a “real” developer, it was no fun, and I kept wanting to dip my hand into the gear-box to tweak things. For example, there was no (obvious?) way to simply execute straight SQL against the FileMaker database.
On the other hand, I could actually quite quickly write the application from data-model to GUI. More important: after a few hiccups, it’s served the users well and I’ve had to do very little support.
That is, FileMaker solved their problems. That is, in the short to medium term.
Upgrade Time
Long term, once the users wanted much more sophisticated reporting and functionality, they’re thinking of contracting out for a re-write. Of course, they’ll probable never actually do this: they’re not technologists and they’d rather prioritize their main business much, much higher than editing their tools. While they’re “stuck” with FileMaker, it gets the job done better than the manual process they had previously.
Thinking further back, Hypercard had much the same utility. The metaphor of a stack of cards with links between them, glued together with AppleScript worked well. It was early constraint-based design and tooling.
I’ve even heard that Hypercard was long used a “good enough” front-end for AS/400’s. I’m sure there’s still some stacks in production.
The point here harkens back to our less code/config idols of several years ago. For many business applications, in the short and medium term, throwing up a good enough platform is good. It’s like an appetizer until the main course is cooked. And if that main course never gets cooked, it’s a good enough meal.
Filling the Gap
Looking at the use of Web 2.0 technology behind-the-firewall, many of the same opportunities exist. Mashup servers, wikis, blogs, XML-over-HTTP, and dynamic languages may seem toyish and not check off all the items a line of business needs to satisfy the long-term goal. But, that bag of tricks might curb your appetite long enough to let the IT department code up the “real” solution.
Of course, this can be a massive tar-pit of problems. The core issue is allow the user’s data and config to be migrated to the long-term solution. In all my years as a developer, that’s the first thing to be ignored, even before testing: a solid data model. I’m often quoted as saying unit tests are the dog everyone kicks as they go out the door. Data models are the dog that was long ago buried in an unmarked highway grave, probably dug up by other dogs as a snack.
Yes, it’s that bad.
Web 2.0 Providing More Options
But, if there is a simple enough way of exporting data and it’s semantics from the good enough solution, architects can at least make a more informed risk decision to give the business a good enough short-term solution. It’d be great if that data format was a standards-based data format, but I’ll take simple over standard in a crunch.
As I’ve said before, whole-hog, “real” Web 2.0 is about a lot more than just technology. That said, when it comes to delivering quick, good enough solutions, Web 2.0 technology seems to have inherited the quick-fix position that FileMaker and Hypercard once served well.
Aah Hypercard … fond memories here too. With a lot of internal IT development being shipped out, and packages implemented, the ‘good-enough’ DIY mashup engines may become very popular …
It’s a good point about the data model though (and it’s also one of my current tasks) – and this is something that is very difficult to outsource, as an understanding of the business vocabulary is critical in building a usable and useful data model