I released five new sample lessons from my Test With Spring course: Introduction to Spock Framework

When Business Dictates Technology Selections

A few days ago I found myself in the middle of an argument concerning the best build tool for Java projects. Somewhere during the discussion, I realized that there is no tool, which is best in every possible situation. Naturally, this leads into a conclusion that the best tool for the job must be selected individually based on to the requirements. What is the catch? Of course technology selections must be based on the job in hand. In reality, all requirements will not be technical.

I bet you are now asking from yourself: what is this bullshit? I thought I was reading a blog written by a geek. Well, you are. The thing is that some technology enthusiastics do not see longer than their noses. What makes things worse, if they do, it is probable that they are observing the enemy. The enemies of a technology enthusiastics overruns their opinion by saying something like:

  • We have selected our technology portfolio, and cannot change it without careful consideration.
  • Well, this might be the newest trend, but what guarantee do we have that it will still be around five years from now?
  • I feel that this might not be beneficial enough to justify giving up the synergy benefits, which are given to us by the status quo.

Even though these statements might at first sound like typical corporate bullshit, the logic behind these statements is solid. I will walk you through my reasoning in following:

Honor the technology portfolio. It is important to understand that each part of the portfolio has been selected with careful consideration. During the time of the selection, each part has been fitted in with the other parts of the portfolio. Together they form a seamless machine. Changes, which could have a negative effect to the function of that machine, must indeed be justified. However, it is not impossible to make changes to the technology portfolio. If a part of a machine is broken, it must be replaced. One must remember though that before replacing the broken part, it must be ensured that the replacement part fits in seamless as well.

Continuation makes sense. To a certain point, it makes sense not to fix something that is not broken, at least in a way causing a disaster. The evolution of software development tools (programming languages and frameworks) is so rapid that using the coolest tools is not always wise. Sometimes, it might even be just stupid. If the community behind the tool, which is currently the hottest thing in the industry, is small or not matured, the risks are simply too high. Naturally, the same applies to the tool itself. If the changes between different versions are huge and not backwards compliant, it does not really matter how innovative the tool is. Constant and compulsory changes to the source code, which uses the tool, makes it unsuitable for production usage. The lack of commercial support can also be a minus, especially if the tool in question would be an essential part of company’s business.

Synergy benefits saves time and money. Synergy benefits is a term, which has a some what negative echo among employees. In this context, it means saving both time and money. Implementing the applications by using same technologies offers several immediate benefits to an organization. First, it prevents vendor lock in. It is not wise to put all eggs in the same basket. By preventing the vendor lock in, the organization has got free hands for selecting their subcontractors. Second, maintenance work becomes easier and more efficient. Since the skill set required from the maintenance personnel is always the same, there is no need for application specific maintenance teams. Thus, maintenance work can be guided to a place, where it is needed the most.

I have now described the reasons, why I feel that people making business decisions should have control over technology selections. The reason why I feel that this issue is so important, will be revealed next. The scope of a single software project or a technical problem, which should be solved, is quite small when compared to the scope of business decisions made inside the organization. Technical staff has to concentrate only to the solution of a problem, which is given to them. Even though that is a huge responsibility, the problem area of persons making business decisions is typically much broader. They have to also review, what kind of effects their decisions will have to the organization and its business. That is why business can dictate technology selections.

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

0 comments… add one

Leave a Comment