Issue #66

In the previous issue, I introduced a framework for evaluating API design methodologies. In this issue, I apply that framework to the Synergetic Blueprint, a domain-driven API design methodology proposed by Junker and Lazzaretti [1]. As a reminder, here a is a table summarising the review dimensions.

For each criteria in each dimension, I will give my opinion on how the Synergetic Blueprint addresses that criteria, and I'll also give the Blueprint a score between ' 1- Does not support this outcome' and '5 - Excellent; a built-in strength'. Let us begin.

Criteria question: How well does the API design method lead to platform APIs that are aligned with real user needs and requirements, to promote high platform adoption?

The Synergetic Blueprint is strongly geared towards producing APIs that are aligned to business capabilities. The Enterprise Design phase starts by exploring business capabilities at the highest level - right from the business model as expressed on the business model canvas. The extent to which technical stakeholders are given full access to an organization’s business plan as expressed in a business model canvas depends on the project and organization. But when done well, the Enterprise Design Phase of the Synergetic Blueprint should create not just a strong alignment, but stop APIs being built that don't need to – because they are commodity capabilities that can be procured. So the Synergetic Blueprint supports business alignment, but does it support user-centricity?

The focus on user journey and user outcomes in the Strategic Design phase, using Domain Storytelling and EventStorming workshops, supports this user-centricity. While these workshops can be intensive, they help ground the requirements in real world user scenarios and create architectural alignment with business capabilities. I also like the fact that the API Product Canvas has a box for the Value Proposition of the API and its Core Functions. These help focus the design on the user, but also communicate this focus across to different stakeholders.

This combination of user-centricity and business capability alignment comes with a cost. The Synergetic Blueprint requires multiple workshops with multiple stakeholders and this takes time, and requires strong facilitation [1].

Criteria question: How well does the methodology encourage APIs to be designed for end-to-end workflows and orchestration across multiple capabilities?

The Synergetic Blueprint EventStorming workshops are a great way to surface the end-to-end workflows and orchestration required for Bounded Context APIs. It creates an alignment between the web API design (request-response interactions) and event-driven API design (publish / subscribe interactions). The use of Bounded Contexts and Context Maps in steps 5 and 6, ensure the designs are based on consistent data models, and this works well for interoperability of the APIs. 

One thing I would have liked to see more of is the capturing of workflows during the design process, in some kind of executable workflow format, like Arazzo or Postman collections. This would be a very useful artifact from the design process, and can serve several uses, including end-to-end test automation, agentic API consumption use cases, and SDK generation. While the authors provide a prompt for API contract generation, I think it would be valuable to also have a prompt for the generation of workflows (like Arazzo) based on other artefacts of the Synergetic Blueprint method (like Domain Stories) and generated API contracts.

Criteria question: How much does the API design encourage platform API reuse and reduce the probability of duplicated APIs?

Having a clear Context Map showing APIs connecting Bounded Contexts helps make context boundaries clear. Such a Context Map should reduce the chance of creating new APIs for a Bounded Context where one already exists. (Assuming, of course, that the Context Map is consulted by the involved teams). Such a map can be very useful for API design reviews. That is, during API reviews, check the Context Map to see where the API sits in the grand scheme of the digital platform.

However, I wonder how the Synergetic Blueprint method will fit into organisations that have a poorly defined context maps or where there are lots of duplicate APIs. I imagine the EventStorming and Context Mapping workshops can help highlight these issues. I think that as part of these workshops, there should be an activity somewhere to see what APIs exist in the organizations API catalogue that can be reused. An API catalogue with excellent search features or an AI-assistant can help with this. 

Criteria question: Does the method encourage creating APIs that can be evolved without creating backward incompatible versions (i.e. breaking changes)?

The Synergetic Blueprint’s strong focus on a domain-driven approach based on stable, prioritized, business capabilities, shared domain data models, and extensive stakeholder discussions helps reduce (but of course, not eliminate) the probability of API evolution leading to breaking changes. True, a high up front investment in time is required for defining those domain models and bounded contexts, but it does lead to a more stable API. 

However, the Synergetic Blueprint does not make mention of API versioning techniques. I assume it expects this to be covered in the organisations API style guide, which is used in the Tactical API Design stage. As I shall mention in the next criteria, (Standardization and Consistency) this is quite a gap.

Here is a radar chart of my evaluation so far. As you can see, the Synergetic Blueprint performs strongly in supporting user-centric APIs, workflow orchestration, and reuse through domain-driven modelling.

