问题描述
想要向非技术人员解释十二要素的概念，但不确定如何用简洁的语言解释每个要素。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
首先，需要明确的是，你不需要向管理层解释十二要素的每个细节。如果他们真的对此感兴趣，你可以直接将十二要素的官方网站链接发送给他们，该网站已经提供了每个要素的一句话总结。
以下是你在标题中提出的问题的答案：
十二要素不是一种软性的“文化”。它是一套具体、实用且相当低级的技术，用于解决与配置管理、部署和应用程序高可用性相关的问题。与其称之为“文化”或“方法论”，我更愿意将其称为一种模式，或者一种开发人员手册。它显然与DevOps、云和类似的热门词汇有关，但并不一定如此——即使只有一个开发人员在做自己的事情，甚至根本没有涉及云或其他“现代”环境，你也可以使用这些技术。
在是否采用十二要素中，甚至不需要涉及管理层的问题。其中许多要素只是每个开发（“服务”型）软件开发人员多年来的最佳实践。这在“I. Codebase”、“III. Config”和“XI. Logs”中是非常明显的。没有必要让管理层批准采用这些实践。
其他原则，即“II. Dependencies”、“IV. Backing services”、“VI. Processes”、“VII. Port binding”、“VIII. Concurrency”和“IX. Disposability”，可以简洁地总结为“微服务”。不需要向管理层解释这些具体细节，而是告诉他们你将从之前的假定上的单体应用架构转向基于微服务的架构。在管理层层面上，这可以通过图形表示来完成（一个复杂软件的大块 – 几个单独的小软件块）。你可以用非技术术语解释为什么后者对当前的工作更好，即将一个庞大、复杂的代码块分割成更小的部分，这样更容易处理（和扩展）。
你的管理层想知道这需要多少成本和时间。十二要素对此一无所知。虽然某些要素（例如，建立一个中央日志存储）确实需要一些成本，但成本很小，后期的节省将很容易弥补。其他成本可能是开发人员需要花费的时间来掌握一些更困难的部分（即，II、VII、IX，取决于你已经拥有多少现有软件）。
非常重要的是，在一个大型的单体应用程序环境中工作并且只添加新的东西时，完全采用十二要素方法，或者在进行转换时逐步从原始软件中转换出一些部分，这是非常简单的。如果你有时间或资金限制，这可能更明智。
方案2
另一种方法是解释如果不应用十二要素会发生什么，即软件腐败。十二要素是为开发人员和运维人员设计的，而不是为管理层设计的。
相比解释十二要素，更好的方法是解释如果不应用十二要素会发生什么，即软件腐败。十二要素是为开发人员和运维人员设计的，而不是为管理层设计的。
你可以告诉管理层，如果不采用十二要素，软件将会腐败，即出现更多的错误、不稳定的软件，导致客户满意度降低，收入减少。