“When integrators bid on a deal, deployment [using an ALF] tool will be easier because you’re not tied to any proprietary standard..”
Mikey, a reader of PAOSS, recently asked a great set of questions, as follows:
“What do you think are the biggest challenges in a multi-vendor OSS. More importantly, did you see the need for a Solution Integrator (SI) or did having a strong core team within the operator suffice for an SI?”
I’ve worked on a few multi-vendor implementations over the years and I believe the keys to this type of environment are coordination and demarcation between vendors/products.
The products you’ve chosen are likely to deliver most of the functions you need within each OSS domain, whether that’s alarms, performance, etc. That’s why they’re “best-of-breed-for-your-needs” after all. It’s the 80% of Pareto’s 80:20 rule. The integration across domains will enhance the others products (eg using inventory information to enrich alarms) to add the other 20%.
A strong core group within the operator is absolutely essential because you need to drive the outcomes that best suit your organisation, even if you do engage an SI. You will need to make decisions based on your deep knowledge of the way your organisation operates that just can’t be delegated to an SI.
However an SI, will tend to have pre-defined approaches (eg vendor selection, cross-vendor process mapping, proof-of-concept interop, benchmarking, cross-vendor testing, etc) that your core group might not have. I can’t speak for your organisation of course or the experience within your team, but many CSPs have skill-sets that are brilliant at operating, but not quite so much at integrating OSS tools.
If you do select an SI, it’s best to choose one that is vendor agnostic so that they can help guide you through the tough integration / demarcation issues without biases towards any of the vendors. They will hopefully also guide you through the challenges of operationalizing the tools that the vendor implements. That means to ensure they’re making the best decision for your long-term goals, not for the implementation by their vendor partners.
One of the things I’ve seen in multi-vendor environments is either a land-grab (ie a vendor trying to push other vendor products out or push them into areas of lower importance) or diminished responsibility (ie a vendor trying to pass responsibility for a task onto one of the other vendors).
In a multi-vendor environment, particularly where the vendors haven’t worked with each other prior, there is a bit of an unknown regarding what integrations will enhance the operator experience. Similarly, it’s quite possible that some of your products will have overlapping capabilities (eg network mapping in inventory and fault management modules) or gaps. The three things that I do to compensate are:
1) Cross-vendor process mapping that shows where each product will be used
2) Get proofs of concept of each of your products established in a lab and try to get all your important use cases (eg service activation) operating with little or no cross-product integration initially. This will help you to find gaps where integration, either manual work-arounds or programmatic integration, will be essential. [BTW. I don’t need to tell you to not underestimate the cost of this integration tax in your business case because your team will already be aware of this no doubt!]
3) Benchmark different alternative workflows if there are overlapping functionalities that you could use. The PoCs will help your process mapping team establish the best end-to-end workflow through the whole suite of products that you have available
There are many other items worth discussing too of course that are common with any large OSS integration (eg project / stakeholder / change management, etc) as well as situations where multiple products / modules are being implemented by a single vendor.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email