Jim Gough discusses the transition from accidental architect to API program leader, explaining how to manage the complexity of secure API connectivity through the Common Architecture Language Model (CALM) framework.
Jim Gough discusses the transition from accidental architect to API program leader, explaining how to manage the complexity of secure API connectivity. He shares the Common Architecture Language Model (CALM), a framework designed to bridge the developer-security gap. By leveraging architecture patterns, engineering leaders can move from six-month review cycles to two-hour automated deployments.
The Complexity of API Connectivity
Building APIs appears simple at first glance. With modern frameworks, you can get a consumer and API service running on your laptop in minutes. However, authentication and authorization introduce immediate complexity. When users cross trust boundaries, consistency becomes critical regardless of backend architecture.
API management tools seem like the obvious solution. They provide policy configuration and centralized control, but introduce their own complexity. Operators must carefully configure policies, and moving between environments becomes challenging. API management can do many things well, but that versatility becomes a liability when portability is needed.
As systems scale, automated deployments become essential. Previously manual configuration through user interfaces now requires learning entire API ecosystems that may not exist in development environments. Tools like WireMock help mock dependencies, but add complexity. Coordinating API service deployments with zero downtime and specification consistency becomes critical.
Gateway components often enter the architecture for service discovery and routing, especially in microservices environments. This adds another layer of complexity to manage.
Non-functional requirements compound the challenge. Security must be considered from the outset, not as an afterthought. Performance characteristics need clear communication—internal users often misunderstand REST API performance expectations. Availability requirements demand consideration of infrastructure failure scenarios. Observability becomes critical for troubleshooting production issues. Audit logs ensure compliance. Cost management prevents unexpected bills. Growth and maintenance requirements demand sustainable approaches.
These non-functional requirements transform from nice-to-haves into critical operating requirements. Without them, API programs spend time on maintenance rather than delivering value.
The developer-infrastructure gap emerges when shifting left too aggressively. Providing developers with powerful tools without adequate support creates frustration. Infrastructure as code can be overwhelming with excessive YAML. Undifferentiated heavy lifting—time spent on plumbing rather than business value—distracts from core objectives.
The developer-security gap represents another challenge. Security concepts often feel unfamiliar to developers. Training mismatches exist between what security professionals expect and what developers receive. Security becomes a gate rather than a guide when introduced too late in the process.
Secure Design Approaches
When architecture changes become necessary in regulated industries, review processes multiply. Rather than conducting 80-100 individual security reviews, a better approach embeds security thinking from the start.
Threat modeling provides this foundation. While developers naturally think about happy paths, attackers consider exploitation scenarios. The STRIDE model categorizes threats effectively:
- Spoofing: Impersonating legitimate services through mTLS, service identity validation, or SPIFFE and certificate pinning
- Tampering: Manipulating requests and responses to redirect users or inject malicious content
- Repudiation: Denying actions occurred without proper logging and audit trails
- Information disclosure: Exfiltrating sensitive data through TLS, encryption at rest, and proper access controls
- Denial of service: Overwhelming services internally or externally to disrupt operations
- Elevation of privilege: Gaining unauthorized access through role misconfiguration or lateral movement
Architecture Patterns in Action
The Common Architecture Language Model (CALM) addresses these challenges through a structured approach. The core model uses JSON Schema, familiar to OpenAPI users. A command-line interface provides accessibility. Patterns represent reusable architectural templates.
Nodes represent architectural components—services, load balancers, databases, or even entire Kubernetes clusters. Relationships connect nodes with validation ensuring semantic correctness. Interfaces specify interaction details like HTTP paths or gRPC methods. Controls capture non-functional requirements like security policies or performance constraints.
The micro-segmentation control exemplifies this approach. Requirements specify the NIST document basis and configuration options. Ingress and egress policies define network boundaries. Protocol specifications ensure proper communication patterns.
CALM doesn't replace existing tools but provides glue between them. It excels in regulated industries and high-reuse organizations where platform teams need consistent deployment patterns. The goal shifts from six-month review cycles to two-hour automated deployments through clear paved paths, fast feedback loops, self-service deployments, integrated approval processes, drift detection, and comprehensive documentation.
Demo Walkthrough
The demo illustrates CALM's practical application. Starting with a pattern file, the architect defines nodes, interfaces, relationships, and controls. The pattern captures everything needed for secure deployment without specifying implementation details like container image names.
Running calm-generate creates an architecture from the pattern, prompting developers for implementation-specific details. Validation ensures completeness before deployment. Template bundles transform the architecture into infrastructure as code—Kubernetes manifests, Terraform configurations, or other deployment artifacts.
The micro-segmentation example demonstrates security by default. A minikube cluster with Calico default-deny policies blocks all network traffic. Only explicitly permitted connections work. The attendees service remains inaccessible from unauthorized containers, preventing lateral movement attacks.
CALM Hub provides a central repository for patterns and architectures. Visualization tools generate C4 diagrams and documentation automatically. The Docify feature creates comprehensive documentation including architectural diagrams, control specifications, and deployment details.
CALM Workflow
The complete workflow begins with C4 design and review involving architects, developers, and security professionals. Patterns capture architectural decisions, interface specifications, control requirements, and template bundles. Publishing to CALM Hub makes patterns available for generation. Validation ensures architectural integrity. Infrastructure as code generation, configuration templating, or documentation creation completes the deployment pipeline.
This approach transforms API program management from reactive firefighting to proactive architecture governance. Developers gain clear guidance while maintaining flexibility. Security becomes embedded rather than bolted on. Compliance becomes demonstrable rather than aspirational.
Summary
Complex operating environments demand sophisticated approaches to API connectivity. The developer productivity imperative requires reducing time-to-market while maintaining security and compliance. CALM provides a framework for managing this complexity through industry-standard modeling, practical tooling, and comprehensive documentation.
The journey from accidental architect to API program leader involves recognizing that simplicity at the surface masks complexity underneath. Success requires embracing that complexity through structured approaches that make secure development the easy path rather than the difficult one.
CALM continues evolving with controls and flows modeling more detailed requirements. The CLI and CALM Hub provide interactivity. Documentation remains a work in progress but represents a critical component for adoption.
For organizations facing similar challenges—regulated industries, high-reuse environments, or complex API ecosystems—CALM offers a proven approach to transforming API program management from months-long review cycles to hours-long automated deployments while maintaining security and compliance.
Questions and Answers
How easy is it to retrofit CALM on existing systems? Legacy systems can be modeled as nodes within CALM architectures. Controls can be applied to existing components, and detailed architecture specifications can evolve over time. AI-assisted analysis tools are emerging to help import existing systems into CALM models.
Can CALM integrate with Arazzo and OpenAPI standards? While CALM currently pulls OpenAPI specifications into deployment systems, deeper integration with emerging standards like Arazzo represents an active area of exploration. The goal remains complementing rather than competing with established standards.
**Could CALM concepts extend into OpenAPI as vendor extensions?**n This represents a promising direction. While CALM currently links to OpenAPI specifications, bidirectional integration could enhance both ecosystems by expressing architectural constraints directly within API definitions.

Comments
Please log in or register to join the discussion