> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/stop-selling-event-driven-architecture.-start-selling-business-outcomes.md).
# 🚀 Stop Selling Event-Driven Architecture. Start Selling Business Outcomes
A strategic guide on how to secure EDA funding and adoption by stopping the technical pitch and translating event architecture into concrete business outcomes.
Why are the best EDA initiatives funded through business value, not technical excellence.
Many organizations view Event-Driven Architecture (EDA) as a technology modernization initiative focused on event streams, messaging platforms, and real-time integration. While these capabilities are important, they rarely justify investment on their own.
Business leaders fund outcomes, not architecture. One of the biggest challenges in securing EDA investment is focusing too heavily on technical benefits such as scalability, decoupling, and architectural elegance. These matter to technology teams, but business stakeholders are more interested in the impact on business performance, customer experience, operational efficiency, and risk management.
The key question is simple: **"How will this improve business outcomes?"** If we cannot answer that clearly, gaining support and funding becomes difficult.
For more insights, see my newsletter: **"**[**Event-Driven Architecture: Aligning Technology with Business Outcomes**](https://www.linkedin.com/pulse/event-driven-architecture-aligning-technology-business-stephen-tsoi-xwnnc)**."**
### Start with the Business Problem
From my experience, successful EDA adoption starts with understanding business challenges, not promoting technology.
Conduct a thorough analysis of stakeholder use cases and current operational or system pain points. Then demonstrate how EDA can improve information flow, increase responsiveness, and remove bottlenecks.
This is where many IT teams and vendors fail. They focus on explaining the technology rather than the business value. Business leaders invest in outcomes, not architecture.
The technology remains the same, but the story becomes relevant to those making investment decisions.
### Start Small and Prove the Value
Large-scale transformation programs often struggle because they ask stakeholders to commit significant investment before any value has been demonstrated.
A more effective approach is to identify a small but high-value use case and establish a proof of concept. When stakeholders see tangible improvements, support often expands organically to other business domains.
### Four Lessons Learned from Driving EDA Adoption
#### 1. Tailor the Conversation to Each Stakeholder
Not all stakeholders care about the same outcomes. Using the same narrative for every audience is rarely effective.
Instead, align the discussion with the objectives and success metrics that matter most to each stakeholder group.
#### 2. Understand the Business and System Landscape Thoroughly
To build credibility, you need more than architectural knowledge.
You should understand:
* Business processes
* System interactions
* Upstream and downstream dependencies
* Data flows
* Operational constraints
* Regulatory considerations
Stakeholders frequently ask questions that extend beyond the immediate solution. Being prepared to discuss the broader landscape demonstrates ownership and builds confidence in the proposed approach.
#### 3. Use Real Numbers Whenever Possible
One of the most effective ways to gain support is to quantify the expected benefits.
Avoid statements such as:
* "The process will be much faster."
* "The system will be more efficient."
* "Users will have a better experience."
Instead, use measurable outcomes:
* Reduce processing time from 4 hours to 5 minutes.
* Improve customer notification speed from next-day to near real-time.
* Reduce manual intervention by 60%.
Numbers transform assumptions into business cases.
#### 4. Translate Technical Concepts into Business Language
Many stakeholders are not interested in technical architecture diagrams.
That does not mean they lack expertise.
In fact, they often possess a deep understanding of the business processes and systems they manage every day. When people understand the outcome, they become far more willing to support the solution.
**They invest in better business outcomes that Event-Driven Architecture makes possible.**
### Takeaway
The fastest way to gain support for EDA is to stop selling architecture and start telling a business story. When stakeholders can clearly see the operational, financial, or customer benefits, funding conversations become significantly easier and adoption follows naturally.
## 🚀 Let's Connect Beyond GitBook!
If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms:
* **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/).
* **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/).
***
#### 📬 Stay Ahead of the Curve
Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week.
👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed!
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/stop-selling-event-driven-architecture.-start-selling-business-outcomes.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
