Answers: <p>As far as I can read between the lines, you want your upper management to support you in introducing the 12-factor approach to your company's software development.</p>
  
  <p>In that respect, you do <em>not</em> want to explain each of the 12 factors to them. If they really were interested in that, then you could just send them the 12-factor website you have linked in your question - it already has 1-sentence summaries.</p>
  
  <p>I'll answer the question you wrote in the title:</p>
  
  <blockquote>
    <p>How to explain the Twelve Factors to non techy people?</p>
  </blockquote>
  
  <p>The Twelve Factors are not a soft "culture". It is a set of concrete, practical and pretty low-level techniques for solving problems relating to configuration management, deployment and high availability of applications. Instead of "culture" or "methodology", I would rather call it a pattern, or a kind of handbook for developers. It is obviously related to DevOps, cloud and similar buzzwords, but not necessarily so - you can also employ the techniques if you only have one developer doing his own thing, and even if there is no cloud or otherwise "modern" environment involved at all.</p>
  
  <p>It is not even necessary to involve management in the question whether to employ some or all of the techniques mentioned in the 12-factors. Many of them are simply best practices which everybody who develops ("service"-like) software will end up over the years.  This is pretty evident in the <em>I. Codebase</em>, <em>III. Config</em>, <em>XI. Logs</em>. No manager is required to give a green light to employ these practices.</p>
  
  <p>Other of the principles, namely <em>II. Dependencies</em>, <em>IV. Backing services</em>, <em>VI. Processes</em>, <em>VII. Port binding</em>, <em>VIII. Concurrency</em>, <em>IX. Disposability</em> are neatly combined into the keyword <em>"microservices"</em>. Don't explain to your management those specifics, but tell them that you are going to make a move from some presumably monolithic application architecture you had before to a microservice based one. On a management level, this can be sufficiently done with a graphical representation (one big blob of complex software on the one hand - several individual small blobs of software on the other hand). You can explain why the later can be better for the job at hand with nontechnical terms; every manager can understand the concepts of dividing a big, convoluted mass of code into smaller pieces that can be handled (and scaled) much easier.</p>
  
  <p>Your management will want to know what it costs and how long it takes. 12-factor tells you nothing at all about that. While there is a slight cost involved in some of the factors (e.g., establishing a central log stash), the cost is minor and will easily be caught up by savings later. Other costs may be the time needed for your developers to embrace some of the more tougher parts (i.e., II, VII, IX, depending on how much existing software you already have).</p>
  
  <p>Very important: it is pretty simple to work in an environment with a big monolithic application, and only add <em>new</em> stuff with the full 12-factor approach, or convert bits and pieces from the original software as you go. This  might be more sensible if you have time or money constraints.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-07T14:27:24.677Z
