snippetMinor
How to explain the Twelve Factors to non techy people?
Viewed 0 times
factorsthenontechytwelvepeoplehowexplain
Problem
The Twelve Factors 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?
How would you explain each of the 12 factors in less than three sentences to random people?
Solution
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.
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.
Context
StackExchange DevOps Q#3758, answer score: 6
Revisions (0)
No revisions yet.