Architecture and Design Huddle

Software is never designed in isolation. In my career I have never seen someone come into a meeting on a green field project with a clear vision, draw what it needs to be done and everyone agrees and development start the next day. That might be the case if you have done that type of project many times but not for something new.

Instead in a healthy environment engineers and architects get together, start with a number of simple proposals, discuss pros and cons of each and the discussion is built up from there. Some might play the devil’s advocate, some question things and some ride their egos.

This decision making process is similar to the Blackboard design pattern where a common base, the “blackboard”, is iteratively updated by a group knowledge sources.

Below are some tips to guide a technical design discussion so it’s beneficial to everyone:

Start the discussion early – The sooner you start the discussion the better. You have more time to think the big problems through. You will have more time for experiments.

Keep attendees small – There is no magic number but a meeting with more than 8-10 people will not be constructive specially if everyone wants to talk. Choose the right people who have the knowledge and authority to make a decision.

Start with the customer – Everything starts from why and how it’s going to benefit the customer. Always start from “why” then go to how.

Requirements and constraints – Everyone should be on the same page about requirements and constraints of the system. Make these things clear. Being fast is not a requirement but a response time of under 2 second for 95 percentile of requests between 9am to 10pm is a sound requirement. Not every requirement comes from the customer. Think of testability, performance, modularity, etc. early in design.

Present your idea – Let your proposal loose, keep it casual, aiming to spark discussion, and get feedback. No need for a presentation because it’s ripe and has a high chance of rejection or change. Discuss each idea thoroughly. If an idea is rejected, document why. Do not jump to another idea too quickly unless you have documented and understood pros and cons. If an application is slow due to using a particular library and devs suggest to use another library make sure they have tested the first library enough and the decision is based on facts and reliable test cases otherwise switching to another library is just a waste of time.

Do simple things first – When solving a big problem start simple. Do not try to solve all the problems in the world at once. Implement the simplest thing first, take it to production and iterate. Create phases and do simple things in initial phases. Do not budge when PM tells you that we only have one shot at it!

Question everything – As the design meeting organiser or architect one of your tasks is to question everything. This might seem intuitive and many people shy away from asking questions or simply asking why.

If you take away one thing from this article it’s this. Try the role of the “questioning guy” in the next meeting and see how it unfolds solutions.

If you are stuck on a hard problem do not forget the power of Six Thinking Hats method. It has saved me few times.

Step back, watch and manage – Once the meeting started you don’t have to be the sole speaker and decision maker. Give space to all, encourage people to share their thoughts and feedback. Allow them to draw on the whiteboard specially create an environment that junior or shy engineers can have a say. Stop people who talk too much and want to be the sole speaker. Ensure the discussion progresses towards coming up with a decision aligned with the goal of the meeting. Good meeting facilitation takes practice and needs authority. Stop unnecessary discussions and off-topics. Do not allow bully, loudness, arrogance and anger to dominate the meeting. Leave egos out of the meeting.

Use tools effectively – Covid-19 taught (hopefully) many organisations how to work from home and use tools such as online whiteboards, documents, etc. better. A design might be clear in your brain but that is not going to be the case for everyone. Draw it for the benefit of all people and share it after the meeting. A drawing with a bunch of boxes and arrows goes a long way.

Address disagreements – If some people disagree with something, hear the reasons. Know the difference between a technical reason and arrogance or reasoning out of ego. Make sure the disagreement and reasons behind it is discussed. Do not let disagreements linger undiscussed.

Finish with notes – Collect the key decisions made and write up the summary, circulating it to the meeting attendees. If you used a whiteboard, take a photo. Assuming there was an agreement, these notes might be the start of a design document. You may also want to keep a Decision Registrar. Do not forget the action items.

Do not drag the discussion – It’s best to make a decision late enough when you know more about the problem. The more you delay the decision-making the batter. This is called the last responsible moment. But delaying the decision making does not apply to everything. Do not drag decision making otherwise you will not achieve anything and there will be a lot of open items in your agenda.

