The Virtual Think Tank: Using LLMs to Get a Multitude of Perspectives

Author’s note: This article is based on extensive interaction with LLMs. Reading the LLM outputs can be quite tedious. When I feel it contributes significantly, the outputs of the LLM are included in an appendix. Otherwise the article includes only brief quotes. In any case, the reader is encouraged to try out the prompts on your LLM of choice. You might discover something surprising.

Introduction

Since ChatGPT and other LLMs have taken over the world by storm, I have been reading, speculating, writing and talking about how the LLMs might change the way we design software. We all know that LLMs are changing the world of software development dramatically.

Developers are making more and more use of LLMs when creating software, using smarter and smarter tools. It seems that the growth in that area is likely to continue.

Meanwhile the use of popular resources such as Stack Overflow is dropping as developers are no longer searching for communities or examples, rather they are just asking the LLMs to write the code. Many of these LLMs such as GitHub Copilot are embedded directly into IDEs.

To a large extent, it seems like the code being created is syntactically and functionally correct and often clear and conforming to accepted standards.

However, there are other aspects to software development beyond coding, such as design and architecture. We know that architecture is often the art of trade-offs.

As such, when it comes to architecture decisions, there is no one correct answer, rather a multitude of possible answers that need to be considered and choices (often tough ones) to be made. Considering these trade-offs, and arriving at the right decision is often considered to be the hard part of building software.

To see how LLMs can be used for architecture and design, something I have been exploring and experimenting with is the idea of a “Virtual Think Tank”. This article describes what a Virtual Think Tank is, and how to make use of it, along with an example that highlights some interesting results I’ve observed.

Virtual People vs. Real People

When doing system architecture, I alone do not have the experience, depth and breath needed to solve every problem or challenge that comes my way. The resources I use are books, online blogs, articles and other people. (I do not consider search engines to be a “first class resource” rather it is the search engine that helps me find and access the other resources.) Of all resources available to me, I find other people to be the most helpful. Other people are experienced, diverse, smart and eager to help. When I consult another person, I am asking her to apply her experience and intuition to my problem or situation. And she will often do it well.

However the problem with other people is often one of “availability”. Other people are not always available to me when I need them. By available, I mean available in “time” as well as able to afford the attention and mental capacity needed. Other people have lives and priorities of their own, and if they are good at what they do, they are often very busy or at least too busy to give me the attention I am requesting.

That is where LLMs come in. I recently started relying more and more on LLMs as a resource. And even though the LLM is NOT another person and does not have the full range of experience or empathy that a person might have, an LLM has the huge advantage that it is always available. (Architects love looking for trade-offs.)

One of the ways that an LLM can be used is to be asked to adopt a persona. This persona can be generic or specific, as shown in the following sample prompts.

Prompt>> “You are an experienced software engineer. Your concerns are code that is clean and easy to write and maintain, and writing code that is as fast as possible. Please write an implementation of a B-tree in C. Provide detailed explanations on each step”

versus

Prompt>> “You are Donald Knuth. Please provide an implementation of a B-Tree along with detailed explanations”

I tried the above prompts with several LLMs (ChatGPT, Gemini, Claude). In all cases, both prompts resulted in what seemed correct functioning code. (I did not fully test the code for functional correctness. Never assume code generated by LLMs is correct.) However, when I asked the LLM to adopt the Donald Knuth persona, I found several new things.

• Depth and Thoroughness: Donald Knuth is famous for his meticulous attention to detail, particularly in his seminal work, “The Art of Computer Programming”. It seems that this prompted the LLM to create a more comprehensive implementation with detailed comments explaining each aspect of the algorithm, including error handling and various edge cases.
• Academic Approach: The LLM adopted a more academic and educational tone in the explanations, focusing on the theoretical underpinnings of B-Trees rather than just providing a working solution.
• Algorithmic Focus: I find that the LLM emphasized algorithmic correctness and clarity over implementation shortcuts, similar to how Knuth approaches algorithms – with mathematical precision and careful consideration of edge cases.
• Implementation Completeness: The LLM provided a full, working implementation rather than pseudocode or simplified snippets, reflecting Knuth’s preference for complete, analyzable algorithms.
• Historical Context: The LLM included the fact that B-Trees were invented by Bayer and McCreight in 1971, showing awareness of the historical development of algorithms that Knuth is known for documenting.

