In most codebases I have reviewed, events are treated as a messaging detail. You pick a broker, wire up a serializer, and call it done. The architecture is shaped by the transport, not by the domain. This is exactly backwards.

What a Domain Event Actually Is

Eric Evans defined it plainly

A domain event is something that happened inside the domain — something meaningful to domain experts, worth recording, and worth broadcasting.

That last word is the key. Not sending. Not commanding. Broadcasting — because the producing context does not know, and should not know, who is listening.

Three properties follow from this definition:

• Immutability — an event is a fact about the past. It cannot be rejected. OrderPlaced already happened; there is nothing left to accept or refuse.
• Named in the ubiquitous language — OrderPlaced, InvoiceIssued, UserRegistered. Not MessageSentToQueue. Domain experts should recognize the name immediately.
• Temporal decoupling — consumers process events at their own pace. The producing bounded context does not wait, does not care, and does not retry on their behalf.

This is different from a command. A command is a request: do this. It can be rejected. An event is a statement of fact: this happened. It cannot.

Why Events Matter Architecturally

Bounded contexts need to share information without becoming tightly coupled. This is one of the hardest problems in enterprise architecture, and it is where events earn their place.

Without events, the typical solution is direct invocation: one service calls another, either synchronously over HTTP or through a shared library. Both approaches create coupling. The caller must know the address of the callee. Changes to one can break the other. Deployments become coordinated.

With events, the producing context simply announces what happened. Any other context that cares can subscribe. The relationship is inverted: consumers depend on the producer’s contract, not on its implementation. Adding a new consumer requires no change to the producer.

This is how bounded contexts integrate cleanly. It is also what enables the kind of architecture that can scale both technically and organizationally — teams can work on their contexts independently, as long as they agree on the event contracts.

Domain Events vs. Integration Events

A distinction that often gets lost in practice: domain events and integration events are not the same thing.

Domain events are exchanged within a bounded context, between aggregates. They tend to be fine-grained and carry only the delta — the piece of information that changed. They do not need to be serialized to a broker. They can be dispatched in-process, within the same unit of work.

Integration events cross context boundaries. They need to be serialized, transported, and versioned. They typically carry more data, because the receiving context cannot reach into the producing context’s storage to fetch the rest. They are the contracts between teams.

Confusing the two leads to either over-coupling (integration events used inside a context, carrying unnecessary data dependencies) or under-specification (domain events used across boundaries, without proper versioning or schema governance).

Modeling Events as First-Class Contracts

If integration events are contracts between teams, they deserve the same governance as any other public API. That means:

• A machine-readable schema, not just a code example.
• Versioning, with explicit rules about breaking changes.
• A discovery mechanism, so consumers can find what events are available.

This is where most teams struggle. REST APIs have OpenAPI. Events get a Confluence page that is out of date within a week.

The architectural answer to this is to treat event schemas the same way you treat API specifications: version-controlled, machine-readable, and published alongside the producing service.

Deveel Events: A .NET Implementation

Deveel Events (GitHub) is a lightweight .NET framework built on top of the CloudEvents standard. It focuses on the publishing side of domain events — the part that most teams rewrite from scratch every time they start a new service.

What makes it architecturally interesting is its scope. It does not try to be a full service-bus runtime. It does not dictate how you model aggregates or build read models. It solves one problem well: broadcasting domain events from a bounded context to any number of downstream consumers, through a transport-agnostic layer.

Annotating an Event Contract

The starting point is a data class annotated with [Event]. This is your contract:

using System.ComponentModel.DataAnnotations;
using Deveel.Events;

[Event("order.placed", "1.0")]
public class OrderPlacedData
{
    [Required]
    public Guid OrderId { get; set; }

    [Required]
    [Range(0.01, 1_000_000.0)]
    public decimal Amount { get; set; }

    [Required]
    public string Currency { get; set; } = default!;

    public string? Notes { get; set; }
}

The [Event] attribute captures the event type string (order.placed) and its version (1.0). These values become part of the CloudEvents envelope, giving every published event a stable, identifiable type.

Registering the Publisher

Registration lives in the DI setup, separate from the domain model:

using Deveel.Events;

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddEventPublisher(options =>
    {
        options.Source = new Uri("https://myapp.example.com");
    })
    .AddServiceBus(options =>
    {
        options.ConnectionString = builder.Configuration["ServiceBus:ConnectionString"]!;
        options.QueueName        = builder.Configuration["ServiceBus:QueueName"]!;
    });

The publisher is transport-agnostic. Swapping Azure Service Bus for RabbitMQ means changing the channel registration, not the domain code.

Publishing from a Domain Service

using Deveel.Events;

public class OrderService
{
    private readonly EventPublisher _publisher;

    public OrderService(EventPublisher publisher)
    {
        _publisher = publisher;
    }

    public async Task PlaceOrderAsync(Guid orderId, decimal amount, string currency)
    {
        // ... domain logic ...

        var data = new OrderPlacedData
        {
            OrderId  = orderId,
            Amount   = amount,
            Currency = currency
        };

        await _publisher.PublishAsync(data);
    }
}

The domain service does not reference the broker. It does not know whether the event will go to Azure Service Bus, RabbitMQ, or an HTTP webhook. That is a deployment decision, not a domain one.

Schema Governance

One of the most valuable parts of the framework is its schema support. The Deveel.Events.Schema package derives a schema from annotated data classes and exports it as JSON Schema, YAML, or an AsyncAPI 2.x document.

This is what gives integration events the same governance weight as REST APIs. Consumers get a machine-readable contract. Schema registries can validate payloads. Breaking changes can be detected automatically.

dotnet add package Deveel.Events.Schema
dotnet add package Deveel.Events.Schema.AsyncApi

The AsyncAPI export is particularly useful: it produces a complete, machine-readable API specification for asynchronous messaging — the same role OpenAPI plays for REST. Tooling can generate documentation sites, client SDKs, and mock servers from it.

The Architectural Principle

The framework mechanics are secondary. The principle matters more.

Domain events are contracts. They deserve the same discipline as any other public interface: versioning, schema governance, and explicit communication of breaking changes. They should be named by domain experts, not by the infrastructure team. They should be scoped to what actually happened, not to what the receiving system happens to need today.

When you treat events as first-class architectural citizens — and invest in the tooling to govern them — bounded contexts can evolve independently. Teams can work in parallel. The system can scale.

When you treat events as a messaging detail, you get a distributed monolith with extra latency.

The choice is made in design, not in deployment.

Deveel Events documentation is at events.deveel.org. Source code and issue tracker are on GitHub.

Disclosure: I am the author of the Deveel Events project. The views expressed in this post reflect my own architectural perspective. You can find my other open-source work on GitHub.

Even when the final accountability is mine, and even when I know I will be the one defending the design in front of leadership, delivery teams, security, and operations, I do not want to design alone. I want peers around me who can challenge my assumptions before production does, because production is the most expensive and least forgiving reviewer you can find.

Ownership is not solitude

One misunderstanding I see often is the idea that ownership means isolation. It does not. Ownership means I make the call when a decision is needed, I explain the trade-offs clearly, and I take responsibility for the consequences. Isolation, on the other hand, means I protect my design from criticism until it is too late to change it cheaply.

A strong architect should be decisive, but never unchallenged. If every architecture conversation ends with “the architect said so,” then we are not doing architecture, we are doing hierarchy.

When hierarchy becomes too heavy, people outside the architect role often stop challenging openly, even when they clearly see a flaw. Not because they agree, but because they are calculating the social cost: if they push too hard, will they be seen as difficult, disrespectful, or as blockers to delivery? That silence is easy to misread as alignment.

