Don’t confuse tools with technologies
Tools and technologies have many things in common: apart from both starting with the letter “T” and are cornerstones of modern digital businesses. They also both need mastery to be used effectively.
For house builders, house buyers, and do-it-yourself (DIY) enthusiasts, tools are never confused with raw materials. The resulting quality attributes of a structural building are based on the architecture, the quality of the materials, and the quality of the builders’ workmanship.
But when the work is digital, tools and technologies are regularly confused and lumped together in presentations, web pages, and CVs. Mixing them up not only makes conversations more difficult, but it’s also a recipe for poor decision making resulting in poor solution quality.
Technology decisions have a fundamental impact on the performance of digital products and services. Tools do not. With the accelerating use of AI and introduction of low-code automation solutions, the frequent and more important solution architecture decisions are to be made.
This article covers the main differences between tools and technologies and highlights the need for them be managed differently – by tech professionals and everyone engaging in the development of digital products and services.
What’s the difference between tools and technologies?
In short, technologies are a matter for solution architects and product managers, tools are a domain for our teams and skilled engineers.
Technologies are fabric solutions made of (and therefore an integral part of) those solutions. Technologies bring constraints and opportunities for the business to operate and serve customers and users over time.
Software tools, on the other hand, like builders’ tools, are downed when the building job is done. A tool’s usefulness depends on how it is applied and, on the engineer’s skill level.
The distinction is also important from a financial viewpoint. Software solutions that are built can be accounted for as assets on the balance sheet. Whereas tools are direct costs. Which makes the technology and tools distinction relevant even to accountants.
Knowing what’s what is only half the battle
The questions ‘What is it made of?’ and ‘What do you use it for?’ worked to make the point of the distinction between technologies and tools: brick-and-mortar never gets confused with a trowel. It also used to work well in IT after the rule of thumb: if it’s an integral part of the built solution that is running in production, serving customers and users, it’s a technology. If it’s only used in the development phase, it’s most likely a tool and should be managed as such.
However, with advances in automation of quality assurance and the use of cloud-provided services, it is no longer as clear for managers and developers of digital products. And even less clear for other stakeholders.
A more useful way is looking at the artifacts from the product lifecycle perspective
Our recommendation is that all artifacts created and used throughout a product’s lifecycle – design tokens, automated test scenarios, or Kubernetes network policies – should be selected and managed with the care of technology choices.
That means evaluating them for today’s use-case first and after scenarios for what properties are most likely needed in the future. Whereas direct costs and costs of implementation can be somewhat reliably estimated, the cost of change and the value of flexibility in the future are usually underestimated.
Rule of thumb: if it is costly to switch and you’re deciding for years to come, manage it as a technology. If the lock-in time is counted in weeks or months and can be reverted with minimum effort and risk, manage it as a tool.
Technology choices make a difference
A good technology strategy supports the development of digital solutions and business capabilities for the long run without compromising time to market or product quality.
Usability, accessibility, security, warranty, and scalability are just a few examples of technologies’ properties. All quality attributes are greatly influenced by the choice of technology. And so are the costs of building, operating, and maintaining the solution throughout the product’s lifecycle.
A good solution architect is an expert in evaluating the risks and opportunities that are inherent in different technologies, frameworks, and components. A really good solution architect also understands the skillsets and effort needed for both development and operations.
Tools are for teams to select
Tools on the other hand are extensions of our hands, much like the trowels of traditional bricklaying. Tools reinforce ownership, craftsmanship, and productivity. How tools are used greatly influences both the product quality and the flow of work. Tool selection should not be taken lightly, but also not too restrictive.
Tool selection is best made by those who are closest to doing the work. Great professionals will always be curious about new tools and testing out better ways of working for their teams. The best tool is the tool that gets the job best given the combination of the task and the skill of the practitioner.
Summing it up
In the fast-paced world of technology, the distinction between tools and technologies is not just a matter of semantics; it’s a fundamental aspect of effective digital product development. Technology leaders and leading engineers must distinguish categorically between both to be able to manage them differently.
Technology choices have far-reaching and long-lasting consequences. Solution architects in cooperation with product managers should carefully select and evaluate technologies in the perspective throughout the full lifecycle of digital products and services.
Tool choices, on the other hand, should be left to the ones closest to doing the work as they are bound and scoped within the product development lifecycle.
If you enjoyed this reading and want to grow your knowledge and stay updated on the latest technological insights, our Insights page is for you. Learn valuable insights on the DevOps shortcut to AI and how to Explain DevOps to Executives.
Are you ready to take your skills to the next level and leverage the power of Intelligent Automation? Explore the opportunities to join our Intelligent Automation practice.
Additional insights
Is it time to move from projects to products?
Time to put MVP to rest
The 2 key metrics delivery managers should care about first
