11/6/09 :: [Other] The NO SQL Movement [permalink]
Our industry loves to kill its stars of the past. The latest post from Julian Browne provides a spectacular insight on how this relatively unique phenomenon occurs. Here it goes:
About four years ago I sat in a meeting that had finished early. We were chatting away and the subject turned, as it always does, to the lamentable state of IT....Wherever we had invested significant funds to improve and mature our infrastructure we were now spending significantly more and taking longer per-project even for minor changes...that day ... changed my mind about what a good architecture looks like. ... We'd uncovered a major cause of architectural rot and that there were things we could do to work around it, but not what the 'right' answer was. A bunch of people came to the same conclusions as we did, but did know what to do about it. And they went and built real things to address the problem. These people are the pioneers of the NoSQL Movement and they represent probably the most important change in architectural thought for ten years.... [last but not least] Actually many of the concepts aren't new.
You guessed it, this paragraph works for anything, SQL, SOA, Web Services, CORBA, EJBs, REST, whatever. This is how our industry supposedly moves forward.
Let's replay the pattern:
- The way we do things sucks
- We tried, X,Y and/or Z and it sucks even more
- Somehow, somewhere, someone has a "ah ah" moment
- He or she rounds up friends and family and creates a No X, or No Y or No Z movement
- This nihilist movement is poised to become the most important breakthrough in the industry
- But no worries... these concepts are not new, you are already familiar with them
For Julian, it is No SQL, for Stefan it is No WS, for some it is No EJBs, for me it is No CRUD & MVC,... we are all nihilists. No need to say that analysts and pundits LOVE this grand creation wheel. An infinite number of arguments can be derived from it, and of course, in the end we realize that nothing can really be annihilated. Some even call for a resurrection, with the expectation of creating a new circle of "innovation" and of course more importantly monetization.
Julian gives a great business example to illustrate what he is nihiling about. His business problem was that he needs to change its data model from one supplier per order to many per order. He complains:
The ORM in Rails is good, but not perfect. Although it simplifies our code and allows us to change that quickly it hasn't done anything about the data underneath. Even in the simple example above there's quite a bit of data restructuring and migration to do behind the scenes.
Yes, life sucks. We all wish we had push button technology or even a fancy natural language interface and somehow, automagically our systems of record would adapt to our ever changing mind.
Julian's solution? ... Documents.
Businesses are very used to dealing in documents. They like them because they can be passed around (workflow), annotated (audit trail) and are so flexible that they can cater for two instances of the same document type being treated entirely differently (prototype-based inheritance). If we could develop an alternative architecture that was document-based and not based on relational-tables we might very well have something.
Serendipitously, Julian explains:
We did develop a few good ideas, including what I now see was an inadvertent reinvention of REST
But of course, Julian. He actually even goes as far as explaining:
I'm a big fan of Domain Driven Design, which, if you remove all the practices and foofaraw, is all about creating highly expressive models, models that stretch from requirements to code without creating an impedance mismatch between the business and the developers.
In the end it's pretty clear that we live in a multi-dimensional space and optimizations in one dimension, even though interesting or even useful, have created this architectural vortex we are in. Yeap, "documents" are such an interesting idea, until you need to report on them or even create UIs that deal easily with variations. Nothing is impossible, yes new reporting engines could be created (Tilion was one of them back in 2000) and some dynamic UI framework can be designed, but what will be the next problem?
The only way to get out of this architectural vortex is to separate programming and operations models from architecture. MOP tackles the former while William El Kaim's Cloud OS concept can tackle effectively the latter. The problem is not (or is less) architectural, the problem is about the way we harness software architecture. We don't seem to understand that an information system requires multiple execution environments, there is no way around it, but it does not mean that the programming and operations models have to be fragmented. As a matter of fact, turning off architectural elements to solve programming or operations problems is the worst way possible to make progress.
Be a hero, say no to architecture nihilism.