Is “Tailor” the Modern Solution to the IT Dilemma of “Build vs. Buy”?
To be honest, I’ve never liked the distinction between building and buying when it comes to software. Of course you shoud buy rather than build – if, somehow, there’s a third-party product that does exactly what you need, has the same roadmap for future development as your company will require, meets all your security needs, is very inexpensive and comes with great support, and developing your own would provide no competitive advantage. In other words, clearcut cases for buying don’t really exist. In any other case, the supposed build-vs-buy decision must be more nuanced. There is a third alternative, which is to “build” using building blocks that already exist. Many such building blocks are available in the cloud as high-level services; others are well-known open source frameworks and tools. In this blog post, Simon Carter explains this “tailoring” approach, and why it’s often the best choice.
by Simon Carter
In previous blog posts (Time to rethink Build vs Buy, Buy vs. Build Revisited: 3 Traps to Avoid), we’ve looked at the nuanced “build vs. buy” decision and how it has changed in the cloud era. Factors such as IT team skills, organization structure and agility, market differentiators, risk tolerance, and approval mechanisms all play a part. But a third option is becoming available that has some of the advantages of both, and you should give it serious consideration. We’re calling that option “tailor.”
The usual tradeoff between a built product and a purchased product balances speed to market and risk against cost. Your organization may favor one over the other for a variety of reasons:
Organizations that buy solutions tend to reduce risk by favoring the fixed-price, waterfall-style delivery of commercial off-the-shelf (COTS) solutions. An internal business case provides an economic rationale for each project, and partners generally deliver the solution. Business cases tend to have trouble quantifying the value of subjective areas like user experience and ease of use, and tend to underestimate the impact of change, both on schedule and cost. It can take months, if not years, to realize value.
The typical lifecycle of a “buy” project is assess and purchase, integrate, test, and deploy.
Organizations that choose to build solutions tend to favor variable pricing (with maximums) with agile delivery. A lighter-weight business case covers key metrics and the value of those improved metrics to the organization and to the customer. Cross-functional teams deliver a solution based on open-source and custom development. Change is expected and handled iteratively. Selecting the right technology tends to slow down the planning phases of these projects. Trying to build too much all at once can also slow things down. It can take months to start delivering a value stream, but once started, incremental value is delivered regularly.
The typical lifecycle of a built project is plan, design, build, integrate, test, deploy, maintain, and scale.
Is There Another Choice?
What if you could have the speed to market of a purchased product with the flexibility of a built product?
Can you jump-start the technical uncertainty building a solution and ensure you deliver a highly available, stable solution that aligns with Enterprise Security standards from day one and is cost efficient?
It turns out that you can. And it’s dead simple.
A New Choice: “Tailor”
Today there are more than 350 vetted solutions and reference architectures built by Amazon Web Services (AWS) solutions architects and partners. With thorough documentation, they provide best-practice jump-starts to complex solutions. They range from secure and compliant financial services environments to reference architectures for flight crew management. These solutions align with AWS best practices for security, high availability, and cost, and reduce hundreds of choices and manual procedures to just a few steps.
You can deploy these solutions in minutes and start tailoring them to your organization’s unique needs.
The typical lifecycle of a “tailor” decision is deploy, integrate, test, and optionally extend.
How Does “Tailor” Stack Up?
Let’s have a look at how “tailor” stacks up against “buy” and “build” from a management perspective:
From a high-level perspective, tailoring a solution can provide significant advantages to an organization. For example, it can reduce architectural overhead to provide a quick, secure, cost-effective, future-adaptable, resilient, and reliable solution.
We often find that AWS customers are not aware of vetted reference architectures they can use because architectural frameworks such as TOGAF and Zachman tend to consider commercial off-the-shelf (COTS) and open-source products, rather than complete, ready-made architectures.
There are five factors you should consider when deciding whether to buy, build, or tailor a product for your organization:
Control: This is where you have most leverage to differentiate in the market. You have virtually no control over the roadmap of a purchased solution and will likely be locked in for a period of time. When building a solution, however, you have total control—and with it, total responsibility! When tailoring a product, you start with a well-architected, robust, secure, and cost-efficient baseline and have total control to iterate as needed, or not. The speed with which clouds such as AWS iterate and deploy new features, services, and integrations means that native solutions can be readily extended to suit future requirements.
Cost: The vendor you purchase from may give you the advantage of their economies of scale, but more likely, their pricing will be based on run cost, plus the cost of the value they deliver and any intellectual property (IP) they develop. Building your own product is more expensive. You have to manage the product team, develop the IP, build the architecture, run the product, and support the product. When tailoring a product, you just pay for the run costs and support costs. The costs associated with security, performance, cost-efficiency, reliability, and operations are minimized.
Maintenance: Upgrades can be complicated and expensive, especially if you’ve modified a COTS solution. If you build a product, you have to manage OS versions and the life cycle of the entire software stack and its dependencies, as well as any bug fixes. When you tailor a product, OS versions and the software life cycle are generally managed for you, either with patch management (which automates OS version updates) or serverless solutions where you are not exposed to versions.
Opportunity cost: Buying solutions takes opportunity cost right out of the equation. You can continue to focus on your core profit-generating activities, but you lose the ability to differentiate except by solution configuration and integration with other systems. Building a solution can remove subject matter experts from key parts of the business for long periods of time. A tailored solution, however, can be deployed in minutes to hours with infrastructure as code.
Time to value: Buying a solution shrinks your time to value drastically. Your time investment is reduced to the time it takes you to evaluate solutions, decide on one, configure it, and launch. By contrast, building a version 1.0 of a well-functioning, user-friendly platform can take months. Solutions that you can tailor use modern frameworks, such as AWS Amplify, that integrate security services, scalability, and best-practice integration patterns. Additionally, serverless “glue” functions, such as AWS Lambda, allow reference architectures and solutions to be stacked and joined and high-level services to be stitched together seamlessly, keeping time to value low.
So, Tailoring Looks Good. Where Do You Start?
Today, there are a great many starting points. The links below will help you get started. Select one or more multiservice architecture patterns to create your own well-architected applications, avoid wasting time, and differentiate when doing so provides value.
So next time you’re contemplating whether to build or buy, ensure your thought process extends to “build vs. buy vs. tailor.”
PS. Here are some vetted solution libraries to whet your appetite:
- AWS Quick Starts—Quick Starts are built by Amazon Web Services (AWS) solutions architects and partners to help you deploy popular technologies on AWS, based on AWS best practices for security and high availability. These accelerators reduce hundreds of manual procedures into just a few steps so you can build your production environment quickly and start using it immediately.
- AWS Solutions Library—The AWS Solutions Library offers a collection of cloud-based solutions for dozens of technical and business problems, vetted for you by AWS. You can use patterns from AWS Solutions Constructs if you want to build your own well-architected application, explore our collection of AWS Solutions Reference Architectures as a reference for your project, browse the portfolio of AWS Solutions Implementations for applications that you can automatically deploy directly into your AWS account, or choose an AWS Solutions Consulting Offer if you want help from an AWS partner with deploying, integrating, and managing a solution.
- AWS Prescriptive Guidance—AWS Prescriptive Guidance provides time-tested strategies, guides, and patterns from AWS and AWS Partner Network (APN) partners to help accelerate your cloud migration, modernization, or optimization projects. These resources were developed by experts at AWS Professional Services, based on years of experience helping customers realize their business objectives on AWS.
- AWS GitHub repos with examples: AWS Samples & AWS GitHub
- Time to Rethink Build vs Buy
- Buy vs. Build Revisited: 3 Traps to Avoid
- Buy vs. Build Revisited, Part 2: Drawing the Line
- Buy vs. Build Revisited, Part 3: From Having Bought to Going to Build
- Buy vs. Build Revisited, Part 4: You Might Be Asking the Wrong Question
Simon Carter is an Enterprise Solution Architect at Amazon Web Services, working with some of Australia’s largest and most complex customers. Before joining AWS he was the CIO of a fintech startup and a healthtech startup, CEO of a data migration ISV, and consulted across transport/logistics, utilities and fintech. He has a Bachelor of Computer Science and Engineering from Monash.