Document Note: This posts deals with an adaptation of Team Topology to ML applications. In order to break the monolyth in smaller subsystems the book identifies team boundaries based on the cognitive load capacity of teams.
ML topologies:
Stream-aligned ML teams: Develop and manage ML applications for end-users. The scope of the team is determined by the cognitive load of the team. For instance, a recommender system solution might not vary much for residential and not residential assets, so a slightly larger team might deal with both. However, the recommender system might be very different for idealista users vs real estate agencies, requiring two different teams.
Data/infrastructure subsystem teams: Data and infrastructure teams are different breads buy they are both specialist subsystem teams. These teams ensure data and infra management policy are centralized.
ML Platform teams: Develop end-to-end ML platforms so that stream-aligned ML teams do not have to worry about low-level management and communication between ML artifacts.
A platform is more than just software and APIs — it is documentation, consulting, support, evangelism, templates, and guidelines
ML Platform teams: Develop end-to-end ML platforms so that stream-aligned ML teams do not have to worry about low-level management and communication between ML artifacts.
ML Enabling Teams: Internal coaches of stream-aligned ML teams so that they can adopt missing capabilities or use the data platform.
Team Topology pushes the idea of team-sized software. It stems from Conway’s Law that states an organization will produce a system design following the organization’s communication structure. (View Highlight)
Based on this idea, the book defines an alternate approach to identify team boundaries based on specific types of four teams, namely, stream-aligned, complicated subsystem, platform, and enabling teams. (View Highlight)