The dangerous part comes later. The criticism that was not voiced in the room does not disappear; it moves underground into implementation choices. Teams start making quiet deviations, defensive workarounds, and side decisions behind the curtain to protect delivery from a design they do not trust. At that point, the architecture may still look coherent in documents, but it has already started to fragment in practice.

The role is not to be the loudest voice in the room; the role is to integrate the best evidence from people who see different corners of the system.

Peers are critical sparring partners

An architect peer is not there to agree politely and move on. A useful peer is someone who asks uncomfortable questions, spots hidden coupling, questions optimistic assumptions, and forces clarity where language has become too abstract.

In practice, this kind of sparring catches exactly the mistakes that are easy to miss when you are deep in your own mental model: integration points that look simple but are operationally heavy, data ownership boundaries that seem obvious but collapse under real usage, security constraints that appear late, and migration plans that are technically possible but organizationally unrealistic.

The value of peer challenge is not just technical quality. It also improves legitimacy. When teams know a design has survived serious internal scrutiny by competent peers, they trust the architecture process more, and they engage earlier with better feedback instead of resisting later when timelines are already under pressure.

What this looks like in real work

You do not need heavy governance theater to make peer contribution real. You need regular habits.

I have seen good results when architects adopt a small set of simple rituals: short architecture design reviews with explicit decision records, pre-mortem sessions where peers try to break the design on purpose, and periodic checkpoints during implementation where the original assumptions are tested against reality rather than protected as doctrine.

Another important habit is to separate criticism of the design from criticism of the person. If peer review becomes political, everyone becomes defensive and no one learns. If peer review is framed as a shared responsibility to reduce delivery and operational risk, then challenge becomes a professional service, not a personal attack.

The architecture gets better, and so does the architect

The real outcome of peer contribution is not only fewer defects or fewer late surprises, even though those benefits are substantial. The deeper benefit is that the architect grows in judgment, because repeated exposure to strong counterarguments improves decision quality over time.

An architect who never gets challenged usually becomes rigid. An architect who invites challenge becomes sharper, calmer under pressure, and more credible when a difficult decision must finally be made.

So yes, one architect may hold the final responsibility, sign off the decision, and stand behind it across the organization. But architecture should still be forged with peers, tested by critical sparring, and strengthened by collective intelligence, because that is how you design systems that can survive contact with reality.

My opinion is straightforward. If we keep treating prompting as a personal craft, we will keep getting local wins and organizational fragility. If we treat it as architecture, we can aim for repeatability, accountability, and controlled evolution. In my experience, teams rarely fail because a model is incapable; they fail because there is no shared architecture around how that model is used. This is exactly why Fowler and his co-authors’ framing matters: they are not proposing prompt cleverness, they are proposing delivery discipline.

From prompt skill to delivery architecture

I have seen a recurring pattern in AI-assisted development initiatives. A small group of engineers gets very good results with ad-hoc prompting, the rest of the organization tries to imitate those results, and leadership assumes it has found a scalable operating model. It usually has not. One contribution I appreciate in Zhang’s article is that his team makes this distinction explicit: individual effectiveness is not the same as organizational reliability.

At that point, familiar architectural problems emerge. Different people use different implicit interfaces for the same task. Valuable knowledge ends up in private chats rather than reusable assets. Reviews focus on generated code while ignoring the generation conditions. Sensitive context is copied around with no clear policy boundary. To me, this looks very similar to a distributed monolith in integration architecture: productive in short bursts, expensive and risky over time.

This is why I prefer to think in terms of prompt assets rather than prompts. A reusable prompt module should be narrow in intent, explicit in assumptions, constrained by policy, and stable in output shape. I see no meaningful difference between this and how we design internal APIs or shared platform libraries. It is the same engineering discipline applied to a new interface. In that sense, I read Zhang’s structure as a software architecture concern disguised as AI guidance.

When I imagine a concrete case, such as ADR generation, I do not want each engineer inventing structure from scratch. I want a governed module that always returns context, options, trade-offs, recommendations, and risks. That consistency does not reduce creativity; it reduces ambiguity and makes architectural reasoning comparable across teams.

The boundary problem most teams underestimate

The part I consider most underestimated is context. Context injection is not a convenience feature; it is a data architecture concern with governance implications. Zhang repeatedly emphasizes structure around inputs and expected outputs, and I think that is where many teams still underinvest.

I find it useful to frame context as an envelope with clear boundaries: what is required to do the work, what is conditionally useful, and what is restricted unless transformed or explicitly approved. Without that framing, teams usually end up with both compliance exposure and reproducibility problems. The output quality also becomes unstable because each run is shaped by arbitrary context choices.

A backlog decomposition assistant is a good example. I would allow domain glossary, service boundaries, and non-functional constraints, because those improve relevance. I would block production secrets, raw customer transcripts, and unapproved roadmap material, because those create risk with no proportional value. Architecture, in this scenario, is the mechanism that maximizes useful flow while controlling coupling and exposure.

Reliability requires deterministic controls

The other point I feel strongly about is evaluation. I do not trust generated output without gates, not because models are inherently poor, but because architecture should always assume variance.

For me, structured prompt-driven workflows become credible only when deterministic controls are built into the pipeline: format checks, policy checks, architecture conformance checks, and mandatory human review for high-impact changes. Without these controls, teams can ship plausible regressions faster than before, which is the worst possible outcome of acceleration. This is another point where I align with Zhang’s broader engineering philosophy: fast feedback without quality control is not acceleration, it is deferred failure.

In legacy migration work, for instance, my minimum expectation is simple: the build must pass, the existing test suite must pass without reducing scope, forbidden dependencies must stay out, and architecture rules must still hold. If one of these conditions fails, the workflow should go back to refinement instead of moving toward merge. I consider this non-negotiable.

This is also why I prefer orchestration to one-shot prompting. Real delivery work has stages, dependencies, and feedback loops. A staged flow that frames constraints, proposes a plan, generates changes, validates them, and documents rationale is more diagnosable and easier to improve than a single opaque interaction. When quality drops, I can see where it dropped and fix that stage.

From a governance perspective, I think a federated model works best: platform teams own shared modules and gates, product teams own domain context, and architecture or security functions own guardrails and exceptions. That balance avoids both central bottlenecks and unmanaged fragmentation.

Yes, this approach adds overhead. It requires asset lifecycle management, context governance, gate automation, and new skills in failure analysis. I accept that trade-off for the same reason I accept the cost of CI/CD and API governance: reliability is never free, and pretending otherwise is usually how technical debt is born.

I do not see Structured Prompt-Driven Development as another methodology to memorize. I see it as a correction toward architectural maturity. The meaningful shift, in my mind, is moving from “I can get good results with prompts” to “we can deliver reliable outcomes with a governed system.” Reading Zhang’s article through that lens helped me clarify my own position: the long-term value is not in better prompts, but in better architecture around prompt-driven work. Once that shift happens, the priorities become obvious: design boundaries, define contracts, instrument workflows, and enforce quality. That is architecture work, and I believe it deserves the same seriousness as any other production-critical concern.

Last week, I had a meeting with a supplier to present an architectural blueprint I had prepared, with the goal of assessing whether their system could support it.

After a brief presentation, we moved into a bilateral discussion. A young engineer on their side challenged my assumptions, and within fifteen minutes I was convinced he was right. I had to revise — fortunately not radically — the processes and integrations I had originally envisioned.

