"Nabla’s data service is stateless, or at least almost so - save for the temporarily stored pseudonym correspondence table that is deleted upon each query, no inbound or outbound data is stored."
This doesn't address the case where state does need to be stored, which we briefly discussed in the comments to the last post (https://quiteafewclaims.substack.com/p/the-paths-to-healthcare-plg-part/comment/18533170). It might be useful to add statelessness/statefulness to your workflow MECE. Without thinking too much about it, it seems like statefulness is necessary if:
1. Writing to source systems is challenging (e.g., the RPA doesn't work well enough for that).
2. The nature of your workflow is such that it produces data that doesn't fit into an existing system's data store.
If you need statefulness, you need somewhere to store that state. If you require both statefulness and are attempting true bottom-up adoption, then the place you store that state has to be decentralized (as discussed in the linked comments).
"Nabla’s data service is stateless, or at least almost so - save for the temporarily stored pseudonym correspondence table that is deleted upon each query, no inbound or outbound data is stored."
This doesn't address the case where state does need to be stored, which we briefly discussed in the comments to the last post (https://quiteafewclaims.substack.com/p/the-paths-to-healthcare-plg-part/comment/18533170). It might be useful to add statelessness/statefulness to your workflow MECE. Without thinking too much about it, it seems like statefulness is necessary if:
1. Writing to source systems is challenging (e.g., the RPA doesn't work well enough for that).
2. The nature of your workflow is such that it produces data that doesn't fit into an existing system's data store.
If you need statefulness, you need somewhere to store that state. If you require both statefulness and are attempting true bottom-up adoption, then the place you store that state has to be decentralized (as discussed in the linked comments).