Answers: 2018-04-07T17:43:05.470Z
Answers: 2018-04-07T17:43:05.470Z
Answers: AnoE
Answers: <blockquote>
    <p><strong>I. Codebase</strong></p>
    
    <p>One codebase tracked in revision control, many deploys</p>
  </blockquote>
  
  <p>Version Control System (VCS)</p>
  
  <blockquote>
    <p><strong>II. Dependencies</strong></p>
    
    <p>Explicitly declare and isolate dependencies</p>
  </blockquote>
  
  <p>Use a package manager tool</p>
  
  <blockquote>
    <p><strong>III. Config</strong></p>
    
    <p>Store config in the environment</p>
  </blockquote>
  
  <p>Environment variables</p>
  
  <blockquote>
    <p><strong>IV. Backing services</strong></p>
    
    <p>Treat backing services as attached resources</p>
  </blockquote>
  
  <p>The code should not change if another service like a database changes.</p>
  
  <blockquote>
    <p><strong>V. Build, release, run</strong></p>
    
    <p>Strictly separate build and run stages</p>
  </blockquote>
  
  <ul>
  <li>unique release id</li>
  <li>a new release must be created for every change</li>
  </ul>
  
  <blockquote>
    <p><strong>VI. Processes</strong></p>
    
    <p>Execute the app as one or more stateless processes</p>
  </blockquote>
  
  <p>...</p>
  
  <blockquote>
    <p><strong>VII. Port binding</strong></p>
    
    <p>Export services via port binding</p>
  </blockquote>
  
  <p>...</p>
  
  <blockquote>
    <p><strong>VIII. Concurrency</strong></p>
    
    <p>Scale out via the process model</p>
  </blockquote>
  
  <p>...</p>
  
  <blockquote>
    <p><strong>IX. Disposability</strong></p>
    
    <p>Maximize robustness with fast startup and graceful shutdown</p>
  </blockquote>
  
  <p>Disposable. It does not matter whether services go down. The platform that consists of multiple services, is able to continue if services go down, e.g. data will not be lost. When the services are rebooted the platform can continue without data loss.</p>
  
  <blockquote>
    <p><strong>X. Dev/prod parity</strong></p>
    
    <p>Keep development, staging, and production as similar as possible</p>
  </blockquote>
  
  <ul>
  <li><p>Save time: one does not have to think, where does the acceptance database reside or where does this app exist in the testing environment. If one applies the same structure for systems in dev, test and acc then one does not have to think every time when such an environment is used and this will save time</p></li>
  <li><p>Decrease number of bugs: if a development environment is similar to production, the number of bugs will be decreased as there is a higher chance that the bugs will be solved in the dev phase proactively</p></li>
  </ul>
  
  <blockquote>
    <p><strong>XI. Logs</strong></p>
    
    <p>Treat logs as event streams</p>
  </blockquote>
  
  <ul>
  <li>stdout</li>
  <li>store all logs in a log manager like splunk</li>
  </ul>
  
  <blockquote>
    <p><strong>XII. Admin processes</strong></p>
    
    <p>Run admin/management tasks as one-off processes</p>
  </blockquote>
  
  <p>...</p>
  
  <hr>
  
  <p><strong>Discussion</strong></p>
  
  <blockquote>
    <p>we are a startup of 6 devs our boss is a former sportsman</p>
  </blockquote>
  
  <p>...</p>
  
  <blockquote>
    <p><strong>Who should read this document?</strong></p>
    
    <p>Any developer building applications which run as a service. Ops
    engineers who deploy or manage such applications.</p>
  </blockquote>
  
  <p>...</p>
  
  <p><a href="https://en.wikipedia.org/wiki/Software_rot" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Software_rot</a></p>
  
  <blockquote>
    <p>slow deterioration of software over time that will eventually lead to
    it becoming faulty [or] unusable" and, importantly, that "the software
    does not actually decay, but rather suffers from a lack of being
    updated with respect to the changing environment in which it resides.</p>
  </blockquote>
  
  <p>...</p>
  
  <p><strong>Manager:</strong> Why do you want to apply 12factor?</p>
  
  <p><strong>Team:</strong> The 12factor prevents software rot, i.e. more bugs, unstable software resulting in less customer satisfaction, less revenue.</p>
  
  <hr>
  
  <p><strong>Conclusion</strong></p>
  
  <p>Instead of explaining the 12factor it is better to explain what will happen if the 12factor is not applied, i.e. software rot. The 12factor is for Devs and Ops people, not for managers.</p>
  
  <hr>
  
  <p><strong>References</strong></p>
  
  <ol>
  <li><a href="http://www.clearlytech.com/2014/01/04/12-factor-apps-plain-english/" rel="nofollow noreferrer">http://www.clearlytech.com/2014/01/04/12-factor-apps-plain-english/</a></li>
  <li><a href="https://12factor.net/" rel="nofollow noreferrer">https://12factor.net/</a></li>
  <li><a href="https://thenewstack.io/12-factor-app-streamlines-application-development/" rel="nofollow noreferrer">https://thenewstack.io/12-factor-app-streamlines-application-development/</a></li>
  </ol>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-04T12:52:25.717Z
Answers: Thank you for those links .. I am starting to have a number of ideas to discuss with my management .
Answers: storm
Answers: CC BY-SA 3.0
Answers: 2018-04-01T18:56:12.400Z
Answers: 2018-04-07T06:27:27.820Z
Answers: 2018-04-07T06:27:27.820Z
Answers: 030
Body: <p><a href="https://12factor.net" rel="nofollow noreferrer">The Twelve Factors</a> is a sort of manifesto seen as a road-map for developers to follow when building modern web-based applications.</p>
  <p>How would you explain each of the 12 factors in less than three sentences to random people?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-28T15:20:04.403Z
