Firstly say No to SQL
These days with the popularity of No SQL / No UML and everything No which was previously Yes we are now entering the No era of things. There was a time when traditional databases moved from plain old databases to RDBMS and it was the biggest paradigm shift of that time. Now it is get away with the overhead of everything that comes with RDBMS and move towards No SQL.
Apparently the fact remains that SQL still remains a most sought after job skill to have based on indeed.com search listings. This movement reminds one of the era when certain medicines were considered good for health are found to have lost their relevance and things moved eventually to better things. Everything big is now embracing the No SQL movement , big data, big users (massive concurrent number of users) and cloud computing. The data that all of us collectively keep churning out simply puts RDBMS out of the picture being capable of handling that level of scale. Once you open up your web delivery mechanisms to the app world(blackberry,strawberries, apples and all the fruits out there !! ) .You could potentially hit several hundred million hits in a short span of time. Much of the data is semi-structured and unstructured which does not conform to a normal schema and much less conforming to any data model.
Why No SQL Maps fits the Cloud Model
The traditional model of scalability is put a load balancer in between commodity servers and as soon as the users reach a set limit say 10000 users route them to a new server with a routing logic at the load balancer. This works fine at the web tier but eventually when the data comes over to the database tier , being centralized and share everything would create issues and help only scale up and not scale out would be possible. This meant dynamic scalability was not possible and easy.No SQL databases were designed to be distributed and help scale out as the distributed computing needs increases.
Why JSON is becoming the standard sought after ?
When dealing with dynamic data we often encounter data which can be outside strictly of the rdbms schema model . All of us have stories of how changing a parameter within a control structure of a three tier application or rather n-tier application is rather difficult . This over a period of time was met by linked lists and key/value pairing kind of solutions which would bunch newer data in this format and send it all the way to the database. At the database layer we would then need to disassemble them into respective DAO objects and push them into the respective tables. All this is fine if the table structure itself is not changing. If the table structure has to change then it would mean that changes in the following :-
1. DAO layer 2. Schema / XML / Meta model layer. 3. Java generated boiler plate code for the db layer.
This is developer and release nightmare if needs to be done any which way agile or non agile in the shortest time to value cycle. In such cases developer would prefer to stack up all the information across db tables in objects and prefer storing objects as they were instead of in tables the traditional way. No SQL would mean now the entire JSON objects would get stored into the database as it is and can accommodate any free format. This would ensure that you aren’t fiddling around with the current application state in a disruptive way. Not knowing if poking something here would pop up something on the other side or at times the systems fails to come up.
Secondly say No to UML
Have heard the thing that UML is a big overhead. Most often we see people sure need to know how to document using UML but prefer the white boarding technique to charting diagrams. Post running through this in their head or code it first with back of the napkin kind of approaches then finally document the hard to understand must be read before cracking the code figures being put up via UML. Some prefer calling this as AML or Arbitrary UML but there are a lot of standards that are cumming up at least at an enterprise level that indicate a less techie and more friendly to the end users / business folks kind of language. ArchieMate is a step in that direction. But again you still need UML at all costs and needs to be given its due where required. But will not be the be all and end all of artifacts documentation and most people would agree it never was in the first place. There are tools which help to get the diagram and the code in synch but again haven’t seen or heard of this practice as been followed as the done thing.
Given the No to SQL and UML I am sure there will be many more along the lines of lean code, lean organisation and lean startup and many things lean on the NO movement. Say Yes to NO where applicable and you suddenly are a most sought after person indeed the YES guy….