The last responsible moment is a point in time when you must make a decision otherwise there will be dire consequences or it would be irresponsible not to.

Iterate – Depending on the type and complexity of project/problem you are tackling there is a high chance that you cannot cover all the items in one meeting. You will need multiple discussion meetings across your SDLC. Ideally more before dev starts, then a few during dev when you get real feedback and hopefully less during more formal test cycles and production.

Follow up and execute – This is the hardest part! Sometime after the meeting follow up on the action items. Also any discussion for the sake of it is just waste of time. Go to production asap. Demonstration defeats discussion!

Team Architecture

Team architecture is one of the major concerns of any engineering group in tech companies. How do we arrange people in teams so that the best outcome is achieved.

Definition of a team usually makes sense in the context of ownership. What is it that a few people can own to form a team for? This is the first question you have to ask when forming a team. What they will own and what happens to the product when the team vanishes.

Another aspect that make a team more effective is the reporting lines, e.g. an infra team that does not report to engineering but reports to the operations is just waste of their potential. This is a different topic I will get to later.

Below are some thoughts on the subject (with focus on software products) that will hopefully spark more thinking and discussions.

Patterns of Team Structure

The definition of the following patterns is not rigid at all. They have a lot of overlap, similarities and some even come under hierarchies. Some teams have different names in different organisation. A DevOps team in one company might be the Infra team in another company. I haven’t made much effort to classify them into a better grouping or structure.

In reality we group teams together all the time, e.g. CloudOps consist of cloud team, DevOps team and operations team; or a commerce team may consist of billing team, ordering team, etc. Teams similar to software can have levels of abstraction and hierarchy.

These patterns provide tools to ask questions on why the teams are formed the way they have and if there is a better way to re-structure them.

Product Team

An organization may have one or more products, e.g. Kayo, Binge, etc. Products my be for internal or external customers, B2B, B2C, etc.

This pattern has some variations:

  • External customer: Product may be developed for an external customer. If the external customer has very tight timeline and budget constraints the long term support of the the products may face difficulties.
  • Internal customer: Product may be developed for an internal customer. The company owns the product and the team has a better sense of ownership. Internal products usually receive more care and longer term support. Internal products may be a revenue generating product such as Kayo for Foxtel or an internally used productivity or cost saving product such as bedrock vending machine.
  • Bundle of products: A team that works on a group of products.
  • Product variation: A team that supports a variation on a product, e.g. Android team, iOS team.

For a product team to be successful they have to be cross-functional and own all of product + design + engineering. Product team’s goal should be solely customer focused.

Feature Team

A team that supports or owns a feature or a process within a product. A feature team is usually across multiple domains or applications. When a process/feature/journey/aspect is big enough then it requires a team to handle it.

Example: signup team, purchase flow team, user journey team, search team, etc.

Feature teams usually have many communication points as they interact with many other teams and applications. 

Processes may have sub processes and that might mean sub-process/feature teams.

Feature team may be a short lived team and has similarities with project teams below.

Teams by Conway’s Effect

Conways law states that the communication structure of an organisation influences the systems they build. That means they architecture of a system is affected by the team structure.

The effect of team structure on system architecture makes team building an architectural concern not a management or agile activity.

As a rule of thumb remember the Reverse Conway which focuses on a team structure that matches the desired architecture we want.

If the architecture of the system and the architecture of the organisation, are at odds, the architecture of the organisation wins. Ruth Malan

Spotify Model

It’s a famous model you can read about here. Since Spotify announced this model it was adopted by many organisations some of which took it too seriously unlike the Spotify themselves (according to Kingberg and Ivarsson on the original Spotify blog they partly implemented the model!)

One major problem with the model is that there is no regards to the team size. You have to be careful otherwise the tribes will grow too big.

