teamtopologies / independent-service-heuristics Goto Github PK

A few thoughts - let me know what you think.

Team vs members of the team - considering skills liquidity (Chris Matts)

• Does the team have the necessary mxi of people / skills and willingness to cross-skill
• some explanation https://vimeo.com/86839451 > https://vimeo.com/299158189

Does this 'thing' make sense to independently migrate / deploy in the public cloud independant of related 'things'

• (e.g. modularization / bounded context / tight coupling)
• do you have any dependencies on vendor / 3rd party software that prevents scaling if demand increases (e.g. licences based on compute e.g. SAP HANA / MIPS vs pure compute consumption like public cloud services)
• does an existing 'thing' / service already exist on public cloud that you could use as a commoditized service instead (e.g. Wardley mapping techniques to avoid building already commoditized capabilities)

Is there demand for this 'thing' outside of the context of its current usage, could this be used more broadly within your organization or to different customer segments. --> possibly an extension of No.2 but more about re-use / demand.

Does this 'thing' as as a master or authoritative source for key static / reference / client data?

• do you have versioned interface contracts and the ability to deploy new versions without impacting existing 'customers' (consumers)

Resilience / scalability

• as demand for your 'thing' scales do you have a linear increase in demand for new capacity / availability (including geographical regions)

Anti-pattern

• Are there since points of failure / individuals (e.g. Brent from Phoenix / Unicorn Project) that cause a bottleneck
• Does your 'thing' depend upon tight coupling / specific vendor drivers or use things like DB Links rather than through a managed versioned API
• Do you upstream / downstream producers / consumers need your 'thing' to coordinate a release (e.g. release train) or can they release independently as frequently as they need to