“Nothing is particularly hard if you divide it into small jobs.”
I have an interesting question to pose to you today dear readers, one that I don’t think has a perfectly right or wrong answer, but one you’re bound to have an opinion on. Let me put the contrasting views to you.
Let’s say you are a large CSP that has commissioned a new OSS suite that consists of multiple different vendor offerings in a “best-fit for each segment” product strategy. When preparing end-to-end blueprints through this vendor tapestry, do you:
- Involve all of the vendors in the design process (the transparency model) or
- Keep all of the vendors away from the overall design, but involve them within the domain-specific blueprint development (the divide and conquer model)
Being a big-picture architect, with an eye on the total end-to-end solution, I like to see roadmaps and processes that function across the whole OSS tapestry (the transparency model). I feel that if I’m only given a narrow field of view (ie a single domain with minimal knowledge of adjacent systems), then I’m constrained from forming a fully-considered view. This is particularly true when it comes to flows (process, data, experience) and statue changes.
The problem with the transparency model is the more entities involved, the harder it is to gain binding decisions and reaching agreements on scope, as described in previous posts, “the handshake analogy” and “reaching a binding decision.”
I’d love to hear your considered opinion on which approach is the best (or somewhere in between).Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email