When reading marketing literature as an engineer, you must always be careful to parse the words correctly. For example, I was reviewing a vendor’s pitch deck on a new hardware switch. The switch was described as having the following attributes.
- Cloud-native
- AI-driven
- Secure
- Next-generation
From an engineering perspective, nothing of value has been described to you in that list.
I have no idea what they are trying to get at with cloud-native. I can think of no greater antithesis to “cloud-native” than a chunk of hardware you bolt into a rack to do network things. Someone on Twitter suggested that because the switch supports ZTP, it’s cloud-native…which, if so, is comedy gold.
AI-driven means…what, exactly? That there is some AI on the switch itself doing data analysis and changing the network configuration in response to whatever the algorithm thinks is best? It could mean that, although then we’d have to discuss what’s meant by AI, whether or not the “AI” is happening off- or on-box, and why that’s different from software-defined.
Secure is a word you sprinkle over every technology product. Because of course it’s secure. But again, what does secure mean in this context? That the switch was built with supply-chain integrity and cryptographically provable hardware identity? Maybe. Or it might merely mean that the switch has a login prompt when you try to get at the CLI over a console port.
Next-generation? Who knows? Sounds impressive, though–I mean, who wants that crappy last generation stuff? Of course I want the next generation!
These words are not for you, the engineer. The dog whistle is blowing at a frequency your ears are not attuned to. These words are meant to entice folks with purchasing authority. Your boss. Or his boss. Or her boss. Marketing buzzwords echo the terminology popularized in reports by analysis firms such as Gartner, selling the idea that this vendor’s product does all the things the Gartner report says it’s supposed to.
Don’t Infer–Verify
The problem with these vague words is that you might infer a feature that is not actually a product capability. That’s where your job as an engineer comes in. Use these words as a starting point to discover and understand the specific capabilities the product has.
Let’s revisit the claim of cloud-native. You can infer that the vendor is intimating some sort of cloud functionality. What is that functionality, exactly? Once you figure out what the function is, you can decide if it would help the business with, say, IT operations, security posture, bringing a product to market more quickly, etc.
That’s one of your roles as an engineer: translating non-specific buzzwords into specific capabilities so you can make architectural decisions. When you can do that, you bring significant value to your organization, as you become an arbiter of product usefulness.