One important measure for a team size is team cognitive load which is the amount data, information, task and process a team is capable of handling. This imposes constraints on the software architecture too because there will be limits to the amount of components you can realistically place into an architecture that a team is responsible for.

Sometimes too many bugs in a system is an indication that the system is bigger than the cognitive load of the team and the team is having difficulty figuring things out.

Spotify model also doesn’t talk about the dynamic interaction of teams; it’s static.

Platform Team

A platform team in digital companies is a basis that provides self service APIs and reusable tools to other teams to perform their duties. Example is DevOps team that builds CI/CD pipelines, application templates, etc.

Platform team nowadays is a capability that gives companies an edge. As a rule of thump if a reusable thing finds more than 3 users, then it may be time to consider this a horizontal responsibility and move it to a separate team.

If a reusable thing finds more than 3 users, then it may be time to consider this a horizontal responsibility and move it to a separate team

On the other hand, if the platform team is not self service and automated enough it will eventually burn the team or grow it unmanageably large. It is just pulled in all directions by many teams. Self sufficient teams that have a member from the platform team (capability) take this direct pressure off the platform team. Ideally other teams should contribute seriously to the platform and the platform itself should be flexible and extensible to allow such contributions.

The concept of platform team paves the way to define capability teams. Teams that are specialised and take care of an speciality across the organisation such as Kubernetes team, Identity team, etc.

Some do not like the idea of DevOps team and would insist on merging Ops and Dev and define DevOps as only the concept of affinity between the two but I doubt this is true anymore. Nowadays DevOps is an abstraction layer on Ops teams where they stay on their hardware/network/storage realm and DevOps take care of the necessity for more automation, container orchestration, GitOps, CI/CD, etc. More on the later.

Project Team

A team that is formed for a project. These teams are usually short lived depending on the nature of project. Project teams usually have the role of project manager. Care has to be taken for the long term support, maintenance, ownership and upgrade of the created product or service when the project finishes.

As project teams are formed every time for a new project, they share the common problems of a new team such as personality clashes, etc.

Project teams are usually more constrained with time and budget. From personal experience showing a project plan or timeline to developers just makes them miserable! Just shield them from it as much as possible!

Component Team

A team that is responsible for a component (part) of a product or feature. This could be a considered as a variant of a product team as well. Component teams of function best as cross functional teams.

Example: backend team, front end team, watchlist team.

Even though a component might be a feature and vice versa but component team focusing on one well defined part of a system is usually the opposite of feature team working across many components.

Domain Team

If you have defined boundaries for each domain in your business context you can have domain teams, e.g. commerce team, content team, billing team.

Domain teams usually map to the capabilities of a business. A business with capabilities such as sales, marketing, streaming may have teams with the same names.

Each domain may have a manager and/or architect. Domains are hierarchical in nature hence this pattern has a logical variation of sub-domain team.

Cross Functional Team

This type of team has at least one member for any capability they need to make them self sufficient and to reduce cross team communication and dependency. It is also called self-sufficient team. These teams seem to be high performing teams due to less external communications and better internal communication (cohesion).

One problem with this type of team is that they might diverge from the standard architecture of the overall system that organisation follows and there should be ways to align and enforce such standards, e.g. using a self service platform.

HBR says that 75% of cross functional teams are dysfunctional. Read here why.

Functional Team

If cross-functional team is a thing then we should have a definition for a functional team as well. A functional team is responsible for or corresponds to a function unit or domain of an organisation.

A functional team has a lot of similarities with domain team and component team, e.g. accounting team, IT team, platform team, development team, billing team, test team, architecture team, call centre team may all be called functional team.

Technology Team

Specialised teams that build or maintain a piece of technology or a group of technologies. Example: Kubernetes team, front end team, backend team, UX team, Java team, etc. These teams are not self sufficient and many depend on them. They also usually do not map directly to an organisational value stream.

Consulting (Enabling) Team

