One of the main problems with modern architecture is the ability to quickly review an application and decide if it requires further inspection.

I remember arriving in Perú after a long absence and being asked to press a button that turned a traffic light red or green to determine if you can continue on your way or be detoured and sent through a different line where an inspector will go through your luggage. While not random, the architecture review process done by the ARB (Architecture Review Board) should have a red/green light system that allows applications to just continue without delay because they match an already approved template, or be routed for further inspection.
The problem is not in the desire, but in the execution, since there is no easy and accurate way to compare an application blueprint with a template because there are no standards for recording an application blueprint, or application templates.
Gathering and constructing the blueprint very early in the process will be key for sound architecture discipline, this is probably the area where the ARB will benefit the most, when application owners, architects, and developers are all working out of the same living documents to describe, review and run the application.

Application digital blueprint

An application digital blueprint is a human and computer-readable and actionable description of the application architecture. This living document should accompany the application throughout its lifecycle, and thus, should be versioned and kept up-to-date with the evolution of the application.

Blueprint’s ability to stay current

As with any blueprint, there is the danger of implementors deviating from the original blueprint and also later improvements and additions not originally reflected in the original blueprint, and thus the importance of the blueprint being computer actionable. In application architecture nirvana, and there is nothing today that prevent us from doing this except an actual tool, we should be able to dynamically generate the deployment template (i.e. helm chart, ansible, etc.) from the blueprint, forcing the application maintainers to update the blueprint when architectural changes are required. Also, we should be able to run scheduled audits of the running application and report on any deviations. All architectural diagrams (e.g. C4 model, archimate) should be just different renditions of the blueprint.

Current state of things

The industry is lacking a robust and consistent application digital blueprint model and tooling. Some of the previous efforts fell short because the implementation would easily stray away from the design. Nowadays, when software-defined-everything is possible, we should retake this goal of producing a single source of truth for the architecture that is human and computer-readable and actionable.
Maybe a new version of the TOGAF standards, post cloud and DevOps, would be the necessary kick-off.
None of this is possible as long as we keep describing application architecture in word or excel documents and drawing architectural diagrams by hand.

Templates

I will continue describing a template as if a meaningful model already exists for the blueprint definition with the hopes that it will help someone, someday think and derive from its ideas.
Templates are configuration descriptions that abstract the subject to a simple red/green light outcome: Pre-approved or Needs Inspection.
Templates are made of a series of simple or hierarchical question/answer pairs with a human and computer-readable and actionable outcome.

There are three types of templates: Application, Requirements, and Technology. Technology and Requirement templates are the building blocks from which Application templates are made.

Application templates

An application template is made of very specific answers to the templates. You might think of an Application template like a glorified version of the old applications stacks (LAMP, LEMP, MEAN, etc.), but, different than an application stack which was only concerned with the technology deployed into the server, an Application template goes above and beyond that to also have an interest in how the application is developed, deployed, what kind of data, users, processing, etc. We could also call it a Modern Application Stack, but I just prefer to use a different name altogether and avoid confusion.

Requirement templates

Requirement templates describe unnegotiable demands of the application and cover the following areas

• Data sensitivity
• Application IP
• Visibility
• User base
• Computing
• Availability

Technology templates

Technology templates describe current or promised implementations and cover the following domains:

• Infrastructure
  • Storage
  • Networking
  • Database
• Security
  • Authentication/authorization/RBAC
  • Scanning
• Operations
  • Monitoring and alerting
  • Scalability
  • Server application technology
  • Client application technology
  • High availability
  • Disaster Recovery
• Architecture SDLC
  • Monolithic/Loosely coupled microservices
  • Virtualization/Containerization
  • Integration pipeline
  • Deployment maturity