When I openly acknowledged that he was right, both the supplier’s team and my own colleagues seemed genuinely surprised. Some even tried, half-jokingly, to talk me out of changing my original design, like if the young engineer acted in disrespect. In that moment, I had another realization: many people take it for granted that an Architect should possess complete knowledge of everything within the scope of the architecture they design — to the point of defying the internal logic of systems themselves and arrogantly imposing a personal vision on top of reality.

I firmly believe that an Architect who works this way is preparing for disaster. If you do not study the terrain, understand the materials, or acknowledge the skills of the people involved, you are not designing an architecture — you are performing a vanity exercise. And vanity-driven architectures eventually collapse, causing harm to others and often significant financial damage.

For some, being an Architect is reduced to a symbolic milestone in career progression: a title to wield against others, a perceived badge of superiority, perhaps even a justification for a higher salary. (I can personally debunk that myth—I have been an Enterprise Architect while earning less than several senior developers.) The real cost of this mindset, however, is the gradual loss of objectivity and rational thinking.

This reminds me of a situation where I had a prolonged conflict with a colleague. We argued for weeks, exchanged harsh emails, and strongly disagreed on many issues. Yet, during a public architectural discussion, I openly defended his position on a topic where I believed he was right. Later, he reached out privately to thank me for being objective and for not letting personal differences interfere. That reaction surprised me—almost as if objectivity were optional, even when the alternative could risk hundreds of thousands, if not millions, in damages. Silencing one’s ego is difficult, in architecture as in any other discipline, but the psychological effort pays off in the long run.

One aspect that is often misunderstood from the outside is that an Architect is not a Subject Matter Expert. Architects are not expected to know everything about every system, technology, process, or organizational nuance within the scope of their architecture. Sometimes, even Architects themselves forget this, falling into the trap of believing they can independently interpret business, legal, technical, and organizational concerns without relying on experts in those domains.

Naturally, everyone brings personal interests and professional or academic backgrounds that lead to deeper knowledge in certain areas. But an Architect must remain acutely aware of the limits of their expertise—and be humble enough to listen, learn, and integrate the insights of true experts. Objectivity in architecture is not about knowing everything; it is about knowing how to synthesize reality, evidence, and expertise into coherent and sustainable decisions.

Dealing with legacy code is a common task for developers, and in most of the cases it is not a pleasant one, since they didn’t participate in the design of the system, if any design was done at all. Finding yourself in such situation might require that you will engage in some analysis and studies to refactor a legacy application using Domain-Driven Design (DDD) concepts, and possibly apply the Strangler Fig Pattern to migrate from a monolithic application to a microservices architecture.

Embarking in such a journey is not to be taken lightly, and it should be sponsored by the organization and the management you belong to, because it will require a lot of resources and time, and it will be a long-term project: as such, the drivers for this effort shouldn’t be just technical or the desire to use the latest technologies, but the need to improve the business and the organization.

I would recommend some outcomes to argument in favor of this effort:

• Adoption of New Technologies: the legacy application is probably using old technologies, and it is not possible to upgrade them without breaking the application. The new application will be built using the latest technologies, and it will be easier to upgrade them in the future.
• Improve the Readability of the Codebase: the legacy application is probably hard to understand and maintain, especially for newcomers, who would need a lot of time to get familiar with the codebase, resulting in a slow onboarding process. The new application will be easier to understand and maintain, and it will be easier to onboard new developers.
• Improve the Testability of the Codebase: the legacy application is probably hard to test, and it is not possible to write automated tests for it. The new application will be easier to test, and it will be possible to write automated tests for it, resulting in a more reliable application.
• Improve the Performance of the Application: the legacy application is probably slow, and it is not possible to improve its performance without breaking it. The new application will be faster, and it will be possible to improve its performance in the future.
• Improve the Scalability of the Application: the legacy application is probably not scalable, and it is not possible to scale its functions without employing a lot of time, while a new designon will be able to be scaled easily it in the future.

The Legacy Application

Before the mainstream introduction of patterns and practices like DDD, SOLID, TDD, etc., developers used to write code in a procedural way, with a lot of code duplication, and with a lot of business logic in the UI or presentation (eg. APIs) layer. Furthermore, the lack of analysis of the business domain, the lack of definition of clear bounded contexts, and the lack of communication between developers and domain experts, resulted in a codebase that is hard to understand and maintain.

It is quite common in applications that have been written in such a manner to find the following issues:

• Lack of Separation of Concerns: the codebase is not organized in a way that allows to separate the business logic from the infrastructure, and the business logic is often mixed with the infrastructure code.
• Lack of Abstraction: the codebase is not organized in a way that allows to abstract either the business logic, the data access, or the infrastructure, hindering the possibility to replace or scale them.
• Incorrect Layering: presentation layers often contain business logic, and business logic, or even data access is operated in these topmost layers, making the code not reusable from other applications.

Analysis of the Legacy Application

In most of the cases that require the refactoring of a legacy application, the codebase is not documented, and the developers who wrote it are not available anymore, so the only way to understand the application is to analyze the codebase.

Also, many times the choices of the developers who wrote the application are not clear, and it is not possible to understand why they made those choices: they might not have been informed or trained on the patterns and practices that are used to write maintainable code, or they might have been forced to use a specific technology or architecture by the management.

This analysis should be done by a team of developers, and it should be done in a way that is not disruptive for the business, so it should be done in parallel with the development of new features and bug fixes.

Definition of the Bounded Contexts

Before the refactoring of the legacy application can start, it is necessary to define the bounded contexts of the business domain, and to define the relationships between them.

This aims to define a set of containments for entities, value objects, and aggregates that are logically part of a well-defined context, and that are related to each other, and eventually to define the relationships between these contexts.

For example, in a system that manages the orders of an e-commerce, the bounded contexts could be:

• Orders: The management of the orders places by the Customer of the e-commerce.
• Customers: The management of the entities (individuals or organizations) that acquire products and services of the e-commerce, and it is related to the bounded context of the Orders.
• Products: The products and services that are sold by the e-commerce, and it is related to the bounded context of the Orders and Customers.

Definition of the Entities, Value Objects, and Aggregates

Once the bounded contexts have been defined, it is necessary to define the entities, value objects, and aggregates that are part of each bounded context, so that it is possible to define a coherent model of the business domain.

It is not uncommon that the legacy application analyzed has already some prototypes of entities, and even aggregates, but they are generally not defined in a way that is coherent with the bounded contexts, and they are not related to each other, or even that the developers who wrote the application didn’t know about the concept of entities, and they didn’t define the application objects coherently.

For example, in the bounded context of the Orders, the entities could be:

• Order: The entity that represents an order placed by a Customer.
• OrderItem: The entity that represents an item of an order, and it is related to the Order and Product entities.

While examples of value object could be:

• Amount - The value object that represents the amount of an order, and it is related to the Order entity, calculated as the sum of the amounts of the OrderItem entities.
• Quantity - The value object that represents the quantity of an order item, and it is related to the OrderItem entity.

In this case, the Order entity is to be considered also an aggregate, since it contains the OrderItem entities, and it is the only entity that can be accessed from the outside of the bounded context.

Domain Events and Integration Events

Once the entities have been defined, it is necessary to define the domain events that are related to them, and that are used to communicate the changes of the state of the entities to the other bounded contexts.

The typical approach to design domain events (those exchanged within the same domain) is through the methodology of the delta events, which consists in defining an event for each change of the state of an entity, and that contains the information about the change, not the new state of the entity.

In fact, this allows the minimization of the size of the information exchanged, that other components of the system might not need, and it allows to avoid the duplication of the information, that might be already available in the other components of the system.

