Start with Business Requirements, not Technology
This is the feedback I got from someone who used ExpertExpress to discuss the evolution of their data center:
The session has greatly simplified what had appeared to be a complex and difficult undertaking for us. Great to get fresh ideas on how we could best approach our requirements and with the existing equipment we have. Very much looking forward to putting into practice what we discussed.
And here’s what Nicola Modena (the expert working with the customer) replied:
As I told you, the problem is usually to map the architectures and solutions that are found in books, whitepapers, and validated designs into customer’s own reality, then to divide the architecture into independent functional layers, and most importantly to always start from requirements and not technology.
A really good summary of what ipSpace.net is all about ;) Thank you, Nicola!
The architecture is often driven by the Excel sheet. Seen this many times: the product is selected first because it simply matches the budget and we (designers & architects) are required to implement the solution matching original requirements.
Worked for many big projects both for US-based and EU-based companies. I am talking about non-military projects - those strictly driven by business case.
I wonder if someone lives in 'ideal' world (the one from the books).
Customer will not choose overengineered solution against business requirements.
For example technically it is good to have redundancy. But if RTO is large enough customer will never pay for redundancy
You are "encouraged" by the better discounts to promote certain solutions.
I do not want to share any further details (vendor names, project names) - I took part in many big deals and believe me - the reality is far from the ideal imagination.
For example, "redundant WAN links" is not a business requirement. It's a means to an end, and may or may not be justified based on what the real business requirements are.
Then there's the "negotiation" phase - based on business requirement you come up with a solution. They balk at the price tag. No problem - you can change the solution **when they adjust the requirements**.
Now, all this works in imaginary world (at least for Grumpy Anonymous) where the motivation of the network architect is aligned with the motivation of the business (getting the most bang for the buck). If you allow a vendor to design your network, you get the price tag you deserve. Worst example I've seen: non-redundant Nexus 7000 (because there was no budget for two of them) acting as a ridiculously-expensive patch panel.
That's why some customers go for independent consultant and/or design reviews. I understand that not everyone believes in the feasibility of this approach. I have no problem with non-believers, we're too busy working with people who see value in what we do.
Finally, there are the customers going for the cheapest. We had a few of them in the past, thanked them for their interest, and moved on. They're a waste of everyone's time.
Have you ever tried to figure out why that is and whether you can change that (maybe by moving on)? I would strongly recommend you read some of this: https://daedtech.com/
Not new either (as in "stupidity and universe are infinite... well, we're not sure about the universe"). 20+ years ago had to deal with the aftermath of someone selling a customer a bunch of totally unnecessary Stratacom switches because everyone knows you need ATM to run MPLS.
BTW, you might enjoy this video https://www.youtube.com/watch?v=ClKEkCRvWTQ