Introduction
The Albatross method is a project management approach designed for modern software teams. For readers new to Albatross, a full introduction is available here: It’s Time to Rethink Agile: The Albatross Method Is the Advanced PM’s Choice.
This post focuses on one specific phase of the method: system design.
In the Albatross method, system design begins after the product owner and the development team have agreed on a UI design. At that point, the development team imagines the components of the system that are required or affected, lists them, and draws them. Listing and drawing often happen at the same time.
The goal is not to produce a perfect blueprint. The goal is to produce a shared, high-level understanding of what the system does, which components depend on which, and where the risks of circular or missing dependencies lie.
This post covers four areas:
- Diagrams: drawing the system as a data flow diagram
- Listing: recording components and control information
- Team agreement on the design
- Who makes the system design
1. Diagrams: Drawing the System as a Data Flow Diagram
The primary diagramming tool in Albatross system design is the data flow diagram, similar in spirit to those used in UML. A data flow diagram models a software process as a network of data flows. It focuses on at least one component and covers all components that engage in the process.
Some components can be grouped into a module to simplify the view. Among the components, data flows are drawn.
Rules for Data Flow Diagrams
- Every component must have at least one data flow, either into or out of it. A component with no data flow is an orphan and should not appear.
- Every data flow must have a direction and a label describing its content. The content is often recorded as major data items, and/or the data items on which change happens.
- Only data flows are drawn. There is no space for control flows.
The last rule can be difficult for someone new to the method. Programmers naturally think of “how” rather than “what.” But “what” is a higher-level abstraction. The “what”s help the team find dependencies. A component X naturally depends on a component Y when data primarily flows from Y to X.
Example: DB Access and Control Information
Consider a database access. X sends an ID to Y, and Y sends a user record to X. Between X and Y there are two data flows: one carries the ID, the other carries the user record.
The critical point is this: although the ID is indeed data, it is used to control how Y behaves. Strictly speaking, the ID works as a control. Therefore, it is the flow from Y to X that determines that X depends on Y.
Example: Distinguishing Apparent from Real Circular Dependencies
Another common confusion arises when a component X sends data to Y, and Y keeps the data somewhere. X also retrieves data from Y. At first glance, this looks like X depends on Y and Y also depends on X.
Closer analysis shows it is not circular: Y depends on the sending part of X, while the retrieving part of X depends on Y. The two directions involve different parts of X, so there is no real circular dependency.
Real circular dependencies are a thing to avoid. Apparent circular dependencies, however, can be accepted once the analysis shows they are not actually circular.
Such ways of drawing are not 100% strict, but in practice they work well enough for finding circular dependencies and missing dependencies.
Recording Important Control Flows
Sometimes a control flow is considered so important that it is better to record it together with the data flow or the module in the data flow diagram. In such a case, the control information must be recorded as comments.
2. Listing: Recording Components and Control Information
Because control flows are not drawn in the data flow diagram, control information must be recorded separately. This is done in a list form, called the component list.
Each involved component is listed, together with a brief description of what it does or what is changed.
The component list serves two purposes:
- It captures control information that the data flow diagram intentionally omits.
- It provides a quick reference for reviewers who need to understand the functional responsibilities of each component.
3. Team Agreement on the System Design
Agreement on the system design happens at two timepoints.
Timepoint 1: Manager’s Review
The first agreement happens when the system design is done. This is the manager’s review.
The manager:
- Views all the data flow diagrams and tries to identify any logic failure.
- Reads the component list and tries to identify any functional mismatch.
- Checks whether the system design is aligned with the product owner’s wish, which is often recorded as a UI design.
Timepoint 2: Team Alignment Before Implementation
The second agreement happens when the team is about to start turning the design into an implementation.
At this time, all involved members read the system design and make sure they share the same understanding. This may be attained by a presentation, some discussion, later questions, and so on.
4. Who Makes the System Design
Often the system design is done by only one member. But there are cases where one person’s knowledge about the software is not enough to build a whole system design.
When this happens, the design task can be distributed to several members. Each member works on the assigned part, then they negotiate and agree on how their relevant parts interface.
This distributed approach preserves the benefits of a single coherent design while allowing the team to draw on broader knowledge.
Key Takeaways
- System design in the Albatross method starts after the UI design is agreed on.
- Data flow diagrams focus on what data moves, not how control flows.
- Only data flows are drawn. Control information is recorded in comments or in the component list.
- A component with no data flow is an orphan and should not appear.
- Real circular dependencies are to be avoided, but apparent circular dependencies can be accepted once closer analysis shows the two directions involve different parts of a component.
- Agreement happens twice: once at manager review, once before implementation.
- System design can be done by one person or distributed across several, as long as interfaces are negotiated and agreed on.
Conclusion
System design in the Albatross method is a disciplined but practical exercise. It uses data flow diagrams to expose dependencies, a component list to capture control information, and two agreement points to ensure alignment between management, the product owner, and the development team.
The method is not intended to be 100% strict. It is intended to work well enough in practice to find circular dependencies, missing dependencies, and functional mismatches before implementation begins.
For technical leaders evaluating project management approaches, the value of Albatross system design lies in its clarity: it separates what from how, makes dependencies visible, and creates a shared understanding that survives the transition from design to implementation.