I'm interested in how people are running against the herd and why.
A good example of what I mean would be HN's use of tables for layout--it's not trendy.
For myself, I am playing with stylesheet formatting so most things are on one line, which I find faster to get around, and easier to see more at once. Another example is I now rarely abbreviate in variable and function names. I've decided I waste more time remembering my abbreviations than I would spend typing the word.
For instance, we have a user service (which controls accounts, sessions, etc and has its own database), a metadata service (which controls what files we know about, what tags they have, etc and has its own database), a file service (which controls the actual binary data of the files and has its own database), etc (we have a few others, but that gets the point across). They talk to each other through REST -- though it could be anything, of course -- to get anything done they might need.
This allows us to scale each service independently, which is great. I'm always surprised at how long it takes folks to move to a SOA.
But, perhaps, the coolest part from an always-hungry-to-try-new-things development team is that having a service based architecture means that we are free from programming language constraints. As long as the language can speak HTTP, we can try it out for a new service or a new client. There's nothing like the feeling you get when mastering a new language. And there's no better way to master a language than write something tens of thousands of people will be using.
So, we have an old front-end built in C#/Mono, we have a couple Rails services, a Java service, our new APIv2.0 (http://api.openomy.com) is written in Haskell/HAppS (which I'm particularly proud of), and now we're writing a client in Scala. And, besides that, we use Perl for some offline scripting tasks.
I think it's pretty unconventional-- but it shouldn't be! I highly recommend going this route.