For example, when adopting the persona of Donald Knuth, Claude said:

B-Trees are self-balancing tree data structures that maintain sorted data and allow searches, insertions, and deletions in logarithmic time. They were invented by Rudolf Bayer and Edward M. McCreight while working at Boeing Research Labs in 1971.

(The reader is encouraged to try these are similar prompts for themselves on their LLM of choice.)

As we can see, the responses are useful and provide much more than correct and efficient code. They provide context similar to the way a person might provide context.

A very interesting thing I noticed is that even though I did not request a specific programming language, Claude provided the B-Tree code in JavaScript. Most of the code that Knuth published in various forums was written in C, so the translation of Donald Knuth’s approach into JavaScript was unexpected.

The Stakeholders Meeting

Before we dive into the Virtual Think Tank, let’s discuss the real think tank. And before we discuss the real think tank, let’s first discuss the stakeholders meeting.

Design and architecture decisions impact many parts of the organization and many considerations should be taken into account. One of the effective ways to weigh the various considerations is by the “stakeholders meeting”.

In the stakeholders meeting each stakeholder argues from a different point of view. Each participant argues for what they perceive as the interest of the organization as reflected through their role. This can be a complicated, nuanced and highly productive discussion where each stakeholder has a different perspective on the system, a perspective that stems from their role and interest (“stake”) within the organization. One participant represents the database perspective, another the UI, one the backend, and so forth. This is often a productive way to reach a decision because while it is difficult or impossible for one person to take all considerations into account, a mature group comprised of representatives of the various interests and perspectives can reach a “good” decision. When done properly, the stakeholders meeting allows for effective decision making. (For a good understanding of how architectural decisions can be made by stakeholder meetings see Facilitating Software Architecture by Andrew Harmel-Law).

Think Tank

Now we get to the think tank.

A think tank is a group of individuals with no role, responsibility or vested interest in the organization or in the issue being discussed. These are people with different perspectives and life experiences. They might also differ in their values and preferences. The members of the think tank discuss the issue or problem at hand and come up with a solution that takes many or all of the perspectives and collective experiences into account. One of the many powerful tools that the members of the think tank use is the argument, where each member tries to use rhetoric, hypothetical cases, and data to defend their position, but are at the same time open to being convinced by compelling arguments from other think tank members. The think tank members do not argue or debate from the perspective of their organizational interest, rather they partake in the discussion from the perspective of their particular experience and world values. This is a very powerful tool that can allow real depth of thought and analysis.

Very often when an organization will engage a think tank, the think tank will not provide a solution rather the think tank will provide a “report” or “white paper” that discusses a spectrum of solutions and compares their relative merits and trade-offs. This report is then used to provide guidance and direction throughout the life cycle of the work or project.

While a think tank is a very powerful and useful tool, a think tank does have several disadvantages or challenges that need to be taken into account.

First and foremost, a think tank is expensive. When setting up a think tank, we are looking for people with experience, wisdom and perspective, but that are not stakeholders, and they do not work for our organization, so getting them to devote time and attention can be expensive.

Beyond being expensive, there is the simple issue of availability. We need diverse perspectives, and it might not be possible to find these people and put them together.

The Virtual Think Tank

Over the last two years I have been experimenting with the idea of using LLMs to create a “Virtual Think Tank”. The basic concept is to prompt the LLM to discuss an idea or problem from multiple perspectives. The virtual think tank does not propose a solution, rather it evaluates a series of trade-offs and helps me arrive at what is the best solution for me.

I have found this approach to work surprisingly well on many types of challenges and issues. In the next section I walk through an example.

Virtual Think Tank Example

