Buy, Build, Blend or Blitz

Software procurement in our industry has to balance a constant tension between vendors who wish to sell you something ("buy"), and technical folks who wish to build something similar ("build"). What if there are better alternatives?

Sometimes the buy scenario just works, but more often than not teams are left with very expensive partial solutions: they have a lot of what they need, but are forced to invent creative, and yet fragile, solutions to satisfy the full requirement. In the build case, teams may get precisely what they need, but at what cost? Many of the tools required to build software are must-haves, but is the DIY investment really worth it?

We've also seen the emergence of concepts like "blend" and "blitz."

Blend combines buying and building of software. This is particularly common with API-driven tools and the emergence of lightweight platforms or frameworks which make heavy use of integration rather than providing all functionality inside the platform. This is different than the "buy" pattern in that there are no surprises: you go in knowing full-well that you will be integrating the "last mile."

We've not seen "blitz" talked about much among enterprise software teams. Here the goal is to pick off the shelf components which provide as much capability as needed to get a specific task done as quickly as possible. This already occurs when disruptions hit or when unscheduled priority shifts occur. I think the reason this pattern is looked at negatively is due to its association with technical debt and the lack of analysis that often occurs. I believe that is unfair: appropriately-managed debt can provide the leverage your business needs to achieve its next milestone.

What if the majority of software adoption should either be blitzed or blended?

Does every piece of software require an RFP or acquisition process to be successful? Is the toil of analyzing every available option in the market worth the upside this process theoretically provides? Can every team build every type of software? More importantly, should teams be building and maintaining software that is not core to their business?

Once you really think about these scenarios you begin to see the errors within the way we've been approaching this as an industry. What happens if you miss something, make a bad choice or miss an update? The edge cases are endless and the risk abounds, yet the biggest risk of all is the time allocated to prolonged analysis and overweight projects.

The upside to a blitz pattern is speed. It is not without risk, but because you are reducing the overhead of the associated processes, the actual risk is lower than the perceived risk. Following this pattern helps teams become more responsive; likely resulting in happier technical teams and downstream stakeholders.

The upside to a blend pattern is risk reduction. You can select a commercial, open source or in-house application, library or tool based on team skills, speed, complexity or any number of options available. Additionally, with standards-based API integrations, you may even find yourself with increased optionality.

We think the days of a buy vs. build discussion are coming to an end. The complexity present in modern software environments makes the other approaches more realistic for most scenarios.

This means software should be selected, based in large part, on its ability to augment and integrate with your existing technology investments. This allows teams to build what they need while still gaining a huge amount of leverage off-the-shelf.

And this is why we are so bullish about building our developer platform with Backstage. As you bring a developer platform into your organization, you will want to integrate with existing investments and our approach includes much of what you'll need including ubiquitous tools like GitHub, Kubernetes, AWS and the like.

But, you will also likely find that you have in-house tools that you rely on everyday. For successful adoption of the platform, these will need to be integrated. Our platform provides all that you need to integrate your in-house tools.

In short, blending and blitzing your way to platform capabilities is the path to developer efficiency. It gets your team on the same page and keeps you moving without overloaded RFP's or spending too much time on maintenance.