12 Factors App: How can it help with Architectural Audits?

Reading Time: 3 minutes

If you are writing software applications for a while that can be in the category of a SaaS application and has to scale and work in a distributed environment, you might face or participate in Design or Architectural Audits of your applications. If you want to conduct or simply Ice-breaking with the process, you would need homework before you proceed. If you don’t have a well-written template that helps reduce the time taken the process or you want to know how to start with the review, this blog can help plan it better.

12 Factors App

It is a set of guiding rules which can be used to govern and audit the applications which we are writing to be competitive SaaS applications. These are very detailed and well explained on The Twelve-Factor App page. My intention in this blog is to use it as a reference and build a set of questions that we can use to ice-break the Audit process. All questions might not be applicable to a particular service that you have written but the list of questions is not exhaustive. You can also add your own version to it if it makes more sense. The answer to these questions can be useful in collecting general violations of each of the factors which we can collect.

How to use This Questionnaire?

The below tables contain the link to explanations of the 12 Factor App guidelines. For e.g. You can click on the hyperlink of the I. Codebase and come back to the question. By looking at the answer to each of these questions, you would be able to find if any of the guidelines are applicable in your scenario and if applicable, if the service is following the principle or not.

I. Codebase
Are all services/microservices separated from each other in source control?
Which branch is considered from release?
Is a single branch deployed across all env?
Code Base should be separated for each service
II. Dependencies
How build is being managed?
Is Fat Jar being deployed to environments?
Does the system depend on any existing environments like java, JRE is assumed on the target system?
Is it using any containerization tool?
Dependencies should not be assumed
III. Config
How configuration is maintained?
Is it maintained centrally?
Is any hardcode configuration exists like constants in the code?
Are they being passed using environment variables?
Configurations should not be hardcoded
IV. Backing services
Are all databases, and message systems configured and have cloud-based access?
Do we need to configure the apps differently for production and dev environments?
What are all the backing services being used in the service?
Can we replace backing services with another product? e.g. replacing MySQL with another RDBMS product without changing the code of the application?
Backed Flexible?
V. Build, release, run
Are all services part of a CI pipeline? Is it automated?
How deployment is triggered? Is it scripted and source controlled for each environment?
What is the release frequency?
What is the revert policy in case of failures? Blue/Green enabled?
Build, Release, Run should avoid inconsistencies

What next?

So far, I have only listed questions to the first five rules of the 12 Factor App. In the upcoming part of the continuation, I will list more questions as applicable covering other aspects of the application. You are welcome to add more questions in the comments or comments on the existing ones if you find them relevant. Thanks for Reading!!

Written by 

Manish Mishra is Lead Software Consultant, with experience of more than 7 years. His primary development technology was Java. He fell for Scala language and found it innovative and interesting language and fun to code with. He has also co-authored a journal paper titled: Economy Driven Real Time Deadline Based Scheduling. His interests include: learning cloud computing products and technologies, algorithm designing. He finds Books and literature as favorite companions in solitude. He likes stories, Spiritual Fictions and Time Traveling fictions as his favorites.