There is a mind-boggling amount of resources and tools available for the developer. NoSQL options are also an ever growing variety. Context in most cases is at the heart of any business decision process. One must evaluate the needs of the business cases for application in order to understand the requirements and then to weigh them out in terms of their importance. This is often not an easy matter as it not only requires communication and convincing to stakeholders, but also to the wider team. Choosing the right database solution is crucial. It can mean start of a successful application for a competitive advantage or could mean nightmare later on.
A general trade-off process can be applied in reaching a constructive decision for a database architecture:
- Introduce the process to the business and teams
- Gather the respective requirements
- Narrow down the requirements that are most applicable to the business
- Select a set of NoSQL architectures
- Evaluate by way of Use Cases
- Estimate the level of complexity for training and implementation
- Apply specific weighted scores against all the different cases
- Produce a documented set of results of the findings
- Lastly, communicate the results to justify and reason to both stakeholders and team members
This is a similar approach that was introduced by Carnegie Mellon ATAM in order to evaluate how a new solution fits into an existing architecture and weighs the specific risk factors.
One then has to apply a decomposition in form of a set of quality trees to formulate a solution through divide and conquer in order to break the complexity into smaller chucks of functional components. Here again defining granular use cases and scenarios comes in handy. An architectural choice could have associated quality trees defining a set of target attributes. These attributes would usually be in form of all the relevant abilities one can think of as a formal criteria for evaluation:
- Scalability
- Availability
- Supportability
- Portability
- Sustainability
- Security
- Searchability
- Agility/Modifiability
When evaluating hybrids they should be done separately on their own so as to avoid any incorrect analysis. Once a set of quality trees has been conceived, one can then relay them to stakeholders in form of navigational maps and clearly display the specific project risks. After this stage, one can prototype or pilot a project. However, even at this stage there is a set process involved:
- The likely duration of project
- Technology transfer process and willingness
- Finding the right data to use
- Finding useful data to use
- Defining a key set of success measures
Lastly, one has to be aware that often introduction of new databases especially NoSQL means a careful analysis. Many teams have to be sold on the idea and benefits of moving away from a relational database into a NoSQL option. Change is not always an easy aspect to adopt or convince especially with lack of organizational willingness to accept it. Atleast, following a constructive approach attempts to alleviate apprehensions and provide insights into the merits of such a business decision for change.
