Adding New Features

[deanwebb]

I'm in discussions about adding a new feature. On the surface, "Expose (X) subsystem with an API for automation" sounds like an awesome thing. FINALLY, we can use an API to automate what has been a manual process. And then we start looking at use cases...

Different customers have different ways of mapping the data from their sources to (X). How do we customize that mapping, or do we force one method on everyone?

Some customers have a single source of truth to send data to (X). Others, it's not so well maintained, can't trust it 100%, maybe just for adds/removes/changes, and even then... Still others, there are multiple global regions, each with their own source of truth for (X) functions in their region. How do we handle those use cases?

And what about people making errors in the source of truth that pushes garbage automatically to (X), crippling the system, possibly the entire product? Rollback? Threshold limits? Never automate without human approval?

And now we're back to talking about a manual process to address an issue in the automation that we want to implement to get rid of the manual processes.

Not so easy, adding these new features in a product...

[icecream-guy]

for the Cisco ASA API, the API account needs full access to the firewall system,  not something easily negotiated, when you dole out limited access to partners and such.

the other this we struggled with for the API, what that if the partner is making changes to the firewall, this is not in compliance with our change management policy.
we do support this for our group, but partners will need need to trudge through our process to make changes on the co-managed firewall. 

[deanwebb]

Again, API is not magical... we always need to keep that in mind...