The difference between an architecture and a product

This 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.

2 thoughts on “The difference between an architecture and a product”

  1. That is the typical problem for many startups and not just on the hardware oriented side. There is a reason “platform” became an ugly word. Too many companies focussed on platforms and not on products. A platform is great and serves a purpose, but platform as business model usuall does not work.

  2. I have seen this in computing, and bioinformatics, with the small bio-tools companies. Their tool becomes their raison d’etre, and they convince a few people of the value of it.
    I am sure it is a common problem across multiple industries. A platform requires evangelism and education to gain market traction. Or you can go the “open source” route and gain massive adoption (very rare) to get the base you need to go forth.
    I agree though, it is not viable business model in most cases. My perception is that the architecture approach raises barriers to adoption as it makes adoption harder. The onus is upon the purchaser to build the rest of the infrastructure. Works great when there is trust and cooperation between the purchaser and the supplier. Not so great when it requires the additional efforts of selling the architecture and evangelising the benefits. Not that the architecture increases risk, rather that the lack of a complete product makes the sales job to the customer, and the customers sales job to their management/money people that much harder.

Comments are closed.