Kudos,: you are the collab support product suite use case. And paying attention to what's common and what's distinct is Exactly The Thing(tm). Think overhead reduction, traceability enhancement, and metaphor.
- Less Overhead; More Flexibility: Why run several DBMS, identity services, app servers, container engines, etc. Even if you grab a la carte from different sources, now you have more dependency management. Common functions that are the same, just do once.
- Less Friction; Better Traceability: Can just use the other thing,without another round of setup, and easier traceability. Plus, these user issues (faillures) trace to that design defect (fault), which traces to this correction (chante set), is easier to do if the tools talkto each other.
- Users and Use: Move between collab metaphors freely. High-presision workflow isn't a knowledge base, isn't a virtual cube farm, isn't.... Slack may be a good virtual town hall, but it's a miserable knowledge base: wrong metaphor.Metaphor abuse is the hidden collab system failure mode. One Tool to Rule Them All -- not so much.
I have driven collab n tool chain integration(s) a kajillion times.
- One example: "Hey, routing new ops failures (regressions) to the nearest change is a good hack at fixing them faster. Since we own the repository n build, n we're next to the ticket system (that also has defect (fault) tracking), and email ... how about we plug these together .... maybe start with production deployment crash logs as failures routed in aggregate (candidate faults) to whoever last touched the thing thats crashing?"
- Another examle: I ponied up about 1/2 an Engineering FTE to manually maintain failure (customer support) to fault (defect) traceability. It's huge leverage, but I'd much rather have the tech do that for us.
Approaching it this way works.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.