This is an example of how I used Claude.ai to create a virtual think tank.

Problem Statement: I am starting to build an e-commerce system and I am wondering if and when it is a good idea to start using microservices.

Before I start the actual discussion, I have found it helpful to do the following. These are general guidelines that are not necessarily specific to a particular LLM.

1. Start a new session so that the context is not contaminated by previous prompts.
2. “Priming”. Provide some basic prompts and ask some basic questions to establish context. I have found this to be quite helpful in getting better responses from the LLM.

The Prompts

The following six prompts were used to set up and then interact with a virtual think tank on microservices.

Prompt 1 – Some basics on microservices

Avraham>> Can you explain to me the basic principles of microservices architecture?

Claude>>

<Claude responded with a long and mostly standard and correct response on microservices that was quite useful and accurate. The answer is an aggregate of all the good texts written about microservices. Specifically, the response included no controversial or strong opinions.>

The reader is invited to reproduce the results with their LLM of choice.

But what if I need someone who can explain microservices to me in a more personal way? Perhaps even someone that might have a strong position or opinion on the matter.

Prompt 2 – Finding a persona

Avraham>> Can you suggest an actual real life person that would do a good job of advocating and explaining microservices?

Claude>> For a real-life person who would do an excellent job advocating and explaining microservices, I’d suggest Martin Fowler.

Martin Fowler is a renowned software architect, author, and speaker who has been influential in promoting and explaining microservices architecture. He’s particularly effective because:

1. He co-authored the seminal article that helped popularize microservices in 2014 with James Lewis
2. He explains complex concepts with clear, practical examples rather than abstract theory
3. He balances enthusiasm for microservices with pragmatic advice about when they’re appropriate
4. He has decades of experience in software architecture and can compare microservices to other approaches
5. His writing style is accessible even to those without deep technical backgrounds

Other strong candidates would include Sam Newman (author of “Building Microservices”), Chris Richardson (creator of microservices.io), or Adrian Cockcroft (who led Netflix’s migration to microservices).

So now l know of a person that can advocate microservices. (In this particular case, I knew of Martin Fowler’s work before I started, but I often find that LLMs provide very useful names of experts that I had not known about and from whom I can learn a great deal. In the early days of GPT, it was known that a major drawback was “hallucinations” where an LLM would invent names of people that do not exist. While not completely resolved, major progress has been made in this area.)

Prompt 3 – Asking “Martin Fowler” for his opinion

Avraham>> You are Martin Fowler. Can you explain to me the basic principles of microservices architecture?

Claude provided an excellent summary. The entire summary was written in the first person. The reader can easily reproduce a similar response on their own. (See Appendix A)

Looking at the responses provided by the LLM and comparing the generic response to the Martian Fowler response, we can note several differences.

Using a persona changes the “voice”. The Martin Fowler version is speaking in the first person about a topic that he has experience with. It is almost as if reading a transcript of a conversation rather than an edited text.

Martin’s version does not have bulleted lists. In the Benefits vs. Challenges section, “Martin” talks about scalability and flexibility in a much less formal way.

It is worth noting the differences between the two openings:

The generic opening>> (Provided by Claude)

Microservices architecture is an approach to software development where applications are built as a collection of small, independent services. Here are the key principles:

Martin Fowler>> (Provided by Claude)

As a software architect, I find microservices to be a powerful architectural style that has gained significant traction over the past decade. Let me explain the fundamental principles that define this approach:

You can see that once we put Martin Fowler in the picture, we get a more personal voice. Not only are microservices an approach, they are a powerful approach.

So now I know what microservices are, and I know who some of the advocates of the approach are. But in order to have a productive discussion, I need someone that sees things a bit differently.

Prompt 4 – Finding someone to disagree with Martin Fowler

Avraham>> Can you suggest someone that might strongly disagree with Martin Fowler?

Claude>> For someone who would strongly disagree with Martin Fowler’s perspectives on microservices, I’d suggest David Heinemeier Hansson (DHH).

