Search

Home > Devops Mastery > Episode 20 - Devopsmastery.com - Don't be a tool about tools...
Podcast: Devops Mastery
Episode:

Episode 20 - Devopsmastery.com - Don't be a tool about tools...
Category: Technology
Duration:
Publish Date: 2014-09-07 19:00:00
Description: Everyone loves a new toy. New tools help us do our jobs better, faster and more accurately. Which is great when you understand exactly what you want the tool to do for you. How often does that really happen though? As an Enterprise Architect I am asked on a regular basis to help companies deploy tools. The problem I run into the most is they don't completely understand what the tools can do for them. They know it will fix one problem but may not realize that it could be fixing others. Then there is the situation where the competing tool could have solved even more problems and easier. So why don't my large enterprise clients go through a process that prevents this? Every company is different, but sometimes it's a time factor. Other times it's not understanding the problem they need to solve. Each company is unique on what their specific issue is. Usually the core issue is that the selection process didn't have enough parameters or ignored parameters altogether. In a lot of situations and evaluations it's a problem of not communicating with other members of the evaluation team or with other teams. When people love a tool and have their heart set on using it, very often it's hard to get them to hear criticism about it. To avoid those situations they exclude people or groups that may have a different opinion or a different tool they are passionate about. People may also be trying to avoid paralysis through analysis. No matter what the reason the result will be the same. You will end up with a tool that you either never use all of the features or doesn't have enough features. This will require you to get a second tool when an alternative tool that covers both problems exists. The best way I have found to avoid this is too do selections in three phases. The first is to solicit the wish list of features from both the tools target users and the operations teams supporting it. Also ask them for suggestions of tools they like or hates using in the past. The second is to research the tools then start looking for feature lists. Evaluate each against the wishlist and not each other. Try to narrow the set down to two or three at most. The final step is to do a Proof of Concept with your top choices. In the Proof of Concept Phase Install them, set it up in a development environment, and actually make it do something. Ask the Users and support teams if each tool is doing what you think you need it to. Once you have things working then demo each environment. This will show how well, if at all, they are answering the items on the wish list for a small subset of the tools users and operations staff. If the Demo's go well then your choice should be clear. You will have done what you can to make people happy. Just don't expect everyone to love the choice. you can never make everyone happy.
Total Play: 0