Our industry operates in two parallel universes.  In universe A, everything is moving to software defined.  If all you did is listen to presentations by vendors or read trade journals, you might think that everyone is buying software defined everything.  How does the industry explain software defined:  Software Defined is where a commodity hardware’s personality/function is defined by the software it is running.  In other words, if you take a commodity server and add SDS (software defined storage), you get a storage array; if you add SDN (software defined networking), then you get a switch or any other networking device.  This, of course, sounds great.  As an end user I buy hardware from my favorite vendor, load the software, and WHAM, I have a solution.  The reality is what we get in universe B.

In universe B, the end users want a solution that guarantees performance, reliability, and capacity.  The users want real time support of the solution; when something goes wrong, and there is always something that goes wrong, the end user doesn’t want to start calling the different vendors to figure out who is at fault.   This is why solution architects and systems administrators seek offerings that have been tested, have certified interoperability with other components, and where “how to” is straight forward.  So how do we reconcile what the customer wants to hear and what the industry touts and what the customer ends up wanting to buy and use?

The answer is that we need to define concepts a bit differently.  If the idea of software defined is that the software runs on commodity hardware but the customer doesn’t want to do all the integration and support, then what we really have is “Software Designed”.  Software designed means that the software is developed to run on commodity hardware but there is a defined hardware configuration that has been tested and certified for reliability, performance, interoperability and that the software and hardware are delivered together with one point of contact for support.  This concept is not about how the software is developed but how a solution is brought to market.

Let’s remember:  customers don’t want cloud, they want a more efficient, just in time paradigm in consuming and paying for the IT resources.  Customers don’t want software defined, they want a system where the hardware is commodity, therefore lower cost to procure and maintain, and software that is agile and responsive to the evolving needs of the users.