A little while back, I wrote a blog entry that used a Venn diagram to look at how the employee, the IT department, and the business needed to be in sync in order for BYOD to work in an organization. The use of the Venn diagram seemed to go down well, so I thought I’d use it again to demonstrate a different area of concern to an organization — how it chooses its IT suppliers.
I’ve just returned from a trip to listen to a major IT vendor discussing how its research had shown that organizations were now looking for no more than five vendors on any IT procurement list. This can be a problem — particularly where an organization wants to make sure that all bases are covered and that best-of-breed is still an option. However, to avoid finger-pointing between vendors when something does go wrong and the costs associated with managing many multiple different contracts, it is important to minimize the number of vendors used in any IT platform.
For example, if we look at procurement in data center, we now have four major trends in how software may impact hardware purchase decisions: software-defined computing, storage, and networks, leading to a software defined data center (SDDC).
In the post “Will SDN+SDS+SDDC=SDC?”, I looked at the problems of three different approaches to software abstraction possibly leading to software defined chaos — a means of optimizing the choice of vendors is needed so as to avoid such chaos.
The Venn diagram above should help buyers with this. The three inner circles show the components required to create an IT platform; servers, storage, and network, each with their own software abstraction layer. The outer circle brings in the concept of private cloud computing, which, if abstracted through the use of software-defined data center concepts, should lead to the capability for interoperability across hybrid cloud (private plus public) deployments.
The trick then is to position your choice of vendors on the diagram. For example, vendor “A” may be a pure-play vendor with nothing but storage, so it would go into the “Storage” circle. Vendor “B” may be a pure play network vendor – so it goes into the “Networks” circle. Vendor “C” may have both server and network capability, so it goes into the overlap between “Servers” and “Networks”.
By laying out the various vendor options in this way, you can then optimize the vendor choice, bringing the number of requirements down through using the overlaps carefully.
However, even if a vendor fits into the triple overlap, it does not necessarily mean that you have found the ultimate answer — there still may be some point functional solutions required. The diagram can still help here: if the vendor that crosses over all three areas is weaker in its approach to, say, networks, position it more to the server and storage side of the central overlap, and then identify a vendor in the networks circle that helps to move the overall solution towards the center.
Provided that the vendor community follows the basic concepts of the “software defined” world, pushing for a good enough level of standards, the optimized choice of vendors will then provide a platform where the three levels of software abstraction — software defined computing, storage and networking — will all come together to provide a platform that will be flexible, manageable, and responsive as a software-defined data center.