Is your organization moving to a cloud model through a well thought out RFP with at least 40 requirements? May I suggest that you rethink this model. The RFP approach with a committee generated wish list may work in some situations, or even be required, but in general the IT shops that really differentiate themselves go Agile for the cloud. What does that mean?
In our business unit we have turned the development of our Cloud Automation platform: Intelligent Automation for Cloud to an Agile development methodology and process. This means when I ask if we will have a certain feature in our 3.1 version, I get an unexpected answer: we won’t know until close to the ship date. Going agile means we work off a backlog of user stories versus a hard and fast set of features that MUST be in the release. We can ship at anytime with the right methodologies in place.
This approach also works for our customers in building their clouds with our software stack. Agile cloud builders have a set of cloud user stories that they are implementing and may release the updated version of the cloud functionality every quarter, or even every 2-3 weeks. When relaying this approach that one of our customers is taking to another customer considering our solution, I could see a twinkle in his eye as he said: I bet that could really help differentiate the value the IT organization provides. He got that right.
We sell to customers who have RFPs and those who look for capabilities, roadmaps, and more importantly an alignment of vision and approach to cloud automation. Many cloud builders look for vendors who will grow with their agile cloud and one that has an open and extensible model to build new use cases with. Why is that of paramount importance? If you think you know what your cloud needs six months from now, good luck. If you bet on the fact that your business and technology requirements will change before you get to your next release of your cloud you will need an agile cloud builder methodology.
Back to responding to, SIGH, another RFP.