These are not to be confused with the integration events, which are used to communicate the changes of the state of the entities to the other bounded contexts, and that contain the new state of the entity: they are richer and bigger, and they often contain the full information of the entity, and not just the information about the change.

Events play a fundamental role in the communication between the bounded contexts, to trigger the execution of the business logic of the other bounded contexts, and they are used to avoid the coupling between the bounded contexts, and to allow the scalability of the application.

The Application Architecture

It is quite often that the architecture of the legacy application is a monolithic one, with a single codebase that contains all the code of the application, and that is deployed as a single unit.

This architecture is not suitable for a complex organization that aims to scale fast, and provide continuous delivery of new features and bug fixes, because it is not possible to scale the application, and it is not possible to deploy new features and bug fixes without deploying the whole application.

Adopting an architecture of the application that is based on microservices, with a set of services that are deployed independently, and that communicate with each other using a messaging system, will allow the organization to scale the application, and to deploy new features and bug fixes without deploying the whole application.

NOTE: Not in all cases this choice is the best one to take, since it might result in an exponential increase of the complexity of the organization, that might not be suitable for companies of just few people.

The Strangler Fig Pattern

The Strangler Fig Pattern is a pattern that is used to migrate from a monolithic application to a microservices architecture, and it is based on the idea of a strangler fig tree, that grows on another tree, and it slowly strangles it, until it replaces it.

Adopting this pattern requires to create a new application that will replace the legacy application, and to migrate the features of the legacy application to the new application, until the legacy application is not used anymore.

This dynamic is typically required when the legacy application is not possible to be refactored, because it is highly coupled, and it is not possible to extract the features of the application in a way that they can be refactored independently.

The Strangler Fig Pattern in Practice

On a high level, the Strangler Fig Pattern can be implemented with a game of routing:

1. Create a new application that will replace the legacy one.
2. Use an API Gateway to route the requests to the legacy application or the new one, based on the features and/or versions that have been migrated to the new application.
3. Migrate the features of the legacy application to the new one, and update the API Gateway to route the requests to the new application.
4. When all the features of the legacy application have been migrated to the new application, the legacy application can be decommissioned.

This approach allows to migrate the features of the legacy application to the new one, without having to stop the development of new features and bug fixes, and without having to stop the deployment of new features and bug fixes.

It has to be clarified that this pattern doesn’t apply only to the migration from a monolithic application to a microservices architecture, but it can be used also to migrate from a legacy application to a new one, even if the architecture of the new application is not a microservices one: this could be the case when it is not possible to evolve the legacy application, and a new one has to be created.

How to Deal with the Human Factor

The refactoring of a legacy application is not just a technical task, but it is also a human one, because it requires to deal with the developers who wrote the legacy application, who might feel under attack, and they might not be happy to see their work being refactored.

It is important to involve the developers who wrote the legacy application in the refactoring process, and to make them understand that the refactoring is not a way to criticize their work, but it is a way to improve the business and the organization: good developers will understand this situation, and they might recognize they didn’t have the knowledge to write a better application, and they might be happy to learn new patterns and practices.

In most of the cases, the codebase of an application is the result of several years of development, by several developers, which was inherited by the current teams, who might have not been happy themselves to write code in that way, but they didn’t have the time to refactor it, because they were busy with the development of new features and bug fixes.

In fact, a typical event-driven architecture uses highly performant messaging systems, generally deployed within the same network of the applications sending and receiving those kind of messages, also to reduce security and performance concerns. However, the typical use case of webhooks is to export such event model outside the boundaries of a system or platform network.

Domain Events and Integration Events

In the context of a distributed system, events can be classified into two main categories: domain events and integration events.

Domain events are used to model events that occur within the boundaries of a single service or application: they are generally used to notify other components within the same system about changes in the state of the application. For example, a domain event might be triggered when a user places an order in an e-commerce application, or when a new customer is added to the database.

Integration events, on the other hand, are used to model events that occur between different services or applications: they are generally used to notify other systems about changes in the state of the application. For example, an integration event might be triggered when a user places an order in an e-commerce application, or when a new customer is added to the database.

What are Webhooks?

Webhooks are a lightweight and flexible means of communication used to notify systems about specific integration events or trigger actions: unlike traditional request-response mechanisms, webhooks follow the publish-subscribe pattern, where a sender (known as the webhook provider) sends HTTP POST requests to a specific URL (known as the webhook endpoint) when an event of interest occurs. The receiver (known as the webhook consumer) listens to these events and responds accordingly.

It is the responsibility of the webhook provider to manage the subscriptions to certain events, and ensure that the webhook consumer is notified when an event that matches the subscription occurs that same consumer is notified at the endpoint URL: this might involve several retries, and the webhook provider should be able to handle errors and failures gracefully.

How to Use Webhooks to Activate Asynchronous Designs

Webhooks are an excellent tool for enabling asynchronous designs within an integrated architecture: by using webhooks, services can be decoupled, allowing them to communicate with each other without the need for synchronous request-response interactions.

When an event occurs in a platform, the webhook provider can notify all interested consumer applications simultaneously, enabling parallel processing and reducing latency.

A typical webhook payload, since its nature of integration event, also provides contextual information about entities and the occurrence, allowing the webhook consumer to process it accordingly: for example, an e-commerce application might send a webhook notification when a customer places an order, including details such as the order ID, customer name, and shipping address. The webhook consumer can then use this information to update its internal state and trigger other actions, such as sending an email confirmation or updating the inventory.

Webhooks allow systems to scale more effectively by handling events asynchronously. Following the example of the e-commerce application, when a customer places an order, the webhook provider can trigger an event that notifies the inventory management system, the payment gateway, and the shipping system simultaneously. Each system can independently process the event without waiting for the others, leading to improved performance and scalability.

Deveel Webhooks

Deveel Webhooks is an open-source .NET framework that simplifies the implementation and handling of webhooks in .NET applications.

The framework is intended for someone who is looking to implement *-as-a-Service (*aaS) solutions, where the service provider needs to expose webhooks to notify consumers about events occurring in the service. It provides a simple and intuitive API for configuring and managing webhooks, allowing you to focus on the business logic of your application rather than dealing with low-level HTTP interactions.

Components of the Framework

The framework provides services at various levels of abstraction, allowing you to choose the level of control you need for your application:

• Webhook Subscriptions: the framework provides a generic interface for managing subscriptions to webhooks, allowing you to store them in a database or any other storage medium of your choice. It also provides a default implementation of the interface that uses a MongoDB database for storing subscriptions.
• Webhook Notifications: it also provides a generic interface for sending notifications to consumers that have subscribed to certain events, allowing you to implement your own webhook provider. It also provides a default implementation of the interface that uses the ASP.NET Core HTTP Client for sending notifications.
• Webhook Sender: assuming you are willing to implement your own webhook subscription and notification services, or extending the default contracts, the framework provides a generic interface for sending notifications to consumers that have subscribed to certain events, allowing you to implement your own webhook provider.

Using Deveel Webhooks in Your Applications

You can read more about how to use the framework in your applications in the documentation, but the following example shows how to configure a webhook provider in your ASP.NET Core application, to start accepting subscriptions and notify consumers about events:

public class Startup {
  public void ConfigureServices(IServiceCollection services) {
    services.AddWebhookSubscriptions<MongoWebhookSubscription>(options => {
      options.UseConnectionString("mongodb://localhost:27017");
    });

    services.AddWebhooksNotifier<MyWebhook>();
  }
}

