How to explain the Twelve Factors to non techy people?

Question

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?

Answer 1

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 2

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/