FINOS CALM and the evolution of the architect role: from diagram owner to architecture product manager

FINOS CALM and the evolution of the architect role

CALM is already credited with supporting “well in excess of 2,000 application deployments” inside several firms, with pattern-based security approvals baked into the delivery flow (Matthew Bain on CALM v1.0). That number matters because it signals a real shift in the architect’s job. Architecture stops being a quarterly review ritual and turns into a daily control surface teams hit every time they ship.

CTOs should care because CALM changes the unit of scale. You don’t scale architecture by hiring more architects. You scale architecture by shipping patterns, controls, and tooling that teams can run in CI.

What is FINOS CALM (Common Architecture Language Model) and why CTOs should care

FINOS CALM, the Common Architecture Language Model, is an open-source specification for “defining software architectures” in a format machines and humans can read (FINOS CALM docs). CALM sits under the Architecture as Code community in FINOS, which is exactly where you want this work to live if you operate in regulated, high-scale environments.

CALM models architecture with a small set of primitives. The DevOps.com write-up describes three core components:

• Nodes: services, databases, networks, clusters
• Relationships: how components connect and exchange data
• Metadata: context, constraints, and tags for governance

The same article quotes Matthew Bain on the intent: CALM “translates the design of an application into code,” keeps diagrams updated, and applies controls along the way (DevOps.com on CALM).

The surrounding tooling matters as much as the schema. QCon London 2025 calls out CALM CLI, CalmHub, and a visualizer, plus validation against predefined patterns and controls for secure API connectivity (QCon London 2025 session abstract).

Here’s the framing I use with exec teams: CALM is GitOps for architecture intent. The artifact lives in version control, and pipelines can test it.

How Architecture as Code changes the architect role (and what replaces the old model)

Most CTOs I talk to have the same complaint: architecture review boards don’t scale past 30 to 50 teams. The board turns into a queue, and teams start routing around it.

CALM pushes architects into a different operating model. Architects stop acting like diagram editors and start acting like product owners for architecture patterns.

The old architect model breaks at scale

The classic model looks like this:

• A team writes a design doc.
• An architect reviews it in a meeting.
• Security and risk teams add comments.
• The team ships something close enough.

That flow breaks in two predictable cases.

Microservices sprawl is the first. A “simple” change touches 8 services, 3 data stores, and 2 gateways. A static diagram is stale before the sprint ends.

Regulated delivery is the second. A bank can’t wait six weeks for a network segmentation decision. Teams ship exceptions to keep moving, and the exception quietly becomes the standard.

The new architect model: architecture product manager

CALM makes a different job possible. Architects can ship reusable patterns and controls, then let teams self-serve.

A practical definition helps align the org.

Quotable definition: An enterprise architect is a product manager for constraints. The “product” is a set of patterns, controls, and guardrails that teams can adopt without a meeting.

That definition changes what “good” looks like.

• Good architects write fewer bespoke designs.
• Good architects publish more patterns.
• Good architects measure adoption and drift.

The QCon talk describes “Architecture as Code with CALM” that generates and validates architectures against patterns, keeping security compliance inside the pipeline (QCon London 2025).

Architects now design for AI, not just for services

The InfoQ 2025 architecture trends report calls out RAG as a common technique to improve LLM results, and it notes that architects are adapting systems so data can be consumed for RAG use cases (InfoQ Architecture Trends 2025).

That trend hits the architect role in two ways:

• Architects need to model data lineage and access paths, not just service calls.
• Architects need to encode non-functional rules for AI systems, like prompt injection boundaries, tool access, and audit trails.

A CALM pattern can carry those rules as controls, then validate them on every change.

How CALM fits into secure API connectivity, Zero Trust, and AI threat models

CALM adoption often starts with APIs because APIs create visible pain fast. Teams need a gateway, mTLS, rate limits, and network policy. Security teams need evidence, not a slide deck.

The QCon London 2025 abstract describes a demo flow that starts with an insecure deployment, applies a threat model, then uses controls to enforce Zero Trust and network segmentation in Kubernetes (QCon London 2025).

The Morgan Stanley and FINOS talk on “tool chaining attacks” makes the AI angle explicit. The description ties CALM patterns and controls to microsegmentation and other non-functional requirements during deployment (CALM talk description).

A concrete scenario: internal API platform in a regulated business

Picture a firm with 120 product teams and a shared Kubernetes platform.

• Teams deploy 20 to 40 services per quarter.
• Security requires mTLS between namespaces.
• Risk requires an inventory of external egress.

Without Architecture as Code, the platform team ends up writing wiki pages and chasing exceptions.

With CALM, the platform team can publish:

• A “service behind gateway” pattern with required gateway, auth, and rate limits.
• A “data store access” control that blocks direct access from public workloads.
• A “no public egress” decorator that flags outbound internet routes.