Comments: If you have questions about specific parts why not, but the manifesto is already quite simple and readable with graphics included.
Comments: Michael Pereira
Comments: CC BY-SA 3.0
Comments: 2018-03-28T16:26:14.153Z
Comments: While I agree that the manifesto is simple and well explained , I think that non techy people won't be able to follow and assimilate it. my question aim to trivialize those essential 12 practices.
Comments: storm
Comments: CC BY-SA 3.0
Comments: 2018-03-28T16:40:01.577Z
Comments: Did you try to explain it to a non tech person? What impediments did you encounter?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-28T17:16:15.673Z
Comments: I did, you know a non-tech manager don't really understand techie argot for him it's just another new trend and unnecessary budget allocation.
Comments: storm
Comments: CC BY-SA 3.0
Comments: 2018-03-28T19:31:03.573Z
Comments: Are you trying to convince someone why you want to follow this methodology, or are they asking you to explain it like i'm 5?
Comments: Preston Martin
Comments: CC BY-SA 3.0
Comments: 2018-03-30T06:59:39.803Z
Comments: @Nakilon : I agree , but I still think they would consider change if could bring more benefits .. but first they should understand it .. we are a startup of 6 devs our boss is a former sportsman
Comments: storm
Comments: CC BY-SA 3.0
Comments: 2018-04-07T08:51:05.150Z
Comments: I feel this question could be better if the title skipped the "5 year old child" reference. At first I thought you were actually meaning it, but then you said they have computer jargon... why not clearly state what you want? Do you mean managers? Or programmers that didn't "buy" the 12 factors yet?
Comments: AnoE
Comments: CC BY-SA 3.0
Comments: 2018-04-07T09:37:42.790Z
Comments: @AnoE: you're right
Comments: storm
Comments: CC BY-SA 3.0
Comments: 2018-04-07T09:43:45.647Z
Comments: a side question - *why* do you need to explain that to the management? *what* do you want to achieve?
Comments: Ta Mu
Tags: <culture><methodology>
Title: How to explain the Twelve Factors to non techy people?
UserDisplayName: storm
ThreadText: # How to explain the Twelve Factors to non techy people?
  
  (Asked by: username_0 on 2018-03-28)
  
  [The Twelve Factors](https://12factor.net) is a sort of manifesto seen as a road-map for developers to follow when building modern web-based applications.
  
  How would you explain each of the 12 factors in less than three sentences to random people?
  
  **Tags:** culture, methodology
  
  > **Comments:**
  > **username_1**: If you have questions about specific parts why not, but the manifesto is already quite simple and readable with graphics included.  
  > **username_0**: While I agree that the manifesto is simple and well explained , I think that non techy people won't be able to follow and assimilate it. my question aim to trivialize those essential 12 practices.  
  > **username_2**: Did you try to explain it to a non tech person? What impediments did you encounter?  
  > **username_0**: I did, you know a non-tech manager don't really understand techie argot for him it's just another new trend and unnecessary budget allocation.  
  > **username_3**: Are you trying to convince someone why you want to follow this methodology, or are they asking you to explain it like i'm 5?  
  > **username_0**: @Nakilon : I agree , but I still think they would consider change if could bring more benefits .. but first they should understand it .. we are a startup of 6 devs our boss is a former sportsman  
  > **username_4**: I feel this question could be better if the title skipped the "5 year old child" reference. At first I thought you were actually meaning it, but then you said they have computer jargon... why not clearly state what you want? Do you mean managers? Or programmers that didn't "buy" the 12 factors yet?  
  > **username_0**: @username_4: you're right  
  > **username_5**: a side question - *why* do you need to explain that to the management? *what* do you want to achieve?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_4 on 2018-04-07. Score: 6 | Accepted answer
  
  As far as I can read between the lines, you want your upper management to support you in introducing the 12-factor approach to your company's software development.
  
  In that respect, you do *not* want to explain each of the 12 factors to them. If they really were interested in that, then you could just send them the 12-factor website you have linked in your question - it already has 1-sentence summaries.
  
  I'll answer the question you wrote in the title:
  
  > How to explain the Twelve Factors to non techy people?
  
  The Twelve Factors are not a soft "culture". It is a set of concrete, practical and pretty low-level techniques for solving problems relating to configuration management, deployment and high availability of applications. Instead of "culture" or "methodology", I would rather call it a pattern, or a kind of handbook for developers. It is obviously related to DevOps, cloud and similar buzzwords, but not necessarily so - you can also employ the techniques if you only have one developer doing his own thing, and even if there is no cloud or otherwise "modern" environment involved at all.
  
  It is not even necessary to involve management in the question whether to employ some or all of the techniques mentioned in the 12-factors. Many of them are simply best practices which everybody who develops ("service"-like) software will end up over the years. This is pretty evident in the *I. Codebase*, *III. Config*, *XI. Logs*. No manager is required to give a green light to employ these practices.
  
  Other of the principles, namely *II. Dependencies*, *IV. Backing services*, *VI. Processes*, *VII. Port binding*, *VIII. Concurrency*, *IX. Disposability* are neatly combined into the keyword *"microservices"*. Don't explain to your management those specifics, but tell them that you are going to make a move from some presumably monolithic application architecture you had before to a microservice based one. On a management level, this can be sufficiently done with a graphical representation (one big blob of complex software on the one hand - several individual small blobs of software on the other hand). You can explain why the later can be better for the job at hand with nontechnical terms; every manager can understand the concepts of dividing a big, convoluted mass of code into smaller pieces that can be handled (and scaled) much easier.
  
  Your management will want to know what it costs and how long it takes. 12-factor tells you nothing at all about that. While there is a slight cost involved in some of the factors (e.g., establishing a central log stash), the cost is minor and will easily be caught up by savings later. Other costs may be the time needed for your developers to embrace some of the more tougher parts (i.e., II, VII, IX, depending on how much existing software you already have).
  
  Very important: it is pretty simple to work in an environment with a big monolithic application, and only add *new* stuff with the full 12-factor approach, or convert bits and pieces from the original software as you go. This might be more sensible if you have time or money constraints.
  
  
  ---
  
  ### Answer by username_2 on 2018-04-01. Score: 4
  
  > **I. Codebase**
  >
  > One codebase tracked in revision control, many deploys
  
  Version Control System (VCS)
  
  > **II. Dependencies**
  >
  > Explicitly declare and isolate dependencies
  
  Use a package manager tool
  
  > **III. Config**
  >
  > Store config in the environment
  
  Environment variables
  
  > **IV. Backing services**
  >
  > Treat backing services as attached resources
  
  The code should not change if another service like a database changes.
  
  > **V. Build, release, run**
  >
  > Strictly separate build and run stages
  
  * unique release id
  * a new release must be created for every change
  
  > **VI. Processes**
  >
  > Execute the app as one or more stateless processes
  
  ...
  
  > **VII. Port binding**
  >
  > Export services via port binding
  
  ...
  
  > **VIII. Concurrency**
  >
  > Scale out via the process model
  
  ...
  
  > **IX. Disposability**
  >
  > Maximize robustness with fast startup and graceful shutdown
  
  Disposable. It does not matter whether services go down. The platform that consists of multiple services, is able to continue if services go down, e.g. data will not be lost. When the services are rebooted the platform can continue without data loss.
  
  > **X. Dev/prod parity**
  >
  > Keep development, staging, and production as similar as possible
  
  * Save time: one does not have to think, where does the acceptance database reside or where does this app exist in the testing environment. If one applies the same structure for systems in dev, test and acc then one does not have to think every time when such an environment is used and this will save time
  * Decrease number of bugs: if a development environment is similar to production, the number of bugs will be decreased as there is a higher chance that the bugs will be solved in the dev phase proactively
  
  > **XI. Logs**
  >
  > Treat logs as event streams
  
  * stdout
  * store all logs in a log manager like splunk
  
  > **XII. Admin processes**
  >
  > Run admin/management tasks as one-off processes
  
  ...
  
  ---
  
  **Discussion**
  
  > we are a startup of 6 devs our boss is a former sportsman
  
  ...
  
  > **Who should read this document?**
  >
  > Any developer building applications which run as a service. Ops
  > engineers who deploy or manage such applications.
  
  ...
  
  <https://en.wikipedia.org/wiki/Software_rot>
  
  > slow deterioration of software over time that will eventually lead to
  > it becoming faulty [or] unusable" and, importantly, that "the software
  > does not actually decay, but rather suffers from a lack of being
  > updated with respect to the changing environment in which it resides.
  
  ...
  
  **Manager:** Why do you want to apply 12factor?
  
  **Team:** The 12factor prevents software rot, i.e. more bugs, unstable software resulting in less customer satisfaction, less revenue.
  
  ---
  
  **Conclusion**
  
  Instead of explaining the 12factor it is better to explain what will happen if the 12factor is not applied, i.e. software rot. The 12factor is for Devs and Ops people, not for managers.
  
  ---
  
  **References**
  
  1. <http://www.clearlytech.com/2014/01/04/12-factor-apps-plain-english/>
  2. <https://12factor.net/>
  3. <https://thenewstack.io/12-factor-app-streamlines-application-development/>
  
  > **Comments:**
  > **username_0**: Thank you for those links .. I am starting to have a number of ideas to discuss with my management .  
  
  ---
  
  