DHH is the creator of Ruby on Rails and co-founder/CTO of Basecamp (and Hey). He’s known for his strong opinions and has been openly critical of the microservices trend, advocating instead for what he calls the “majestic monolith” approach.

Why DHH makes a good counterpoint to Fowler:

1. He argues that most companies don’t have the scale problems that necessitate microservices
2. He believes microservices often create unnecessary complexity and premature optimization
3. He advocates for well-structured monoliths that can scale effectively for most businesses
4. He’s critical of companies adopting microservices because they’re trendy rather than necessary
5. He suggests that the operational overhead of microservices outweighs benefits for many organizations

Others who might express similar skepticism include Greg Young (while he helped create event sourcing, he’s cautioned against microservice overuse) and Kelsey Hightower (who has emphasized that monoliths can be perfectly suitable in many cases).

I had heard about David Heinemeier Hansson as the creator of Ruby on Rails but I did not know that he had written extensively about microservices. This was new to me. Also, I had never heard of the “majestic monolith” approach. (To rule out a hallucination, a quick search found DHH’s Majestic Monolith post.) So now I have two personas that might be able to have a productive discussion about microservices. How about someone who is not so strongly opinionated?

Prompt 5 – Finding someone in the middle

Avraham >> Can you suggest someone that might be somewhere in the middle?

Claude>> For someone with a balanced, middle-ground perspective on microservices, I’d suggest Thoughtworks’ Rebecca Parsons.

Dr. Parsons, who served as Thoughtworks’ CTO for many years, represents a pragmatic middle position for several reasons:

1. She acknowledges the benefits of microservices but emphasizes they aren’t appropriate for every organization
2. She advocates for understanding your specific business context before architectural decisions
3. She promotes an evolutionary approach – sometimes starting with a well-designed monolith and extracting microservices only when justified
4. She focuses on team structure and organizational readiness as key factors in architecture decisions
5. She emphasizes that architecture should reflect business domains rather than following trends

Other balanced voices include:

• Gregor Hohpe (author of “Enterprise Integration Patterns”) who discusses “right-sizing” services based on specific needs
• Michael Feathers who acknowledges both architectural styles have their place depending on organizational maturity
• Camille Fournier who balances technical considerations with team dynamics and organizational realities

These architects typically advocate for thoughtful decision-making based on business needs rather than dogmatic adherence to either approach.

So now I have the team. I have Martin Fowler who often advocates Microservices, David Heinemeier Hansson who often writes against using them and Rebecca Parsons, who is considered by the LLM to be somewhat in the middle.

Let’s set up the virtual think tank.

Prompt 6 – Setting up and Tasking the Think Tank

Avraham>>

I am setting up a new e-commerce business. I do not know how much traffic I am going to have or what the traffic patterns are likely to be. I am debating between two approaches.

1. Using a monolith to get the project started. If we see that the traffic patterns justify it, we will refactor to a microservices approach.
2. Start with a microservices approach.

Can you set up a think tank to debate the relative merits of each approach and to maybe suggest and even agree on other approaches.

The think tank should include:

A neutral and well informed moderator, Martin Fowler, DHH, Rebecca Parsons, Peter Drucker and John Galt from Atlas Shrugged.

The full response is in Appendix C. What follows is some discussion and analysis of that discussion.

Analysis of the Think Tank

You will notice that I added Peter Drucker and John Galt. The reason I did that is that I had discovered that when the LLMs create personas, the personas can be very predictable and often say exactly what is expected of them. Adding characters that do not have a lot of direct experience of the topic at hand but that have “transferable wisdom”, actually adds a certain deal of variety.

Notice is that Claude picked Adrian Cockcroft as the moderator. I think that is a great choice. Throughout the discussion, Claude was able to truly speak in the voice of Adrian Cockcroft.

Even though Martin Fowler was brought in as the voice of the microservices advocate, he actually surprised me by not fully embracing microservices but by bringing in a more balanced voice.