In my next post, I will continue with the other evaluation criteria.

[1] A. Junker and F. Lazzaretti, Crafting Great APIs with Domain-Driven Design: Collaborative Craftsmanship of Asynchronous and Synchronous APIs, 1st ed. Berkeley, CA, USA: Apress, 2025.

9 Tips for Reducing API Latency in Agentic AI Systems: Bill Doerrfeld explores the technical challenges of latency within agentic AI workflows, where multiple API calls are often chained together. He provides a series of actionable strategies ranging from protocol selection to regional deployment designed to streamline the communication between AI agents and the external data sources or services they rely upon.

Adversarial testing: Why attacking APIs at scale is the best defense against real-world attacks: The Equixly Team discusses the shift toward proactive security by using automated adversarial testing to identify vulnerabilities in APIs before malicious actors can exploit them. They propose a strategy of continuous, automated "ethical attacks" that simulate real-world breach attempts, allowing security teams to harden their infrastructure based on empirical evidence of how their APIs behave under duress.

Introducing Zuplo API Monetization: provides a high-level overview of the strategic and technical requirements for transforming APIs from cost centers into revenue-generating products.

API Monetization 101: Your Guide to Charging for Your API: Martyn Davies delves deeper into the practical implementation of API billing strategies. They categorise various monetization patterns—such as direct charging, indirect revenue, and developer incentives while providing a roadmap for technical integration.

Arazzo - The Cheat Sheet: Yoan Gross introduces the Arazzo Specification, a new standard designed to complement OpenAPI by describing sequences of API calls to achieve specific functional goals.

The Hidden Cost of Poor API Governance in Large Organizations: Venugopal Reddy Depa provides a scholarly examination of the evolving security landscape as AI services are integrated into traditional API architectures.

Categorizing APIs. Part 1.: Aliaksei Taliuk in this article argues that understanding if an API is internal, partner-based, or public is essential for determining the appropriate levels of security, documentation, and governance required. By establishing these categories, the author provides a framework for organisations to better manage their digital assets and align their technical interfaces with broader strategic objectives.

Why We Built Our Own OpenAPI Linter (And How It Compares): Tristan Cartledge details how modern enterprise specifications often exceed 50,000 lines, causing traditional linters to become significant hurdles in CI/CD pipelines and local development environments.

10 Strategies to Reduce MCP Token Bloat: Bill Doerrfeld examines the inefficiencies inherent in the Model Context Protocol (MCP) when it inadvertently transmits excessive data to Large Language Models. He provides technical guidance on how to filter and prune data at the protocol level, ensuring that only the most pertinent metadata and content are passed to the AI agent.

The Missing Layer in OpenClaw Architectures: Liam Quinn from the Jentic Team identifies a critical architectural gap in the "CLAW" (Control, Logic, Actions, and Workflow) framework for AI agents. He argues that developers can build more reliable and sophisticated agentic systems that maintain state and relevance across disparate user interactions and workflows.

MCP Authorization: How to Manage Permissions for AI Agents & Services: Kay James in this article outlines a framework for fine-grained authorization, ensuring that agents are granted only the specific permissions required for their current task, thereby adhering to the principle of least privilege in an increasingly automated ecosystem.

How Agentic AI is Changing the API SDLC: Jeremy Sindall posits that as AI agents transition from simple assistants to autonomous entities capable of executing complex tasks, the requirements for API design, discovery, and governance must evolve.The article emphasises that as agents gain autonomy, governance frameworks must incorporate real-time monitoring and stricter policy enforcement to manage the unique risks associated with automated API interactions and unintended model behaviours.

LEAP 2026: Tyk's virtual conference on APIs, AI and the future of financial services. Date: March 12, 2026 | Location: Virtual

Apidays Singapore: apidays Singapore will share insights on API monetization, security, AI-driven automation, and more. Date: 14 - 15 April 2026. Location: Marina Bay Sands, Singapore.

Apidays New York: Location: Convene 360 Madison, New York, Date: 13 - 14 May 2026

API Conference London 2026: The Conference for Web APIs, API Design and Management Date: May 11 – 15, 2026, Location: Park Plaza Victoria London, UK.

APIOps Helsinki Conference 2026: An API gathering in Finland for two days of focused strategy sessions, hands-on clinics, and peer-led community building. Date: June 2-3, 2026 | Location: Epicenter, Helsinki.