📆 Tool choices: When to build, Buy or Wait?
Boat building tools, Auckland Maratime Museum
July can be a tricky time to make a tool choice. Today is 70 since Google IO, 57 since MSBuild, and 131 days until AWS re:Invent. This time of year is a limbo period where we may be looking at new services from new vendors, but your existing vendor(s) may be about to announce their version of the tool you’re looking for. Should you wait?
The Dilemma of Choice
We visited the Maritime Museum in Auckland recently. I was envious of the simple selection of tools used to build a boat. I often work with Software leaders who are drenched in more and more tooling decisions. Decision fatigue is real, but interestingly, the increasing pace of tooling evolution makes waiting for the right tool to come to you a more effective tactic.
We start a technology decision with a problem to solve. We look for solutions close to home - our existing vendors, partners or what product has become synonymous with the use case - Vacuum cleaner & Hoover or Online Payments & Stripe. Next, if there is no obvious choice, we look for how other people solve the problem. This search might be talking to new vendors or open-source solutions - both options come with baggage like compliance, governance, and the overall complexity of yet another thing we're responsible for and need to learn.
I've had this with API gateways, search databases and event streaming. The community created powerful tools like NGINX, Elasticsearch and Kafka for these use cases. Still, the situations were working in didn't justify the burden of learning and operating these solutions. The first commercial vendors of open source offerings design for large or enterprise customers with intimidating pricing, contracts and business case drama for you and the team.
After a year or so, two or three things happen:
🌱 The commercial offering improves the value proposition for small businesses
💰 A big vendor buys the small vendor
✅ Your public cloud vendor(s) release a me-too version
The AWS, Azure, Google or other service may be less feature-rich but is more likely to suit their existing customers - you.
📢 Big Annual Events
So what to do?
Build your own solution, maybe with open-source tooling?
Buy the solution from a new vendor?
Or perhaps anticipate and wait?
To help make the decision, you need up-to-date data on what's happening in the ecosystem you're interested in. That's where the big annual events come in, and this time of year, we've had a few and more to come.
March: Salesforce TrailblazerDX:
May: Google IO, MSBuild
June: Apple WWDC
November: AWS re:Invent, GitHub Universe
I scan the announcements from all these events to build a picture of what is coming (or not) within the ecosystem I'm interested in. You can also talk to your existing vendors and network. Let them know what tool you're interested in and why and see how they respond. Actual conversations with experts in the field are often very informative on what's around the corner or what you may have missed.
🗺️ Mapping it out
Simon Wardley's value chain mapping is super helpful in making sense of the ecosystem info you collect. You have your own need(s), then lay out the value chain of meeting those needs and what's happening in the ecosystem of tools and solutions in the chain. How are the solutions distributed across the evolution scale from genesis >custom > product > commodity?
When Waiting is Beneficial
Why not just go for what's available now?
1️⃣Native offerings are more straightforward. Like boat building, reducing the number of parts in your delivery systems always helps.
2️⃣Smaller compliance footprint with solutions from your existing ecosystem
3️⃣Skip the eventual migration of tools when the niche product becomes part of a commodity-level offering.
⏱️Can you wait? Even if you anticipate a native solution is coming, you may not be able to wait, but at least you can respond to your new tool choice with the understanding you're there for a good time, not a long time.
🚧 A working example
I'm in this cycle again for Engineering Productivity tools, specifically developer portals and software delivery performance metrics.
Some players in Software delivery/productivity tooling
I have info on what people are doing for custom solutions, open source and early product offerings. Still, I need to map things out to check my assumption that the more prominent vendors like Amazon, GitHub, and by extension, Microsoft will bring responses to the market. E.g. GitLab already includes decent metrics and emerging options exist for hosted BackStage or proprietary developer portals.