And, Not Or – How Modern Software Architectures Influence the Build vs. Buy Debate

Previously, we spent some time going into the history of the “build vs. buy” debate and discussed some of the factors going into that decision. These include cost, time-to-market, ongoing maintenance, competitive differentiation, and security and compliance concerns. Today, we will delve into how modern architectures have transformed this into “build AND buy” rather than “build OR buy.”

Traditionally, when we think about application development, we think about writing many thousands of lines of code to do everything from logging in users to logging errors.

This changed with the advent of many open-source frameworks in the 1990’s and 2000’s. For example, in the early 2000’s Log4J was released as a logging utility framework for Java and was soon ported to other platforms. It allowed developers to quickly log errors and events as well as configure logging levels and outputs across their application.

While it saved countless thousands of hours of development time, it meant that developers began to spend their time managing frameworks: installing the latest version, addressing any incompatibilities, and recompiling and redistributing their product. Log4J is an especially interesting example given that the Log4Shell exploit was one of the biggest security vulnerabilities in the past decade, forcing many large software vendors to update their products to address these issues. This highlights the benefits and risks of using these types of frameworks.

The Rise of “As-a-Service”

Two prevalent architectures came together in the early 2010’s to open a whole new way of incorporating pre-built functions into custom software: service-oriented architectures and the cloud. As AWS, Azure, and GCP matured, these vendors began offering more and more sophisticated services through an “as-a-service” model. Other vendors quickly followed. Suddenly, developers had easy access to a wide range of services, including:

• Natural Language services that easily translate speech to text or extract text from images or videos
• Security & Identity services that validate identities and access, manage secrets, and log access
• Integration services that provide message queues, event busses, and API management
• Geospatial services that geocode addresses or provide demographic information based on a location
• Artificial Intelligence services that provide machine learning and cognitive capabilities
• Mobile Computing services including notification hubs, content delivery networks, and mapping

These services, typically available on a consumption basis, gave developers easy access to functionality that would have taken months or years to write from scratch. Additionally, unlike the Log4J example, developers do not have to compile assemblies into their applications; they call the services, but usually do not have to recompile or redeploy their application if the vendor fixes a bug or vulnerability.

Why Build Solutions This Way

This type of modern architecture has several advantages over incorporating frameworks or “rolling your own.” Some of these benefits include:

• Time-to-Market – Using vetted, tested, and well-documented services drastically reduces development, architecture, testing, deployment, and maintenance time.
• Up-Front Cost – Paying pennies per call (or usually per 1000’s of calls) is much less expensive than paying your team to develop the same functionality.
• Maintenance – Amazon, Microsoft, Google, and other vendors are responsible for maintaining these services, fixing bugs, and providing additional functionality.
• Compliance – Depending on your compliance requirements (GDPR, CCPA, HIPAA, etc.), many of these services are compliant right “out of the box”.
• Scalability – One of the hallmarks of the cloud is scalability. These solutions easily scale up to support whatever volume your application demands.

Disadvantages of “As-a-Service”

As with any technology or architecture, there are some drawbacks to calling these services. These include:

• Loss of Control – These “as-a-service” services are, by definition, outside of our control. While the architecture somewhat insulates us from changes to the service, the vendors ultimately can remove functionality or even shut down the services. Additionally, you cannot customize nor enhance them; what the vendor provides is what you get.
• Cost – Depending on the pricing model and the volume of calls, consumption-based services can be more expensive in the long run.
• Security & Data – Although these services are generally very secure (though you should always do your homework to verify!), developers and architects need to be aware of the data that is shared with each service, any compliance issues between services, and how to securely call each service.

So, an answer to the Build vs. Buy debate?

We find ourselves back here again. Cloud services can change the “buy vs. build” calculation, so let’s look at each of the factors we considered earlier:

• Cost – Balancing development cost versus ongoing usage cost is not always straightforward and needs to be addressed on a case-by-case basis.
• Time-to-Market – Here, these modern architectures shift the balance towards building solutions. Incorporating these services significantly reduces development, testing, and maintenance time.
• Ongoing Maintenance – Again, incorporating cloud services tends to reduce the maintenance burden.
• Competitive Differentiation – Cloud services, by definition, do not bring unique capabilities to applications, but they can allow us to include “table stakes” capabilities cheaply, while focusing on other functions that do differentiate our business, reducing the cost and shifting the balance to custom solutions.
• Security, Compliance, & Scalability – As with cost, it is difficult to make a quick determination. Cloud services typically are secure, compliant, and scalable, but they must be implemented in secure, compliant, and scalable ways.

Conclusion

Modern solution architectures rely on commercially available, consumption-based, cloud services to easily add sophisticated functionality to custom applications. Incorporating these services reduces development costs, reduces time-to-market, and minimizes concerns like ongoing maintenance, compliance, and scalability. However, we sacrifice some control, may end up paying more in the long run, and still need to be very aware that the way that we use these services can have implications on security, compliance, and data ownership.

These architectures certainly do not make building solutions a foregone conclusion, but a “build AND buy” approach does make building custom solutions, tailored to the demands of our businesses, easier and cheaper.

At RevGen, we love helping our clients navigate complex business and technical challenges, and can help you pin down where you land in the build vs. buy debate. Please let us know how we can help you or visit our Digital Enablement site to learn more.

 Noah Benedict leads RevGen’s Digital Enablement practice.  He is passionate about using technology to advance business and empower his clients to embrace new opportunities.