Flow design decisions
Decision: No dependencies between workflows
Rationale: workflows are deployed as a unit. If deploying a change in flow A
could break flow B, Flow45 would have to implement mechanisms to detect that.
And mechanisms to deal with concurrent deployments of changes to several flows.
Decision: no dependencies between workflows owned by different teams
Rationale: This would be a dependency even more difficult to manage than a
dependency between tasks of different workflows owned by the same team. Flow45
aims to support single teams in managing their own workflows, in a reliable and
correct manner, which is hard enough as it is.
It is possible that a workflow contains steps executed by software developed by
people from different functional teams. However, in that case, a single, cross
functional team, perhaps a project team, can still be assigned ownership of the
overall flow. When generic software or computing platforms are used in the
flow, the project team ideally retains the freedom to determine the deployed
version of such software, and with it the responsibility to timely upgrade, and
to maintain a perfect track record for their flow. When, after a flow has been
put in production, the project team dissolves, and the flow is handed over to a
BAU team, they inherit this responsibility.
- Created
- Sat 24 Feb 2024 20:16:21 CET
- Updated
- Sat 24 Feb 2024 20:16:21 CET