The GitHub issue on decorators shows where the model is heading. Decorators add cross-cutting context without bloating the core architecture document, and they can live in separate files referenced by JSON refs (FINOS issue #1864).

That split matters for org design. Security teams can own decorators and controls. Product teams can own the core architecture file.

CALM plus LLMs changes documentation work

FINOS demos show people using an LLM to help author CALM JSON, even when they don’t have the schema memorized (Zero JSON demo). The point isn’t “LLMs write architecture.” The point is that CALM gives LLMs a strict target format.

A CTO can use that pairing to cut the cost of keeping architecture current. The catch is quality control. Architects still need to review semantics, not syntax.

Enterprise implications: why CALM changes governance, delivery speed, and org design

1. Architecture review becomes a pipeline step, not a calendar event. Pattern validation can run in CI, so teams get feedback in minutes. DevOps.com quotes a contributor calling faster security validation “a no-brainer,” tied directly to moving faster to production (DevOps.com on CALM).

2. Security and compliance teams can ship controls like code. Controls stop living in PDFs. Controls become testable artifacts. The JSON Schema conference deck shows controls and observability schemas as first-class objects, with thresholds, retention, and sources like Prometheus (JSON Schema deck).

3. Platform teams gain a new contract with product teams. A platform team can publish patterns, then measure adoption and drift. That changes the conversation from “please follow standards” to “your build failed because the pattern check failed.”

4. AI architecture becomes governable at scale. InfoQ calls out RAG and AI-assisted development as mainstream trends architects must plan for (InfoQ Architecture Trends 2025). CALM gives you a place to encode AI data access rules, tool permissions, and audit requirements.

CTO recommendations: how to adopt CALM and evolve your architecture team

I’ve seen Architecture as Code fail when leaders treat it like a documentation project. CALM works when leaders treat it like a product and a change program.

Immediate actions (next 30 days)

1. Pick one high-friction path, then model it in CALM. Start with “service to service over mTLS” or “service behind API gateway.” Use the QCon secure API connectivity flow as your reference path (QCon London 2025).

2. Create a thin pattern catalog with 3 patterns max. Keep names boring and clear. Examples: “Public API,” “Internal API,” “Batch job.”

3. Wire validation into CI for one repo. Treat the first pipeline as a pilot. Measure cycle time from PR open to approval.

4. Run one architecture drift review using the visualizer or CalmHub concepts. Look for missing gateways, missing mTLS, and unknown egress.

If you want a place to track the pilot, use our Command Center tool to log risks, incidents, and adoption metrics across teams (/command-center).

Policy framework (what to standardize without slowing teams)

1. Pattern ownership: Platform owns patterns. Security owns controls. Product teams own architecture instances. Write that down.

2. Exception handling: Time-box exceptions to 30 or 60 days. Require an owner and a removal date. Track exceptions in the same repo as the architecture.

3. Evidence format: Define what “proof” looks like. CALM artifacts plus pipeline logs beat screenshots. The JSON Schema deck shows how controls can map to measurable metrics and thresholds (JSON Schema deck).

4. Architecture review SLAs: Replace weekly boards with async review on pattern changes only. Keep human review for new patterns, not every app.

Our incident postmortems guide pairs well with this shift because CALM gives you a clean record of intent versus reality (/tools/incident-postmortem).

Architecture principles (how the architect role should change)

1. Constraints over consultation: Architects should spend more time encoding rules than attending design meetings.

2. Data paths are first-class: Model data access for RAG and analytics. InfoQ expects systems to be designed with data consumption for RAG in mind (InfoQ Architecture Trends 2025).

3. Controls are measurable: Every control needs a test and a signal. Tie controls to metrics, logs, and traces.

4. Tooling is part of the architecture: CALM CLI, CalmHub, and IDE plugins change adoption. Treat developer experience as a requirement, not a bonus.

For leaders who need to justify tooling spend, our Build vs Buy Matrix helps compare CALM adoption versus proprietary governance suites (/tools/build-vs-buy-matrix).

Link-worthy element: the CALM adoption decision matrix

Use this matrix to decide where CALM pays off first.

If you need to quantify delivery impact, pair the pilot with our Engineering Metrics Dashboard and track lead time and change failure rate (/tools/engineering-metrics-dashboard).

Bigger picture: CALM, agentic AI, and the next 12 months of architecture leadership

FINOS is convening workshops on AI reference architectures, aimed at security, architecture, and model risk leaders, with a focus on “agentic AI systems” and shared patterns (FINOS AI reference architectures workshop). That direction matches what I see inside enterprises. AI systems force architecture to get explicit about data, tools, and trust boundaries.

CALM fits that moment because it gives you a common language for intent. The architect role shifts again. Architects become curators of reference architectures for AI, APIs, and platforms, and they ship those references as code.

The hard part is org change, not JSON. Teams will push back on new files in repos. Security teams will push back on giving up manual sign-off. Architects will push back on losing the “review board” identity.

What would change inside your org if architecture approvals moved from meetings to pull requests, and architects got measured on pattern adoption instead of diagram quality?

Sources

1. InfoQ Software Architecture and Design Trends Report 2025
2. QCon London 2025: Platforms for Secure API Connectivity With Architecture as Code
3. FINOS CALM docs: What is CALM?
4. DevOps.com: Morgan Stanley Open Sources CALM
5. GitHub: FINOS Architecture as Code issue #1864 (decorators)
6. LinkedIn: FINOS releases CALM v1.0 (Matthew Bain)
7. JSON Schema Conference deck: Powering FINOS Architecture as Code
8. FINOS hosted event: AI Reference Architectures Workshop Part One (2025-10-20)
9. YouTube: Zero JSON, LLMs and FINOS CALM
10. YouTube: CALM, securing AI and APIs from tool chaining attacks