The difference between an architecture and a product
By joe
- 2 minutes read - 277 wordsThis will be a short comment on something I have noticed with engineering led startups. The hardware oriented ones tend to have really neat architectures. Everything is technically beautiful. One problem though. They are not products. A product is finished. It has all the features one might expect out of a product. Yeah, this is a tautology. You don’t buy a car with the engine inserted, but no fuel lines hooked up, no instrumentation attached. The engine is the architecture. The final car on the showroom floor is the product. Unfortunately, I have seen far too many architectures recently disguised as products. The are not finished. They are missing things. One should not surprise the customer/end user. One vendor who shall remain nameless had a product (a network card) that did some neat things. Even PXE booted. Of course it required a firmware load after the PXE boot to come up to a functional state. Which meant that unless you built the kernel with the driver/firmware embedded (you couldn’t, and their engineering director was surprised that anyone would want that …) after PXE booting, it would just sit there … Um…. no. This is not what you want. The engineers do understand the myriad of details of the product. And they need to put it together into a coherent story to explain to a disinterested 3rd party. Who will promptly find the holes that they miss. Thats the difference between the architecture and the product. Too many startups ship architectures, not enough ship products. Customers for the most part want products. Some may be willing to tolerate architectures, but not all will. Especially not mission critical ones.