Yes and No. If the meanings are not defined ahead of time as to what constitutes build versus buy, you could be arguing the same position. Another common derailment is the scope of the decision. Are you making your build vs. buy choice about an entire system (like a forest) or a component (tree)? Taking an entire system approach can lead to disaster, which I’ll get to shortly.
If only this were true. Google offers 195,000 opinions on ‘Build vs. Buy’. You could easily assemble a multitude of approaches and sites. Here are five recent posts and ancient pillars.
Scaylr, recently acquired by SentinelOne suggests a trifecta of True Costs, Inherent Risks, and the Problem You Solve.
CleverTap suggests another trifecta for their Build vs. Buy Framework: The Problem, The Budget, The Timeline. Great Infographics and visuals from this team.
DivbyZero by Massimo Chieruzzi echoes the great paradox of Build vs. Buy as a seller for build and buy. Massimo presents his checklist manifesto alongside some great methods for calculating total costs.
McKinsey in 2002 introduced the Portfolio of Initiatives. It was really something when it emerged. It continues to deliver value-based on when you need to do research and development (build) and when you need to farm things out (outsource/SaaS).
Breaking out my time machine, Michael Porter’s Five Forces causes us to think about the horizons of solutions and the shifts in the balance of power between buyers and sellers. Business 2 You has put together a great page explaining it all versus the 350 pages. Plus volume in my library.
It is so easy to get lost in the weeds of minutia and criteria that it becomes impossible to decide what is best. My own quest to find a better model led me serendipitously to something different and simple a few months back. How do I know? When your first response is, “I could have saved a ton of time and money and had better results had I known this earlier.” You know you are onto something good.
If you don’t know Simon Wardley, he is a researcher for the Leading Edge Forum focused on the intersection of IT strategy and modern technologies. Simon is a seasoned executive who has spent the last 15 years defining future IT strategies, which included driving Ubuntu’s dominance as the top cloud operating system. Simon created a concept that addresses Build vs. Buy and aptly named it Wardley Mapping.
In thirty short minutes, I was able to grasp the concept and have since then test-driven it with several friends. Many of its concepts have become second nature and you can learn it quickly too. Grab a beverage, take a breather, and watch this video. Not so sure that Simon wasn’t influenced by SNL’s ‘laser cats’ though. (you’ll see what I mean)
If you watched the video, you now recognize that we need a blended approach that creates strategic advantages in the right places, establishes efficient capabilities, and alternate sources for the undifferentiated. Knowing that everything progresses, we understand that everything moves towards commodity especially in technology and software.
Our approaches need to adapt to buyer demands and possess the agility to switch to commonly available solutions or eureka technologies that unlock the previously impossible. If the switching costs are high, we need to understand the time and cost to clear the barrier as well as when we need to start.
Many enterprise architects and major system owners are undergoing the decomposition process of how to shift to microservices. Gartner began discussing a concept last year. It’s called composability that targets the duplicitous waste and complexity of multiple business services having messaging services, siloed content services, and so on. Without a good MAP, it is easy to get lost and focus on the wrong things and underinvest in the things that will be most effective.
To learn or master any new skill, like mapping, you need to apply it over and over as well as test it with others. At edgeTI, we instrument and empower the operations of IT Operations, Cloud Management, Service Providers, Cyber Security, Emergency Crisis Centers, and Critical Supply Operations. I began mapping use cases and the underlying technologies. Placing them from nearness to stakeholders and aligning them by market state. It is easy to see where the R&D stuff is. Where the custom software needs to be, what is standard, and what is commodity. Everything has a place, position, and velocity.
I intentionally left out my own product edgeCore™ because every time I put it on the map and started drawing lines, it was engulfed by its connections to everything. Over-and-over the same thing kept occurring. It was like I had one foot nailed to the floor. Then it occurred to me, edgeCore is a real-time map of all the technologies and systems, capable of intervening at each function, regardless of where it sits in the evolutionary flow. It visualizes telemetry, drills into detail – even native consoles. Yet unlike BI, it can make changes and execute responses. It can also leverage and tap into the latest and greatest advances, such as new AI driven models like AIOps, SOAP, and SOAR.
Observability, Controllability, and Composability all in one package. Impossible to map because it is the map. It led me to one conclusion: edgeCore is the Buy that Brings Your Build and Buy together Quicker and Smarter.
Whether you look at our products or not. You owe it to yourself to learn Wardley Mapping. Feel free to write to me with questions and feedback on LinkedIn and Follow edgeTI