Microsoft Azure is rolling out new features at a fantastic speed. But when is the right time to evaluate those new features? It might be right as the feature is released, it might be later in the lifecycle. The basic answer to when to look at using new services is, it depends.
If the company has some problem that needs to be solved, that we can’t address today using available technology, or the solution we have built today could be made better, then a new feature or new service might be worth looking into.
If there’s nothing that needs to be solved, then the new feature isn’t helping you do anything. The feature is just shiny and new.
What it comes down to, is can the new feature potentially solve a problem that you or the company is having? If you can’t solve the problem, then the new feature isn’t going to help you. Now, this is going to mean some research into the new feature to see if it’s the right solution or not. But if the feature that is being researched turns out to not be a solution to the solution to the problem (or a better solution to the problem than what you have today), then it’s time to move to another solution to the problem.
All too often, companies decide that they are going to use a solution to a problem, no matter what that right solution might be. Even if the solution that they have decided must be used, costs thousands of millions of dollars a year.
Selecting a solution to a problem gets more complicated when there’s politics in the office involved. All to often someone from upper management will decide that some product needs to be included in the solution. This isn’t a new problem, either.
Back in the early 2000s, I was tasked with building a new knowledge base for a department at the company I worked at. XML was getting popular and was being mentioned in all the magazines. The knowledge base was supposed to be a normal relational database so that people could look up. A Senior Manager wanted to use XML instead of a relational database. I refused because XML wouldn’t perform well, XML wouldn’t scale well, and it would make no sense to build a database as a single XML file (which is what he wanted). He insisted we use XML, and I asked him if he wanted to use XML, or he wanted the application to scale and perform well. It took a while to get him to see reason, but eventually, he saw reason and we used SQL Server for the relational data of the application. And shockingly the application was able to be used successfully by thousands of employees on daily biases.
What it came to show, is that applications should be built to be successful, not to use some shiny bit of new technology.