Build-to-ship vs build-to-operate

When discussing software delivery activities, there is often ambiguity when defining the types of software that is delivered, and hence, the delivery pipeline activities that need to be done. Is it embedded? OTS? Enterprise software? Packaged software? Web apps? mobile back-end? Mobile apps (client side)? OS and drivers? Web services? Internet services?

In reality, from a software delivery activity perspective, there are basically two types of software. That software which is built and then shipped, and that software which is built and then operated: built-to-ship (BTS); and built-to-operate (BTO), respectively.

BTS software includes software which will be installed into the firmware of a device (embedded), including mobile phones. It also includes software which will be put onto a CD/DVD and shipped in a box, even software which will be uploaded, as an executable/installable to a website (such as an app store). These are all similar software delivery vehicles which require delivering a “final” software artifact to some form of manufacturing, before the software reaches it’s final destination and can provide value to the customer.

BTO software, on the other hand, all needs to be installed to a server or set of servers and then “operated” (as in operations) in order for it to provide its value to the customer. This includes web applications (including their simplest form, static websites), mobile back-end servers, Enterprise applications such as SAP, web services, SaaS offerings, etc. All of these forms of software require an installation (deployment) to one or more back-end servers, and some amount of orchestration across those servers to get them there. All BTO software eventually will need to be tracked and managed once in production (what exactly was deployed to where) including potential phased releases such as canary releases, A/B releases, dark releases, etc, unlike BTS software, who’s release is basically done once it is handed to manufacturing.

Does this distinction effect the earlier stages of the software delivery process? Tune in next time for that discussion.

Dan Gordon

Dan Gordon

Dan Gordon is a Product Manager at Electric Cloud with more than twenty years of experience in the IT software industry. He brings a focus on helping companies build the best tools to help development and IT organizations achieve continuous delivery of quality software. Previously, Dan served as product manager and systems architect for the enterprise IT automation software business within HP Software. He has also held managing and systems engineering roles at Opsware, and been a developer, a network administrator, and a security administrator at Sun Microsystems. Dan is passionate about enabling all software companies (and all companies are software companies) to deliver value to their customers at high velocity.
Dan Gordon

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe

Subscribe via RSS
Click here to subscribe to the Electric Cloud Blog via RSS

Subscribe to Blog via Email
Enter your email address to subscribe to this blog and receive notifications of new posts by email.