For any new software project, there are many (sometimes conflicting) ways to architect the product. In fact, one of the most important jobs of the architect is to take into consideration conflicting design patterns and possibilities and choose an architecture that best solves the problem.
Historically delivery wasn’t a key consideration in software product design. Actually that is true for many products, not just software. That is a problem since delivery is a critical component in the success of any product – and should be taken into consideration at every stage of product creation.
Here is a great example of design for delivery:
Design for delivery is a critical part of the DevOps shift left paradigm. We like to add “think right” to the equation because shift left isn’t enough – the whole organization needs to include the ability to easily deliver the product as part of product design and implementation.