Please confirm you want to mark all topics read
Not logged in
Now that you've read the article (if you haven't, click HERE), what do you think?
It is very important to disambiguate Users as Contributors early in the Federated Data process. We are working on having stackable validations in the process followed by a friend-of-a-friend model to ensure contributed data comes from a known Person.
In the xMas days of joy and calm, I went thru your Webinar on C-a-C (Compliance as Code) and also had a glimpse of your Use Cases.
I think, we should raise the abstraction to yet another level...
Now I'm, scrutinizing - not the Frank Zappa way 😉 asking rethorically:
- Why do you believe that a Diagram is needed for a Team ?
You keep arguing (elsewhere) that Text is more precise/comprehensive and suitable to Auditors. So why not for a 'general audience' ?
I do agree its compelling to have easy graphics and visualizations beside of textual representations, but to whom - End Users or Architects or both ?
- What is the end-goal (not Minimum Viable product) ?
Is this to remove the variations of Platform specializations, that is tedious to roll into CIS and likewise frameworks ?
Is it to allow easy (machine assisted) comparison of findings of compliance controls detections ?
Or is the reality, it support a general control seen around like 'You must be able to present a documented system', alone invented by decades of various frameworks and standards ?
Well, if it can be automated, like by feeding a VMWare 'Software Defined Datacentre' to PlantUML, and voila - all AS-IS is suddenly documented, then we can get rid of Document Controls like mentioned, and simply require an Automated Document Generation capability should exist as a best practice.