A really useful thing that came out right in the start is that even though I picked a diverse group, there was consensus that we should NOT start with microservices. I consider this to be of particular utility, because there is somewhat of a trend to start with microservices, and here we see that almost the entire think tank is of the opinion that that is not a good idea.

At some point in the debate, Fowler says: “microservices front-load complexity”. That is a very well articulated statement (I wonder if Fowler himself actually said that). It expresses the idea that it is rarely worth introducing complexity at the present in order to solve a future problem.

The discussion later seems to favor building a monolith, while designing for future modularization, this is an approach that does indeed front-load some of the complexity, but all in all it seems to be striking a good balance. So whereas i started my quest looking to understand the trade-offs, the Virtual Think Tank actually converged on the solution.

Continuing the Think Tank

Now that the context has been established and we see that the think tank is working, we can use this session to continue utilizing the think tank to explore other aspects of the issue at hand. I leave that as an exercise to the reader.

Suggested Prompts

Here is a list of prompts that I have found helpful and I am sharing for the benefit of the reader.

Prompt 1:

{system} – can be a long list of documents or artifacts

{current behavior} – can be a long list of documents or artifacts

{required behavior} – can be a long list of documents or artifacts

{problem statement}

I am a software architect responsible for the design of a system that can be described as {system}. Currently the system does the following {current behavior}, but needs changes and we now need to define a system that does {Required behavior}. One of the main issues we are facing is {problem statement}. Before we get started, can you tell me if you agree that {problem statement} is indeed a big problem. Also, since I am going to be using an LLM to help resolve this problem, can please ask me at least two questions about each of the following: The current system, the current behavior, required behavior, problem statement. Use my answers to reword the problem statement so that I can be sure I am asking the right questions.

Prompt 2:

I would like to set up a think tank to discuss the {reworded problem statement}. Please outline at least two possible approaches. An approach can be technical, managerial or procedural. If there are known figures or schools of thought that embrace or promote those approaches. Tell me who they are.

Provide the list in the format of:

{ "approach1": { "name": "John", "approach": "collaborative" }, "approach2": { "name": "Jane", "approach": "analytical" } }

Prompt 3:

Can you suggest a thinker or school of thought that might not have written directly about this particular problem, and who might be able to add a significant or helpful perspective to the discussion? The result should be in the format: { "outsideThinker: { "Name": "John" } }

Prompt 4:

Please set up a think tank to discuss the {reworded problem statement}. The participants in the think tank are someone from the school of approach1, someone from the school of approach2, the outsideThinker, and a moderator who is very knowledgeable in the field, but is not known to have a strong preference or opinion on the matter.

Have the think tank discuss in an open minded manner the {reworded problem statement}. Please do not shy away from argument or controversy. The personas should argue their perspectives but be open minded to hear other perspectives.

If there is something that is unclear or ambiguous – the think tank can ask me a question.

Prompt 5:

Radical approach. I am stumped trying to solve the problem of {reworded problem statement}. I need the think tank to be more creative. Have each member suggest a radical decision that might violate common thinking and practice. Each member should explain why, in this case, their radical approach might actually work.

Prompt 6:

Issue a 3-page summary of the think tank activity along with possible follow up research directions.

Summary

In this particular example, while the think tank did not come up with something new and novel, the think tank was able to discuss and evaluate microservices using existing knowledge in a useful way. I have yet to find an example where the think tank actually comes up with something radically new. But who knows–LLMs are certain to continue surprising us.

As architects, we are always making trade-offs. We are always trying to break out of our biases and conventional thinking. We are always looking for new perspectives and new ways of thinking and of looking at the problem at hand. We are always looking for new tools and methods to help us achieve that. The virtual think tank is an approach that might help us broaden our perspectives.

We are continuing to find interesting and innovative ways to use LLMs. I think that using an LLM to set up a virtual think tank can really help us in tapping the creativity of various figures (both real and fictional) and arriving at useful and interesting conclusions.

Appendices

Appendix A: Martin Fowler on Microservices:

Microservices Architecture: Core Principles

As a software architect, I find microservices to be a powerful architectural style that has gained significant traction over the past decade. Let me explain the fundamental principles that define this approach:

What Are Microservices?

Microservices architecture is a method of developing software systems as a suite of small, independently deployable services, each running its own process and communicating through lightweight mechanisms, often HTTP-based APIs.

Core Principles

1. Single Responsibility

Each microservice should focus on doing one thing well. This is essentially the Single Responsibility Principle applied at the service level rather than the class level.

2. Business Domain Boundaries

Services should be organized around business capabilities, not technical functions. This often aligns with Domain-Driven Design concepts, where each service represents a bounded context.

3. Autonomous Services

Microservices should be:

• Independently deployable
• Independently scalable
• Independently testable
• Potentially implemented in different technology stacks

4. Decentralized Data Management

Each service should manage its own database, either different instances of the same database technology or entirely different database systems to suit each service’s needs.

5. Smart Endpoints, Dumb Pipes

Services should have their own intelligence for processing data, while communication between services should occur through simple protocols.

6. Design for Failure

Microservices must be designed with the expectation that failures will happen. Implement resilience patterns like circuit breakers, retries, and fallbacks.

7. Evolutionary Design

Microservices architecture supports evolutionary design. Services can be replaced and upgraded individually without affecting the entire system.

Benefits vs. Challenges

The benefits include better scalability, flexibility in technology choices, and organizational alignment with business domains. However, these come with significant challenges in distributed systems complexity, operational overhead, and service coordination.

Microservices aren’t for every organization or application. The increased complexity is only justified when your system has reached a certain scale or when you need the specific benefits this architecture provides.

Appendix B – The full Think Tank on microservices

Avraham>>

I am setting up a new e-commerce business. I do not know how much traffic I am going to have or what the traffic patterns are likely to be. I am debating between two approaches.

1. Using a monolith to get the project started. If we see that the the traffic patterns justify it, we will refactor to a microservices approach.
2. Start with a microservices approach.

Can you set up a think tank to the debate the relative merits of each approach and to maybe suggest and even agree on other approaches.

The think tank should include:

A nuetral and well informed moderator,

Martin Fowler, DHH, Rebecca Parsons, Peter Drucker and John Galt from Atlas Shrugged.

Claude>>

E-commerce Architecture Think Tank Debate

The Participants

Moderator: Adrian Cockcroft – Former VP of Cloud Architecture at AWS and Netflix cloud architect who has overseen both monolithic and microservice architectures at scale.

Martin Fowler – Software architect who helped popularize microservices through influential writing.

David Heinemeier Hansson (DHH) – Creator of Ruby on Rails and advocate for the “majestic monolith” approach.

Rebecca Parsons – Former Thoughtworks CTO known for pragmatic, context-driven architectural decisions.

Peter Drucker – Management consultant and author known for the philosophy “form follows function” in organizational design.

John Galt – Fictional character representing individualist philosophy and rational self-interest.

Opening Statements

Adrian Cockcroft (Moderator): “Welcome to our think tank on e-commerce architecture. We’re discussing whether a new e-commerce business with uncertain traffic patterns should start with a monolith or microservices. Let’s begin with opening statements”.

Martin Fowler: “Architecture should enable change. While microservices offer flexibility, they bring distributed systems complexity. For a new e-commerce venture with uncertain requirements, I often recommend a modular monolith with clear boundaries that could later become service boundaries if needed”.

DHH: “Start with a monolith. Period. Most e-commerce businesses never reach the scale that justifies microservices. A well-designed monolith lets you focus on finding product-market fit rather than managing distributed systems infrastructure that solves problems you don’t have yet”.

Rebecca Parsons: “Architecture decisions should reflect your current constraints and future goals. For a new e-commerce business, I’d generally favor starting with a well-structured monolith while designing for future evolution. Your team’s experience and size are crucial considerations”.

Peter Drucker: “The primary question isn’t technical but organizational: what structure best serves your business purpose? Architecture should follow your business strategy. Until you understand your market, customer needs, and competitive advantage, complex architectures may be premature”.

John Galt: “Don’t sacrifice present productivity for theoretical future benefits. A complex architecture that doesn’t directly serve immediate needs is inefficient. Choose the approach that maximizes your productive output now while preserving your ability to adapt later”.

Debate

Cockcroft: “Let’s focus first on the monolith-first approach. What are its advantages and risks?”

Fowler: “A well-designed monolith gives you faster time-to-market. You’re not dealing with service discovery, network latency, or distributed transactions. But design it with clear boundaries from the start, or future extraction becomes painfully difficult”.

DHH: “The monolith approach also concentrates your complexity in one place. Debugging, tracing, and development workflows are simpler. You deploy one application, not twenty. This lets your small team move quickly on business features”.

Galt: “The monolith approach respects the value of your time and capital. It doesn’t squander resources on speculative infrastructure that may never provide return on investment”.

Parsons: “I’d add that monoliths can scale quite far with proper design. Many successful e-commerce businesses run primarily on monoliths with perhaps a few extracted services for specific high-scale components”.

Cockcroft: “What about starting directly with microservices?”

Fowler: “Microservices front-load complexity. You’re solving deployment, service discovery, and communication patterns before delivering business value. This makes sense only if you have strong evidence of immediate scale requirements”.

DHH: “It’s solving problems you don’t have yet and likely won’t have for a long time, if ever. The operational overhead will slow your ability to pivot, which is essential for a new business”.

Drucker: “Premature optimization is the root of many business failures. Until you understand your market dynamics, optimizing for hypothetical scale is speculative at best”.

Galt: “Building unnecessary infrastructure is a misallocation of resources. Each service boundary is a commitment that limits your ability to move quickly if you discover your initial domain model was incorrect”.

Parsons: “That said, there are specific cases where starting with microservices makes sense – if you have a large, experienced team, or if certain components have wildly different scaling needs from day one”.

Cockcroft: “Are there alternative approaches we haven’t considered?”

Parsons: “One approach is the ‘monolith with satellites’ model. Keep your core business logic in a well-designed monolith, but extract specific functions that benefit from independence – like search, recommendations, or image processing – as separate services”.

Fowler: “I’d suggest considering a ‘modular monolith’ approach – using frameworks and patterns that enforce module boundaries within a single deployment unit. This gives much of the architectural clarity of microservices without the distributed systems complexity”.

Drucker: “Consider organizing your team to match your initial architecture. Conway’s Law suggests your system will reflect your communication structure. A small cross-functional team often works best with a modular monolith”.

DHH: “You might also consider a ‘monolith with clear extraction patterns’ – specifically designing for how you’d extract services if needed, but not actually doing it until evidence demands it”.

Galt: “The key is to maintain your optionality. Don’t commit to complex infrastructure until the productivity benefits clearly outweigh the costs”.

Consensus Recommendations

Cockcroft: “I believe we’re converging on some recommendations. Let me summarize”.

1. Start with a modular monolith with well-defined boundaries between domains (catalog, cart, payments, etc.)
2. Design for future extraction by:
   • Keeping modules loosely coupled with clear APIs
   • Avoiding shared database tables across modules
   • Implementing internal event patterns that could become message queues

1. Establish good observability from the beginning to identify bottlenecks as they emerge
2. Consider early extraction only for components with genuinely different scaling needs:
   • Search might benefit from specialized infrastructure
   • Image processing could be separated early
   • Payment processing might need different security boundaries

1. Favor incremental evolution over big-bang rewrites

“Does this approach adequately address the constraints of a new e-commerce business with uncertain traffic patterns?”

All participants nod in agreement

Fowler: “This balanced approach gives you speed now and options later”.

DHH: “It keeps things simple until complexity is justified by evidence”.

Parsons: “It respects both technical and organizational realities”.

Drucker: “It aligns architecture with business strategy”.

Galt: “It optimizes for productive output while preserving future adaptability”.