The above example shows how to configure the framework to use a MongoDB database for storing subscriptions, and a custom webhook implementation for sending notifications to consumers: the framework provides a default implementation of the IWebhook interface, but you can also implement your own if you need to customize the behavior of the webhook provider.

This assumes that you are using the same instance of an ASP.NET Core application to implement both the webhook subscription management and the notification service: if you are using separate instances, you can use the AddWebhookSubscriptions method to configure the webhook provider in one application, and the AddWebhooksNotifier method to configure the webhook notifier in an second one, to obtain a better scalability of resources (suggested option).

Event Transformations

In some scenarios you might need to transform the event payload before sending it to the consumer: for example, you might need to add additional information to the payload, or change the format of the data.

The framework provides a generic interface for implementing event transformations, allowing you to implement your own transformation logic, based on the type of event you are sending to the consumer.

Note: please consider that the above example refers to the current version of the framework (v2.1.5), and it might be subject to changes in the future: it is always recommended to refer to the documentation for the latest information, since at the time you are reading this post, the framework might have been updated.

Refer to the GitHub repository of the framework for more information about the project, and how to contribute to it.

Webhooks and CloudEvents

CloudEvents is a specification for describing event data in a common format, making it easier to integrate systems that use different event formats. It provides a standardized way to express event metadata and payload, ensuring interoperability across various platforms and programming languages.

The main purpose and scope of use of CloudEvents is anyway still limited to the boundaries of a single network, and it doesn’t provide any specification for the transport of events outside the boundaries of a system or platform network.

Deveel Webhooks and CloudEvents

The Deveel Webhooks framework doesn’t provide any specific implementation of the CloudEvents specification, since it is intended to be used as a general-purpose framework for implementing webhooks in .NET applications: however, an outstanding feature request is to provide a CloudEvents implementation for the framework, to allow developers to use the framework in conjunction with other CloudEvents-compliant systems.

It is a luxury problem of small organizations that are successful and need to be supported in their natural growth, because no organization is self-sustaining: external parties, such as investors or suppliers, will begin to require a clear strategy, a clear vision, and a clear direction, forcing a joyful and immature organization to mature and become a serious one.

The Immaturity of Management

Management immaturity is a well-known problem in the startup industry, and it is a natural result of the founders being typically relatively young, with little or no experience managing a firm and with little or no experience managing people. This is a challenge that is typically remedied by recruiting experienced managers to assist the founders in maturing and managing the company, but this is not always the case, and the founders are occasionally left alone on this trip.

One issue that develops in this situation is that the founders are usually very passionate about their idea, and they are very focused on the product, the technology, and the solution that they are producing, rather than the financial side of the organization. This is a very typical problem, and it is usually managed by hiring a CEO to handle the company’s business while the founders focus on the product and technology.

Another situation that is completely unique to the previous one is when the founders are extremely passionate about the business side of the company but are uninterested in the product, technology, or solution that they are developing. This is a very common issue, and it is usually solved by hiring a CTO to oversee the product and technology while the founders concentrate on the business side of the company.

In any case, the pathological condition resulting from both situations is the general diversion of the company and its management from the original vision and strategy, causing general confusion and a general lack of direction, which is a dangerous situation for a startup because it can lead to a general lack of focus, and eventually to the company’s failure.

Growth Pain

In recent years, I’ve been involved in a couple of instances that exhibited the aforementioned patterns, and I’ve witnessed the implications of a lack of a clear strategy and vision for the company, or even a diverging view among the rest of the management.

Both organizations desired to establish more stable and planned growth in order to attract more investors and lay a more solid foundation for the company’s future, but they didn’t really know what this meant or how to achieve it: they were both in a situation of growth pain, where the company was growing but the management was unable to manage this growth, and the company was in a state of general confusion and lack of direction.

Sudden Change in Management and Strategy

In one of these experiences, I was hired to assist the company in establishing a more solid foundation for the Enterprise Architecture, its processes, functions, systems, and data, which also meant establishing a more structured and governed environment: something that contradicted the original vision of one of the founders, who had a poor understanding of the discipline, a generally negative attitude toward it, and a general lack of trust in the people involved in the initiative.

The rest of the founding members were skeptical of the practice, despite not being opposed to it, having worked in large organizations, albeit in roles that suffered the development and governance processes by nature: sitting on the riverbank, they were waiting to see some concrete results before committing to the initiative.

In this context and culture, I could see all of the negative and pathological manifestations of a Agile Manifesto utopia, with several teams working on concurrent matters, using different tools and processes, with little or no coordination between them, and with a general lack of direction and focus: despite the IT department’s moderate size (less than 100 people), and with no cases of acquisitions, the proliferation of systems, libraries, and solutions was immeasurable.

External factors influencing the company’s product performance prompted the board of directors to replace the CEO and several other members of the management team, some of whom were sponsoring the growth strategy and the consolidation of Enterprise Architecture: the new strategy was to shrink the organization’s investments and path to maturation, removing several of the System of Records and System of Engagement that were in place.

Eventually, the majority of the IT staff left, and the firm was compelled to rebrand itself in order to have a fresh start with the remaining personnel (albeit none of my former colleagues are now employed there).

Knowing What you Want / Need

Another example of such ambiguous strategy was presented to me when I was scouted by a promising startup, recommended by a good friend who turned down the offer first, to be their new CTO, to replace the one who abruptly decided to quit the position: they were a very young company, with management coming from mixed experiences and backgrounds, and facing the situation of investors requiring them to shape up their IT strategy, cost analysis, vision, and direction.

In fact, the qualifications for the new post they were searching for were mixed, because a lot of emphasis in their prospects was placed on strategic vision, analysis, and IT strategy (with a strong emphasis on knowledge of cloud technologies).

After a good interview with the HR (and co-founder), where we discussed the reason, vision, and personal experiences, I was invited to a second interview with the COO, where we discussed the technical aspects of the role, as well as the company’s expectations: the COO was very clear that the company was looking for a hands-on person, who could help them in the transformation of the company, and in the consolidation of the IT department, with a strong emphasis on cloud technologies.

As a last step of the process, I was scheduled an interview with the CEO of the startup: a surprisingly short one (less than 30 minutes), where the person clearly stated not being a technical expert, and that he didn’t know what the company needed in respect of the IT, but he wanted that the mobile application to be faster: learning of my limited front-end skills, the interview was more of less over, and we agreed I was not the person he was looking for, although I stated my recommendation to reconsider the requirements of the role, and to focus on the strategic vision and IT strategy aspects, rather than on the barely research of a front-end developer as a CTO.

In fact the above experience proves some of the issues in the management of a startup:

• Lack of communication between the founders on the vision for the company - while for two of them long-term vision was the focus, the third one was looking for a quick fix to an immediate issue.
• Lack of humility in the management, accepting there are areas of competence they might not be experts in - for example, in this case the likely causes for the slowness of the mobile application were issues in the back-end, rather than in the front-end: network misconfigurations in the load-balancer/gateway, database design issues, location of the infrastructure, etc.
• Poor knowledge of the real functions of roles and responsibilities in the IT department and of the real needs of the company_ - the company was not really looking for a strategist, but in reality they were looking for a front-end developer (glorifying the position as CTO) to fix an immediate issue

Follow-Up of a Failed Process

The week after the above mentioned final interview, it was announced by the company the person who was hired for the role: a young full-stack developer with little experience in cloud technologies, and with no experience in strategic vision and IT strategy, and 5 years in the industry: a profile fitting the immediate needs of the company, but not the long-term ones.

