4 ms·

You can iterate on compliance _implementation_ if you keep some tollgate that guarantees all compliance business requirements are eventually met. In my opinion

You can iterate on compliance _implementation_ if you keep some tollgate that guarantees all compliance business requirements are eventually met. In my opinion this is not the same as waterfall, and leaves room for experiments and iterative learning. The (very) tricky part, in my experience, is to have these requirements captured in implementation-agnostic way. Even strict accounting reqs require huge amount of work for someone to deconstruct them down to actual compliance requirement, instead of something solution-specific like "we need to store X in component Y". Not everyone wants to invest into this just for agility sake.

cushychicken 3y ago
The PCI Compliance audit commission would surely have some thoughts about this philosophy.
- oblio 3y ago
  You can just section off the bits that need to be PCI compliant. It would be a good architectural decision, actually.
CharlieDigital 3y ago
> eventually met That might work in some fields, but consider life sciences and pharma where some unmet functional/compliance issue could be injurious to the company, a patient, or both. Waterfall-ish workflows are hard to avoid in such cases. We learned to simply do iterations of waterfall and speed up the validation via automation as much as possible.
- pc86 3y ago
  Even if that's true - I'm not sure it is, particularly in very early R&D phases with no external impacts - all that means is that non-waterfall doesn't work absolutely 100% of the time, which nobody is saying it does. Any time an engineering methodology is discussed, people come out of the woodwork with their specific example of one time where that methodology won't work.
  - jghn 3y ago
    In my experience at pharma there has been an enormous divide between R&D and production for software development. Precisely for the compliance implications. In cases where it hasn't been a perfect black/white differentiation it was always dirty laundry where some subset of people knew they were sitting in a grey area and hoping that compliance officers/auditors wouldn't notice.
  - CharlieDigital 3y ago
    I worked in the pharma space building document management systems that supported clinical and pre-clinical processes (mostly clinical, some R&D). After a while, one starts to understand the need for the rigor. If some cluster of patients suffers some injurious adverse effect pre- or post-market, the FDA and a bunch of lawyers wants to trace the history of development to understand how to assign responsibility. Software systems in this space are validated quite rigorously against their functional and technical design specifications to verify that the records produced are traceable. Software validation in this space works kind of like GPL licenses: the sponsor (like a Merck or a Pfizer) is responsible for validating software from vendors when it is supporting a GxP process. Those vendors are then responsible for validating not only their systems, but all dependent systems as well. (A lot of it is risk-based and obviously a lot of the methodology, guidance, and interpretation has evolved since the cloud era. But we used to have to take our customers on tours of our data center and their auditors would match the specifications of the hardware!) I think it's one of the reasons why -- despite this process being extremely high in "schlep" -- there are few startups in this space because the barrier to entry is quite high. Even having 15 years of domain experience and running a team delivering production systems used by pharmas to run their trials, I don't think I'd want to do a startup in this space. There's a really great HN thread on this that resonated with my experience that I bookmarked a while back: https://news.ycombinator.com/item?id=33545209 https://news.ycombinator.com/item?id=33545209

cushychicken 3y ago

The PCI Compliance audit commission would surely have some thoughts about this philosophy.

oblio 3y ago
You can just section off the bits that need to be PCI compliant. It would be a good architectural decision, actually.

CharlieDigital 3y ago

> eventually met That might work in some fields, but consider life sciences and pharma where some unmet functional/compliance issue could be injurious to the company, a patient, or both. Waterfall-ish workflows are hard to avoid in such cases. We learned to simply do iterations of waterfall and speed up the validation via automation as much as possible.

pc86 3y ago
Even if that's true - I'm not sure it is, particularly in very early R&D phases with no external impacts - all that means is that non-waterfall doesn't work absolutely 100% of the time, which nobody is saying it does. Any time an engineering methodology is discussed, people come out of the woodwork with their specific example of one time where that methodology won't work.
- jghn 3y ago
  In my experience at pharma there has been an enormous divide between R&D and production for software development. Precisely for the compliance implications. In cases where it hasn't been a perfect black/white differentiation it was always dirty laundry where some subset of people knew they were sitting in a grey area and hoping that compliance officers/auditors wouldn't notice.
- CharlieDigital 3y ago
  I worked in the pharma space building document management systems that supported clinical and pre-clinical processes (mostly clinical, some R&D). After a while, one starts to understand the need for the rigor. If some cluster of patients suffers some injurious adverse effect pre- or post-market, the FDA and a bunch of lawyers wants to trace the history of development to understand how to assign responsibility. Software systems in this space are validated quite rigorously against their functional and technical design specifications to verify that the records produced are traceable. Software validation in this space works kind of like GPL licenses: the sponsor (like a Merck or a Pfizer) is responsible for validating software from vendors when it is supporting a GxP process. Those vendors are then responsible for validating not only their systems, but all dependent systems as well. (A lot of it is risk-based and obviously a lot of the methodology, guidance, and interpretation has evolved since the cloud era. But we used to have to take our customers on tours of our data center and their auditors would match the specifications of the hardware!) I think it's one of the reasons why -- despite this process being extremely high in "schlep" -- there are few startups in this space because the barrier to entry is quite high. Even having 15 years of domain experience and running a team delivering production systems used by pharmas to run their trials, I don't think I'd want to do a startup in this space. There's a really great HN thread on this that resonated with my experience that I bookmarked a while back: https://news.ycombinator.com/item?id=33545209 https://news.ycombinator.com/item?id=33545209