Early Software Development and Evolution
In the 1980-1990s era of software development, the tools and architectures used by developers made it difficult to effectively share code. The use of functions and procedures evolved into object-oriented constructs that helped developers think of the solutions they were developing as a series of objects that were joined together. These objects constructed the solution and improved the ability to share code.
Over time, this concept evolved into Service-Oriented Architecture. These Service-Oriented Architectures not only created self-contained constructs but also provided easier access from other systems that wanted to use the functionality.
The concepts have continued to evolve into microservice architectures which have simplified the deployment and management of the solution's building blocks. Together, they allow an architecture where developers can easily and securely plug new components into their solution.
As architectures evolved to promote better, more flexible, and secure code reuse, developers’ mindsets about sharing their code have evolved and matured. Developers held their code close, even going as far as obfuscating it to prevent others from using what they had created.
As modular code became accepted, developers started to push each other to create reusable code. Developers became comfortable with other developers in their organization building from their code and enhancing their code. This shift in mindset gave rise to participating in open-source code, but mostly only for pet projects – not for true production quality code, and not practiced for commercial code.
As architectures enabled more effective techniques for sharing, developers (and their organizations) started to become comfortable with leveraging open-source code. Today, some of the largest commercial software development companies not only share their code openly but often make large contributions to the open-source community and leverage contributions from the community to expand the capabilities of their solutions.
Maturating and Shifting Mindset of Software Development
Maturity in architectures occurred hand-in-hand with maturity in the development profession. This has led to a fundamental change in the buy vs. build debate.
In prior decades, developers might consider using a framework to provide key functionality within their solution. Some development teams would consider buying a solution and integrating with that solution to provide the functionality they needed. This “buy instead of build” mindset was viewed as a good alternative.
However, it often incurred significant costs when the solution evolved and dramatically changed. This caused the development team to spend a significant amount of time keeping their solution working with the underlying solution, instead of spending time creating features their business needed.
As the software development discipline has evolved, so have the approaches to buy versus build. Beyond just frameworks, today's solutions encompass service offerings, SaaS solutions, platforms, and combinations of each of these (Salesforce Platform, Microsoft Dynamics 365, etc.)
With the ease of integrating cloud-based solutions, the question of buy versus build is no longer a binary decision. Rather, it is a decision based on what portions of your system you want to buy and what portions you should spend capital on.
These questions are ones that Improving regularly helps its clients with. We have seen that teams who adopt microservice architectures are much more effective at integrating cloud-based solutions capabilities into their solutions.
Having the experience to break a solution into key components allows these teams to identify portions of their system that can effectively be provided by already-built solutions. This way, teams can focus their time on the key business values of their solution and develop code that is truly a differentiator for their business.
Modern Software Solutions
At Improving, we have seen some clients struggle with details of the third-party solution that they choose to integrate. Too often, development teams get hung up on how the solution provides its capabilities and starts looking for ways to work around it.
It is important that teams focus on what the solution provides, not how it provides it. If you have a specific concern with the “how” side of the solution (e.g., special security concerns), don't expect the vendor to make changes to the solution for your needs. Instead, look for other solutions that meet your “how” requirements.
Don't spend significant development time trying to work around the “how”. If you can't accept the way it functions, find a different vendor or reevaluate if the “how” is truly important to your solution. In some cases, this "how" may be your secret sauce - the aspects that make your business different than others and the reason why you should build it.
Summary: Build or Buy? Both!
Cloud technology and microservice architectures have simplified the decision of buy versus build. These changes have allowed development teams to effectively integrate solutions.
In today’s cloud-first world, developers are often pushed into a buy AND build strategy. Development teams looking to provide business value must be adept at identifying where they should focus their efforts developing custom code.
When it makes more sense to buy and integrate a third-party solution into their own solution, development teams must make good decisions about the third-party solutions being used.
If your development team isn't leveraging cloud technology or microservice architectures yet, Improving can help you become proficient, so your teams can use the buy and build strategy instead of making a binary decision on buy versus build. Contact us today to get started on your next modern software solution