In fact after approximately four months from that announcement I was reached again from the HR (and co-founder), who initially interviewed me, to ask me if I was still interested in the role, since the person hired was not able to deliver the expected results, and they were looking for a replacement.

You can imagine my answer…

Heroes, Rockstars and Ninjas

The mythological figures of the heroes who jumpstart companies, despite the lack of security, and animated by the entrepreneurial spirit of the Western Explorers is fantastic, appealing, fascinating, but it is also a dangerous myth, since it is not realistic, and it is not sustainable in the long term.

When the initial spirit of adventure is turning into the need of a consistent and sustainable growth, the company needs to change its approach, and to start to think in a more structured and planned way, and to establish a more solid foundation for the future: the fun part of jumping without a net is over, and the company needs to start to think about the future, and to plan for it.

Sometimes I make the comparison between starting up an organization with starting a rock band: it is fun at the beginning, and mostly executed in the spare time, with other regular jobs sustaining the living of the members, but when the band starts to get some traction, and the members start to think about a career in music, they need to start to think about the future, and to plan for it. Only few bands ultimately succeed, cause the members, even not liking each other’s, are able to put aside their differences, and to focus on the common goal: the success of the band.

Some rockstars might even have success through a destructive path, with a sudden and unplanned success, but the majority of them will fail, and will be forgotten, and the same is true for the heroes of the startup world.

The Dynamics of Resume Based Development

Organizations with an established agile software development process are more susceptible to encountering a resume-based development approach. This vulnerability arises due to the significant autonomy afforded to agile teams in determining both what to build and how to build it.

One of the fundamental skills to seek in a developer is the ability to learn new technologies and frameworks. Consequently, developers are frequently provided with opportunities to acquire these skills. Regrettably, this sometimes results in the adoption of trendy and hyped technologies and frameworks that do not serve the immediate problem.

Occasionally, this choice is motivated by a genuine desire to equip the organization with a modern, future-proof solution. However, in many instances (as per my experience, the majority), it represents a self-serving decision aimed at enhancing the developer’s resume for internal career growth or external job prospects.

Overengineering Solutions to Problems

Assuming a well defined structure of an agile team, where the product owner has a clear vision of the product and good grip on the marker, the implementation of the service(s) that provide the functions of the product is left to the team, in which one of the developers is generally the architect, meaning the one who ultimately makes the architectural, technical, decisions.

In this phase of inception, the acting architect might use the opportunity given by the green field solution to experiment with new technologies and frameworks, which is not necessarily a bad thing, but it can lead to the adoption of a solution that is not the best fit for the problem at hand.

I had to face myself several occasions where the implementation of a service was overengineered to experiment with a new technology, implementing quite simple requirements with a very complicated and unknown approach, or even worse not achieving the goal at all.

The Impact on the Organization

{: .align-center }

Working with mature technologies and frameworks surely provides benefits like predictability, support, patterns, while at the contrary adopting innovative approaches to the implementation of services introduces a lot of uncertainty and risk.

Product managers, product owners, and business analysts, are often not aware of the technical implications of the choices made by the team, and they are not able to assess the risk of adopting a new technology or framework, which is often not even mentioned in the requirements: here the relationship and trust between parties is key to avoid the adoption of a solution that is not the best fit for the problem at hand.

The uncertainty and risk associated with the adoption of new technologies often lead to a slower development pace and, in the worst-case scenario, project failure - a significant waste of both time and resources for the organization.

The CQRS and Event Sourcing Example

A few years ago, before CQRS became a well-known pattern, I encountered a situation in which one of the developers responsible for the architecture of a critical security component, vital for the large-scale solution I was working on, chose to implement it using CQRS and Event Sourcing as a greenfield solution, contrary to my recommendations to rely on mature technologies such as Active Directory.

None at that time, either within the organization or in the industry, knew CQRS and Event Sourcing well, and I had to study the pattern myself, to understand the implications of the choice made by the developer: given the uncertainty and risk introduced by the adoption of a new pattern, and the lack of any vendor to support it (in fact, the developer himself implemented a framework to support it), I asked him and the organization to desist and adopt a more mature technology, but I was overruled.

Two years passed by, through implementations, experiments, failures, without the component to ever be functional, with an enormous waste of time and money for the organization, and with the developer to leave the organization, leaving the component in a state of limbo.

Ultimately, the organization decided to scrap that component from the architecture and to adopt a more mature technology, with a reputational damage for those who supported the expense to support and immature technology, to implement a component from ground up, not representing the core business of the organization, and even failing to deliver it.

The Architecture Bias

Superficially, some organizations consider the role of an architect just the realization of designs and diagrams, to provide a set of work packages to the developers, and to review the code produced, with a naive approach to what the deliverables of an architecture should be. Some organizations even consider the role of an architect as a senior developer, who is not involved in the complex assessments of IT strategy and IT governance, worried that this might slow down the delivery of the product.

Being an architect is not just about dealing with code patterns, performance and scalability, but it is also, and more prominently, about considering the whole context in which a service or a component is introduced, the IT strategy of the organization, the costs failures and recovery: in many occasions, these responsibilities have been stripped out of the role of an architect, and the role has been reduced to a senior developer. Or even worse, some developers have been granted the title for internal career advancement, without the proper skills and experience.

I am not exonerated from this bias, since I must confess that I failed myself in the past to consider what the architect role meant with this regard, and I have been guilty of the resume based development approach myself, at least in one occasion: we learn, we grow, we improve, we share our experience with the aim of helping others to avoid the same mistakes.

Architects Make it Boring

One of the main criticism towards architects is that they make things boring, and this is true: architects are not there to make things exciting, but to make things work, and to make things work in the most efficient way, with the least amount of risk and uncertainty.

The choice of adopting new technologies and patterns to implement a service is not necessarily a bad thing, but it should be done with the right approach, with the right assessment of the risk and uncertainty, and with the right support from the organization: impact of a failed delivery ripples its effects through the whole organization, and it is not just a matter of the reputation of the architect, but of the whole cohort of people involved.

The Innovation Stream

Developers are generally (and hopefully) attracted by innovation, experimentation, and learning: being in a job where you can be excited by the opportunity to learn new technologies, free from the burden of risk, is a key motivator for developers to join a company, grow with it and stay.

Regrettably, the adoption of new technologies and patterns does not always proceed smoothly, and success is not guaranteed. While offering a secure environment for innovation within the organization is vital for attracting and retaining talent, it is equally crucial to prevent the adoption of new technologies and patterns from being solely driven by the resume-based development approach.

Mature organizations allocate resources and time to the innovation stream, where product development teams feel safe to experiment with new technologies, evaluating their complexity and risks, learning from the experience, and sharing the knowledge with the rest of the organization.

Implementing such a process is an important investment for an organization, which is not assured to provide a return, and it cannot be taken lightly: in fact, only few large organizations can afford to have such a process in place, and it is not a surprise that they are the ones that are able to attract and retain talents.

Unfortunately, the vast majority of organizations should instead accept to rely on mature technologies and patterns, and to provide their developers with the opportunity to learn new things in their spare time, or by attending conferences and meetups, or by providing them with a budget to attend courses and training: in such contexts product owners and architects act in their role of governance trying to reduce risks from the adoption of innovative technologies that are not proven to be the best fit for the problem at hand.

The design of the overall architecture of the systems, applications and services consisting the organization is usually the result of a single vision, which is often the result of the founder’s experience and knowledge, and the result of the first implementations of the organization: these are usually easy to change, adapt, and evolve, since they are owned by a single person or a single team.

