When Jeff Browning was at NetApp we always paid close attention to what he said. Now he is at EMC, which is interesting. When Jeff speaks, it is still a good idea to pay attention:
Jeff has recently started a blog which is worth reading and it sheds some light on why things seem so confusing for NetApp’s customers lately.
It seems to start with management –
Bruce Clarke (who has now left NetApp and probably does not mind my quoting him) once told me “NetApp is the best lead and worst managed company I have ever worked with.” A sentiment with which I must admit that I agree. NetApp does the vision thing very well, no question. It’s NetApp’s implementation that kind of screws the pooch.
An example would be core ONTAP development. While I was there during the last part of my tenure, NetApp shipped ONTAP 7, which contained the functionality of flexvols. I was involved in the alpha testing of this product as it related to Oracle. I went to Engineering and asked about the path for migration from traditional volumes to flexvols, and was assured that there would be a tool to accomplish this built into the product. However, when ONTAP 7 shipped this tool had fallen off the truck, due to scheduling issues. This was never communicated to me (or pretty much anyone else from what I could tell) until after the product was about to ship.
The result was a train wreck. Many, many customers were justifiably upset when a feature which was a critical part of the ONTAP 7 release was denied them as they were marooned onto traditional volumes due to lack of ability to migrate. This problem became embarrassingly common.
Another similar issue was the creation of a version of ONTAP based upon the SpinOS, acquired with Spinnaker. I sat in an meeting where Engineering explained that they had “run out of seats at the game of musical chairs” which they called ONTAP development. In the threads of ONTAP 6.5, ONTAP 7, and the SpinOS based product, they basically had run out of capacity to develop. The result was the necessity to triage the development of a product line. The company made the bet on the SpinOS product, and dropped development of ONTAP 6.5, long before ONTAP 7 was ready for prime time. This resulted in yet more pain.
And the decision was made to ship the SpinOS product as a NAS-only version, and maroon SAN customers onto ONTAP 7 for an extended period of time after the ONTAP 7 product was ready to be replaced.
And he continues…
Another similar issue was the creation of a version of ONTAP based upon the SpinOS, acquired with Spinnaker. I sat in an meeting where Engineering explained that they had “run out of seats at the game of musical chairs” which they called ONTAP development. In the threads of ONTAP 6.5, ONTAP 7, and the SpinOS based product, they basically had run out of capacity to develop. The result was the necessity to triage the development of a product line. The company made the bet on the SpinOS product, and dropped development of ONTAP 6.5, long before ONTAP 7 was ready for prime time. This resulted in yet more pain.
This is really interesting.
Based upon these sorts of decisions, I took the position (which I still maintain), that NetApp would have been better off taking the millions they spent on Spinnaker out onto the parking lot in Sunnyvale, chunking them into barrels, soaking them with gasoline and torching them. Spinnaker was a net loss for NetApp in development energy and momentum, regardless of money. Spinnaker made false promises and created false expectations. All they added was confusion.
As I have said before many times ” you can’t make this stuff up!”