"A very interesting observation during the talk was that Twitter started up with a CMS model and that they gradually moved towards a messaging model. I’ve seen this in a few applications so far, including a casino system, where the messaging model seems to fit best an application intended to power massive community of online users, it seems regardless of what the application actually does business wise. Applications start out completely different, but then more and more functionality gets bolted on top of user messaging capabilities that the whole architecture on the end gets refactored to utilise the messaging channels as the core information transport."
- from Gojko Adzic » Upgrading Twitter without service disruptions
I can't agree with this statement enough. It's amazing the assumptions starts with and how a system really get used and evolves (particularly, one that's actually useful).
We just ran into this same problem in a big way with an in-house ProjectsDB system that aligns money, people and effort with organizational goals. Originally, this system started off as a way to propose projects and quickly bolted on functionality to do many sorts of things (and was originally planned to have a datamart complement project for reporting and analysis to work across this and a handful of our systems).
As the org needs evolved, though, and as the appetite for the value of the app increased, the initial model and assumptions for the application changed dramatically, which ended up pushing the app in a direction untenable with its original architecture and design.
We just finished a new release (live Friday!) which refactored the underlying code base and data store (it's now running on a MySQL RDBMS and a CouchDB key-value store) as well as doing a big usability pass on it (Have I mentioned lately how much I lurv Rails ? I can't imagine having done this refactor in another language and framework).
This is one of the reasons Agile as a dev methodology has been working so well for us in the switch away from more static waterfall models at Amnesty (read: Prince2). We're still working on educating senior management on what that exactly means, as I think the prevailing model in business here in the UK is more about buying or building a system and then just
maintaining it into decay and replacement rather than having systems continually evolving, but the benefits in terms of what we've been able to get out the door has been impressive compared to (IMHO) what's been done in the past.
How does this sort with other experiences of systems they've had to construct in-house, or implemented ? (actually, I imagine this would bring out some pretty big disaster stories actually since fixed and unchanging initial assumptions seems to equate with software death) Wondering. Seems a big sea change being driven in web deevlopment but taking a long time to trickle down to enterprise IT.
Oh, also here I should also thank the hard work of our patience-of-a-saint, long suffering dev, Matt F. (who we wish the best of luck to as he's leaving to go indie and start his own dev shop with his fiancé) and the continued support of our face Rails propellor-heads, the jolly pandas over at New Bamboo.