In such a scenario, the enterprise architecture is usually not a concern, since the organization is still small and the systems are not yet complex enough to require a dedicated function, the technological stack is usually homogeneous and the communication between the different components is direct and simple.

Moving to the Next Level

When the organization starts to grow, the number of people involved in the development of the systems increases, and the number of systems and applications increases, the complexity of the overall architecture increases, and the need for a dedicated function to manage it becomes more and more evident.

To such a complexity and growth pain, it is usually added the need to maintain the existing systems, which are usually not designed to be easily changed, since they were typically implemented to serve an immediate need, and not to be part of a long-term strategy: such systems are usually called legacy systems, and they are usually the most difficult to change, since they are the result of a legacy architecture.

In several situations, I found myself approaching the source code of some of these applications, to trying make sense of the design choices, and I found myself wondering ‘what were they thinking?’. In fact, the design of such systems is usually the result of a design by committee approach, where the different stakeholders of the organization, with different backgrounds, knowledge and objectives, have contributed to the design of the system, without a clear vision and strategy. In addition to this, it is typical that the most senior technical figures who led the design of such systems had no training in the best practices of software design, and they were usually the most senior developers, who were promoted to the role of technical lead or architect.

Anyway, organizations who grow face new problems and challenges, often underestimated and not considered in the initial design of the systems, and they are forced to adapt and evolve the architecture of their systems, to make them more resilient, scalable, maintainable and secure.

For example, a growth in the number of users of a system might require to scale the system horizontally, to increase the number of instances of the application, to serve the increased number of requests, or to scale the system vertically, to increase the capacity of the existing instances, to serve the increased number of requests, or to acquire services from external providers, terminating some functions currently implemented in the system.

The Emergence of Architectures

The evolution of the architecture of the systems of an organization is usually the result of a series of emergent designs, which are the result of the emergent behaviors of the organization, and not of a single architectural vision.

As much as one might want to academically state that the architecture of an enterprise can be clearly defined and designed, the reality is that the architecture of an organization is the result of the emergent behaviors of the organization itself: choices are taken by decentralized teams, with the ambitions of solving the problems they are facing, and not of designing the overall architecture of the organization.

These dynamics within the organization are usually the result of the Conway’s Law, which states that

‘Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations’

Such a dynamic is particularly observable in Agile organizations, where the teams are self-organized and autonomous, and they are not constrained by a centralized architecture function, producing a multitude of services and applications which implement each one a specific set of patterns and practices, reflecting the skills and knowledge of the team who designed and implemented them, rather than a coherent and consistent architecture.

Enterprise Architects who belong to such organizations should resist the impulse to rationalize and operate any military force to restrain such movements, frustrating the values and mission of the organization, that intentionally has chosen such technical paths, but rather try to make sense of the emergent architecture, trying to identify the patterns and the commonalities between the different systems, and trying to identify the best practices and the standards to be applied to the different systems.

I never found it productive trying to impose a top-down approach to the design of the architecture of an organization, going against the existing asset of people, skills and systems, but rather trying to influence them, by providing the teams with the right tools, standards and best practices, to make them more effective and efficient, communicative and collaborative.

Mixing Intentional and Emergent Architectures

As mentioned above, successful organizations grow and evolve, and with them the enterprise architecture of the systems they are composed of: this means that large portions of the functions implemented internally (eg. CRM, ERP, communications, etc.) are usually replaced by external services, externalizing costs, risks, resources, and focusing on the core business of the organization.

In such a scenario, the core function of Enterprise Architects is to design intentional architectures, setting the target for the integrations and the interactions between the different systems, assessing ahead of time the target state of the final architecture, and then working with the different teams to implement the required changes.

How can then a successful organization can mix the intentional architecture with the emergent architecture?

The answer I have given myself (without any ambition of being the right one), is to make intentional architecture as emergent, providing the teams with the right tools, standards and best practices, to make them more effective and efficient, communicative and collaborative, so that the skillset of the teams can be leveraged to design and implement the architecture of the various components forming the target architecture, achieving a good level of buy-in from the various parts of the organization, especially those who are more resistant to change (such as the development teams, who are usually more focused on the short-term objectives, rather than the long-term ones).

Collaborative Design

Although it is not always possible to control precisely the design of the architecture of an organization, it is anyway possible to influence it, by providing the teams with the right tools, standards and best practices, to make them more effective and efficient, communicative and collaborative: ultimately, the sharing of the common knowledge, patterns, practices and standards, will make the teams more effective and efficient, and will make the architecture of the organization more consistent and coherent.

For an organization, keeping the set of principles, standards, technologies (aka the “IT Strategy”) consistent is a matter of cost control, investment opportunities, resource management, and ultimately of technical debt: the more the organization is able to keep the IT Strategy consistent, the more it will be able to control the costs of the systems, the investments in new technologies, the management of the resources, and the reduction of the technical debt.

Managing the Expectations

The core aspect to manage when applying such an agile approach to enterprise architecture is the expectations of the stakeholders of the organization, who are usually looking towards a clear and defined architecture, with a clear and defined roadmap, and not an emergent architecture, which delegates responsibilities of the design to the teams, low in the organization chart and level of details, introducing insecurity and uncertainty.

One of the key aspects considered by mature management of an organization, when hiring an Enterprise Architect, is to remove the unpredictability of target states of the IT landscape, and to reduce or eliminate the uncontrolled fluctuation of costs, things that ideally require a full control of the architect over the whole set of technologies, development processes, infrastructures and possibly people: something that is in contrast with the agile approach to enterprise architecture, where the architect is not the one who designs the architecture, but rather the one who coordinates the design process, and the one who provides the teams with the right tools, standards and best practices, to make them more effective and efficient, communicative and collaborative.

I have also generally observed (and it’s part of the academic literature on the matter) that teams, rightfully, tend to refuse the responsibility of design an overall architecture that is not under their immediate control, and that they are not able to influence: this is a natural reaction to the fear of being blamed for the failure of the architecture, and the fear of being held responsible for the consequences of the design choices, especially when the teams are not involved in the decision making process.

The Role of the Enterprise Architect

Without frustrating the agile ambitions of the organization, the management should then expect an Enterprise Architect to work as a facilitator of the emerging designs of the single parts of the overall enterprise architecture, without any ambition that he/she would be able to control the various parts in details.

The concept of “architecture” was imported into software development from the construction industry, where the architect is the one who designs the building, and then the construction workers are the ones who build it, following the design of the architect: this parallelism had (and in some, very niche, contexts still has) a meaning following the waterfall approach to software development, where the design of the architecture is done upfront, and then the development teams are the ones who implement it, following the design of the architect.

In today’s Agile world of IT, the design of the architecture is not done upfront, but rather it is done emergently, and thus the role of the Enterprise Architect has changed as well, becoming a coordinator of the design process, rather than the designer: that is something to be communicated and understood by those organizations who strive in situations where agility is perceived as a necessity to attract talents, but on the other hand they are suffer the consequences of such choice (eg. lack of control, lack of visibility, lack of predictability, etc.).

The Service Oriented Architecture (SOA) Pattern

The Service Oriented Architecture (SOA) is an architectural style that defines the use of services to support the requirements of software users. A service is a self-contained unit of functionality, such as retrieving an online bank statement: by that definition, a service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online.

Such a model has been used for several years in the enterprise world, but it has been often misused and misunderstood. The SOA is not a technology, but an architectural style, and it is not a silver bullet for all the problems of the enterprise world. It is a way to design and implement software systems that are loosely coupled, interoperable, and reusable.

