Introduction to Architecture as Code

All courses / Architecture as Code / Module 1 / Chapter 1

Learning objectives

After the lesson the participant can:

• Define Architecture as Code and state what its scope covers beyond infrastructure.
• Explain why large microservice estates are the tipping point for adopting the practice.
• Describe slideware syndrome and architectural entropy and how fast delivery amplifies them.
• Apply the three design criteria of adoptability, extensibility and productivity to a tooling proposal.

Key concepts

Architecture as Code

The practice of describing, version-controlling and automating the entire system architecture through machine-readable code. It produces live, executable specifications that stay synchronised with the running estate and covers application components, integration patterns, data architecture, infrastructure and organisational processes.

Slideware syndrome

The chapter's name for architecture practised through expansive decks, static diagrams and committee reviews that rapidly drift away from operational reality.

Architectural entropy

The gradual loss of coherence between documented intent and implemented systems that accumulates when architectural artefacts go unchecked. It erodes trust and leaves teams to improvise workarounds that bypass the guardrails.

Adoptability, extensibility, productivity

The three design criteria by which the book evaluates practices and tooling: teams can adopt it without wholesale tooling upheaval, the platform can evolve with the landscape, and codification gives faster feedback and fewer approval bottlenecks.

The interconnected flow

The ecosystem in which Requirements as Code, Compliance as Code, Documentation as Code, Design as Code, coding, CI/CD, Infrastructure as Code and Management as Code reinforce and validate one another through feedback loops, rather than forming a linear process.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Teaching plan

Discussion

1. Where in your organisation do manual governance checkpoints become bottlenecks that teams circumvent, and what happens to architectural intent when they do?
2. The chapter includes organisational processes in the scope of Architecture as Code. What would it mean in practice to codify one of yours?
3. Which of the three design criteria is hardest to meet in your organisation today, and why?

Written exercise

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

1. According to the chapter, what is the tipping point for most organisations adopting Architecture as Code?

   1. The licence cost of commercial diagramming and modelling tools
   2. The complexity created by large-scale microservice estates
   3. A regulatory requirement to keep architecture in version control
   4. The retirement of experienced enterprise architects
   Show the answer

   B. The complexity created by large-scale microservice estates
   The chapter names microservice complexity as the primary driver: each additional service adds APIs, contracts and deployment topologies that outpace what static diagrams or isolated configuration repositories can keep synchronised.

2. How does the chapter describe the specifications that Architecture as Code produces?

   1. Aspirational design artefacts that guide delivery teams through each quarterly planning cycle
   2. Annual reference models approved by an architecture board
   3. Generated source code that replaces manual implementation
   4. Live, executable specifications synchronised with the running estate
   Show the answer

   D. Live, executable specifications synchronised with the running estate
   The definition contrasts live, executable specifications that stay synchronised with the running estate against design artefacts that linger as aspirations.

3. Which three design criteria shape how the book evaluates Architecture as Code practices and tooling?

   1. Adoptability, extensibility and productivity
   2. Scalability, availability and security
   3. Traceability, immutability and testability
   4. Simplicity, portability and affordability
   Show the answer

   A. Adoptability, extensibility and productivity
   The chapter states that adoptability, extensibility and productivity are the three design criteria, and gives each a subsection of its own.