For nearly 2 decades (yes, hard to believe but it's been that long), I've been developing database-oriented web applications. At first, it was using Unix shell scripts and Perl, then I entered the corporate world and ended up using Microsoft's ASP and SQL Server. Later, I graduated to Java, Oracle, and Postgresql. In the last decade or so, I took a sidestep into PHP and MySQL. So I've been around the block, so to speak.
For the first 15 or so, I found myself constantly doing the same things -- building a database schema, writing code to create HTML interfaces, and writing some more code to process the updates on the back-end. Then came the reports, which were unfortunately almost always an afterthought for the users. A little integration here, a few imports and exports there. That was the routine. It didn't matter what the platform was, it was pretty much the same thing. I can't say it was ever boring, because I was changing platforms every couple of years, but in a way, that also kept me from truly mastering any of them.
Along the way, I discovered frameworks such as Struts, Spring, and CakePHP. These did a lot to jumpstart development. They formalized a lot of the things I'd already partially worked out on my own, such as request routing, ORM, and MVC, etc. For the most part, they did it better than I could, so I used them. I thought I had it pretty good.
These apps were quite boring, I'm ashamed to say. They were all forms-based, with very dry and straightforward data input and reporting. But, then again, that was what my employers/clients wanted. They didn't care about flashy UI's. They just wanted their data to go in easily and their reports to come out easily.
One day, I found Drupal. At first, I used it for my company's web site. It did a reasonably good job as a CMS, and it had a lot of add-ons that I could use to do cool things. It seemed worth using to build a web site.
It wasn't until I tried CCK and, soon after, Views, that my perspective on Drupal changed. It looked like someone had decided to take the "scaffolding" approach that some of the old frameworks had provided and take it to the next level. Rather than even thinking about the database or the object model, as the RDBMS or ORM approaches would have you do, Drupal simply asked: What do you want the output to look like?
Granted, that's a simplification, but you have to admit that when using Drupal it's not in your scope to think of database or even the code that manages the business rules. You just install the modules you need and enter the configuration through the Drupal admin interface, and focus on how you want the node data to appear. Then, you build some views to layout the data in various ways. Maybe even throw together a few panels, if you're really interested in layout and presentation.
Even considering the above, Drupal does come up short in many ways when compared against a developer's framework such as CakePHP, but I have a feeling now after having hacked on it for about 4 years now, digging into the core and contributed code and developing my own complex custom modules. My feeling is that Drupal is already capable of delivering apps that provide about 80% of what can be done in these other frameworks -- without making you write any code at all -- and that adding in the final 20% may not be all that difficult.
So I started this group.
To start, I'd like to put together a list of what constitutes a data-driven application, viewed from an "enterprise" perspective, to borrow a buzzword. Or to be more clear, I want to ask the question: "What features would Drupal have to provide to make it possible for someone to switch from something like Java/Spring/Oracle or .NET/SQL Server, and use Drupal to develop web-based applications for a large organization?"
It seems appropriate to do this with a Wiki page, so I'll start there.