According to the pattern, a system, or even an entire enterprise, can be composed by integrating several external services, which provide each a portion of the information and the functions needed to implement a business process. The services can be implemented using different technologies and can be deployed on different platforms, but they must be able to communicate with each other using a common communication protocol.

Nothing unknown to almost all of you who are reading until now.

The Microservices Pattern

_{Copyright © 2018 Microsoft - Designing and implementing API Gateways with Ocelot in .NET Core containers and microservices architectures}

The terminology “Microservice” first appeared in 2011, in a blog post by James Lewis and Martin Fowler, and it is a variant of the SOA architectural style. Summarizing the principles of the paper, the microservices architecture is a style of software architecture that has the following characteristics:

• The application is composed by several small services, each one running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
• Each service is built around business capabilities.
• Services are independently deployable.
• Services are independently scalable.
• Services can be implemented using different technologies.
• Services are owned by small teams.

As such, the overall ambition of the pattern is not to dictate any specific technology or solution for the implementation, but instead to provide a set of guidelines that can be used to design and implement a distributed application, focusing mostly on the concept of products, rather than projects, and enabling a greater agility in the development and deployment of the features.

The Evolution of the Microservices

Like many good ideas, the microservices architecture has been misused and misunderstood, and it has been often used as a synonym of distributed architecture, or distributed system, or service-oriented architecture. But the microservices architecture is not a synonym of any of these terms, and it is not a silver bullet for all the problems of the enterprise world.

In fact its adoption was helped by the emergence of technologies developed for the support of cloud-native applications, such as containers (eg. Docker), container orchestrators (eg. [Kubernetes]https://kubernetes.io), Service Fabric), and cloud platforms (eg. Azure, Google Cloud), which have been used to implement distributed applications, although they are not a requirement for the adoption of the pattern. Despite not being required, the majority of the IT practitioners implemented the microservices pattern by adopting a specific technological stack, heavily based on the Docker and Kubernetes components, with all its complexities and challenges, often without understanding the real orientation of the pattern.

Naturally, several of the critical aspects of a microservice architecture, such as the development and operational processes, the communication protocols, the data management, the security, and the monitoring, are not new, and they have been already addressed by the SOA architectural style, but the radical approach to define even smaller portions of a service domain, to be served independently, multiplied the complexity of the infrastructure needed to implement the pattern (service-specific databases, separated monitoring and alerting tools, multiple autonomous development and deployment processes), also to address the organizational change emerging from the philosophy of the pattern.

Containers, Orchestration, and Platforms

The adoption of containers, container orchestrators, and cloud platforms, has been a natural evolution of the microservices architecture, but it has been often misunderstood as a requirement for the adoption of the pattern. In fact, the microservices architecture can be implemented using any technology, and it can be deployed on any platform, but the adoption of these technologies can scale up the complexity for the development and deployment of the services.

Since the microservice is indeed a pattern, and not a specific technology, the architecture of a system might be respecting these principles through the adoption of provider-specific technologies (eg. Azure App Services, Amazon EC2 Instances, etc.), or even through the adoption of a monolithic architecture, where the services are implemented as libraries, and they are deployed as part of a single application: it is responsibility of an architect to define where the physical boundaries of a service are, and how to implement them.

Anyway, the usage of orchestration platforms to implement this pattern has been popularized by their alleged scalability and resilience, enhanced by the myth of cloud portability (the concept, never really achieved, of realizing an entire system resilient to the provider of cloud infrastructure, or even the on-premise provisioning), which instead turned up in practice to require more efforts to configure and maintain the infrastructure, to implement the services, and ultimately consisted of a parallel set of technologies to be learned and mastered.

Missed Business Opportunities

Some of the major arguments and drivers, from the business side of the IT, for the adoption of the microservices architecture, have been:

• Agility: the ability to develop and deploy new features faster, and to scale the services independently, without the need to coordinate the development and deployment of the entire system.
• Resilience: the ability to isolate the failures of a service, and to recover from them, without affecting the entire system.
• Scalability: the ability to scale the services independently, and to optimize the resources needed to run the system.
• Technology Independence: the ability to implement the services using different technologies, and to adopt the best technology for each service.
• Team Independence: the ability to assign a team to a service, and to let the team to develop and deploy the service independently.
• Business Independence: the ability to assign a business domain to a service, and to let the business to manage the service independently.
• Cost Reduction: the ability to reduce the costs of the infrastructure, and to optimize the resources needed to run the system.
• Cloud Portability: the ability to deploy the system on any cloud platform, and to migrate the system from one cloud platform to another.

As debated already in the previous paragraphs, some of these arguments have been proven by experience to be not so true, or at least not so easy to achieve, and the adoption of the pattern has been often driven by the hype of the technology, rather than by the real business needs.

In fact the hidden costs of setting up an organization that can handle a microservice architecture are often underestimated, and impact largely by surprise the business side of the IT, resulting in re-evaluation of plans, roadmaps, and budgets, and in the worst cases in the abandonment of the pattern, and the return to a monolithic architecture.

As much as from an IT Strategy standpoint the adoption of microservices can be a good choice, aimed to diversify the technology stack, opening to more opportunities in the market (people, technology vendors, cloud providers), the reality of the enterprise processes is to rely on a single set of technologies, skillset and vendors, to better forecast the costs and the risks of the business: such dynamics counters the arguments of Technology Independence and Cloud Portability, and it is often the reason for the failure of the adoption of the pattern.

Is It Worth It?

A couple of months ago (at the time I am writing this post), a team at Amazon made a lot of sensation in the industry, after the publication of an article titled Why Amazon Chose a Monolithic Architecture for Prime Video (and the related video), supporting the monolithic architecture of their new media service, that has been often used as a reference to argue the failure of the microservices architecture, and the superiority of the monolithic architecture.

Although this article has been a sort of relief for many architects and IT practitioners, frustrated by the development and operational challenges provided by the microservices architecture, including myself, I personally think that is too early to declare the failure of the pattern, and to return to the monolithic architecture for any kind of system.

Anyway, the pattern itself might still provide of high business value, independently from its technological implementation, especially in contexts of mixed technological stacks, such as in the cases of Merge & Acquisition, or in the cases of legacy systems, where the adoption of the pattern can be a good choice to modernize the system, and to open to new opportunities in the market.

One of the untold dynamics in the enterprise is indeed the primacy of the technology over the business, leading to weak positions of the business side of the IT, in favor of the development functions, who are more prone to experiment with new technologies, rather than to adopt the best technology for the business: to counter this dynamic, the business functions have over time introduced more and more agile processes aimed to involve developers into the decision making, and to align the technology with the business needs, but the reality is that the business is still often forced to adopt the technology chosen by the development functions, rather than the other way around.

What is a Microservice?

At the end of the day, I believe that the major misunderstanding of the microservices architecture is the definition of microservice itself, which is often confused with a service, or a component, or a library, or a module: the nature of the bounded context of the service is an unavoidable aspect of the pattern, and it is often overlooked, or misunderstood, leading to the implementation of a distributed monolith, rather than a distributed system.

In fact, several of the information and functions of a service are often shared with other services, and the boundaries of the service are often defined by the technology, rather than by the business domain, often leading to the re-implementation of the same existing functions, motivated by technological choices (communication efficiency within the same technology stack, modernization of the implementation), rather than by business needs.

It than becomes crucial to the successful implementation of the pattern to define the boundaries of the services, and to identify the business domains, and the business functions, that are the real drivers of the architecture, and to implement the services accordingly, rather than to follow the hype of the technology.