Specialised team that is formed internally or hired externally for specific purposes, i.e. something that organisation has no knowledge of or does not want to spend time on. Example: cloud migration team. This type of team usually has a short life span and require close management to make the best out of it.

Outsource and Offshore Team

Many businesses nowadays outsource part of their workloads to onshore or offshore teams. Common problems include: culture differences, timezone differences and lack of present management. You organisation also loses the knowledge of that team when their contract finishes.

Matrix Organisation

This form of organisations are a combination of functional and project teams. An individual works in a project/product team and at the same time part of another functional/domain team, e.g. an architect is part of the architecture team and also works on a project.

Matrix organisations or teams is an old concept and is the basis for the Spotify model.

Temporary Team

A team that is formed for a short period of time in order to handle a time bound task. Care must be taken in terms of the ownership of end product once the temporary team ceases existence. Examples are project teams or task force teams. They have a limited life span.

Team Dependency Patterns

Teams depend on each other for different reasons. This is where team boundaries have to be defined and as said above as part of Conway’s Effect, the team boundary should ideally be dictated by system architecture.

  1. Knowledge dependency: A team needs the knowledge of another team e.g. the billing team needs the DevOps team to setup CI/CD pipeline for them.
  2.   Task dependency: A team’s output is another team’s input, e.g. a team is waiting for an API to be ready for consumption.
  3.   Decision dependencies: A team’s decision affects the tasks of another team. Example: the way front end team wants to consume APIs will affect how backend team creates those APIs in terms of technology and granularity.

Team Communication Patterns

The teams communicate in many different ways. Remember that teams are made up of people and even though with teams we create boundaries but people are still free to talk to each other and this opens unlimited communication paths.

Ideally we want less communication across teams (low dependency) and more communication within the team (high cohesion).

  1. Formal communication – collaboration based on their org structure, reporting lines and formal team boundaries and communication tools (chat, email, etc.) This type of comms usually include hand offs.
  2. Informal communication – collaboration based on interpersonal and friendship relationships or how people influence each other beyond the formal titles and org charts in a personal level. Even though this sounds cheesy but a lot of tasks in organisations are actually performed via informal interactions. Sometimes this is an indication of wrong team boundaries, missing capability in the team or incorrect org charts (people are not where they should be)
  3. Communication by Service – based on services provided by another team. A team provides a service (e.g. payroll or platform) and another consumes
  4. Communication by API – based on an API provided by another team.

Benefit of communication by service or API is reduced human interactions or hand offs.


Microservices or Micro Service Architecture (MSA) is being advertised heavily these days mostly by Thoughtworks.

At first it looks like a great idea, in fact it is a great idea if you look at this this way:

  • There are boundaries between services.
  • Each service is small enough to understand, to be re-written, etc.
  • Each service is supposed to do only one thing.
  • Each service can be so fine grained that it can even correspond to a single database table (extreme?)
  • etc.

I would like to call it a “pattern” as it has its own pro’s and con’s. But none of these are new concepts or best practices on their own. To me MSA at its core seems like a style (or part) of SOA since services are the “things” you work with.

On the other hand there are few areas where the current articles and enthusiasts are not very clear about:

  • How do we orchestrate a ton of services? In all videos and articles they diminish ESBs. I am not a fan of ESBs but they do a fine job of orchestration but MSA is not clear about it. I have seen suggestions on using a thin layer of orchestration, using messaging or RESTful styles, etc but if you have a million of microservice then it would be a nightmare.
  • If we create too restricted boundaries around our services and they become so isolated then how do they communicate from a database perspective? How sales database can be so separate from ordering database?
  • Lots of small services makes transaction management a big job.
  •  etc

Given these concerns you have to be very careful when you use MSA. I feel this is an old concept with a new name which is not yet mature to become a full fledged style of architecture. Probably it is good in smaller applications with mostly read-only services or services which are inherently separable….Time will tell…