I have been fortunate over the last couple of months to help found a new working group as part of the FINOS Foundation Special Interest Group - DevOps Automation, called "Architecture as Code".
To quote from our homepage:
Our collective focus lies in the progressive practice of codifying the logical design and behavior of software systems. The concept of "Architecture as Code" (AasC) aims to devise and manage software architecture via a readable and version-controlled codebase, fostering a robust understanding, efficient development, and seamless maintenance of complex software architectures.
So what does this mean?
You can see the original proposal from back in May here. The pertinent section is:
Whilst most organisations have strong, well-defined processes and controls around the development and deployment of code, design and architecture tends to encompass a wide variety of techniques and disparate practices even within a single organisation, with no common industry standard for describing system architectures. Most commonly architecture is captured in a combination of non-interrogatable formats which tend to go stale as system state over time drifts from the agreed architecture.
Whilst there are tools available to help us document the visual aspects of our architectures in a more uniform and machine readble format, such as Structurizr, C4 and PlantUML, these are still very much parts of adhoc processes and only solve the ability to capture the diagrams we produce as code, not the ability to codify the architecture itself.
What this means is that whilst as a heavily regulated industry we have clear policy, guidance and structure in place to ensure that due thought and attention is put upon the practice of Design & Architecture, we have no way of ensuring that the design and architecture we have agreed is actually what is implemented or how the system may drift from that original design over time.
Reuse
We frequently look to provide pre-approved system designs that are known as good solutions to common problems and these themselves are documented and made available through organisations as artefacts to be manually followed.
But again there seems to be a missed opportunity to take these pre-approved designs or even portions of designs and be able to reuse them in a more automated fashion, going from zero to production deployed code in a matter of hours or days rather than weeks or months.
Infrastructure as Code
One thing I'm keen to point out, because when many people hear Architecture as Code they immediately think of Infrastructure as Code, these are not the same thing.
Architecture as Code != Infrastructure as Code
Infrastructure as Code is a well established and served part of the DevOps toolkit, it allows us to automate and provide greater levels of consistency and repeatability in the deployment of our infrastructure, but it does not help us with the design of our systems.
Architecture as Code, if successful, will allow us to capture the foundational technical decisions and architectural characteristics of our systems, providing the blueprint for how our systems should be built and enable us to track their evolution over time.
Come and join the Community
If you're interested in getting involved to help shape the future of Architecture as Code, please come and join us in the "Architecture as Code" working group.
You can jump straight into the working group issues here.