Pros and cons of External Cloud Services

Nowadays, the cloud is everywhere. All software you see and all providers propose cloud brokering via their Datacenters, platforms or software. Now what are the real cloud drivers? We often speak about cloud acceleration but rarely speak about issues that arise when you start playing in the cloud...

The good points with the cloud :

• It is fast and flexible (from a service ramp up / down perspective)
• It usually implements the very latest technology and software platforms
• It is usually very adapted to geographically dispersed solutions, allowing resilience and regional / local implementation of global solutions across the globe
• You don't have to handle capacity reporting and planning of the environment... just pay as you go
• For some very specific requirements, you can have your environment online only a few hours per day (when you really need it). The rest of the time, you turn it off and limit the cost, which is not as cost efficient when done on your owned assets
• You run on a standard operated environment
• There is a huge varitery of services (IaaS, PaaS, SaaS) to subscribe out there. Cloud solutions are usually financial efficient when you buy PaaS or Saas. IaaS will usually let you manage a level of complexity between your in-house architecture and the cloud infrastructure which adds complexity and overhead to your teams

Now the drawbacks of these kind of services : 

• As soon as you have a certain volume and a sustained growth, public cloud is usually more expensive that in house
• If you don't run on standard "off the shelf" applications, the cloud can be a real issue for you. Even though upgrades are planned and predictable, there is no place for blocking upgrades of versions. Should your application not support that intense patching roadmap, you will be really bothered
• Service transfer from cloud services can be a real pain point. A very simple example I went through was when using an SAP on an "as a service" mode. When attempting to exit that service, and without any clear contractual statement, I was explained that the SAP image itself was the intellectual property of the vendor. As a result, a complete replatforming of the SAP environment had to be done, follow by a data synchronization.
• Data reversibility is an extension of the issue above. Be sure, when contracting a cloud service, that you have the right conditions for a transition out. Vendor "lock in" is one of the most common issues on the cloud. 
• Most cloud services come with limited to no SLA. Cloud providers prever to commit on means than results. Be aware of this before putting any critical service in the cloud
• Cloud is usually not recommended for critical data. Indeed, it is always complicated to impose data location to cloud providers. Moreover, cloud providers are usually seen as a big regulartory risk since the staff managing the cloud platforms is geographically dispersed and you usually have no control over this

Cloud services continue to progress and seduce more and more companies. They remain perfect for either temporary workload hosting (IaaS) or complete end to end solution hosting (PaaS or SaaS, where limited integration is required with your core company services. 

Keep in mind that cloud services are extremely standardized but always come with limited SLA commitment and a very limited framework. As such, either you will need to be a major player to get an appropriate contract or you will have to accept the risks on the services you contract.

To conclude: should you have a sustained growth, internal private cloud with capacity on demand will be the perfect solution. For other cases, or off the shelf platforms, hybrid or public cloud can greatly enhance your capabilities but keep in mind that getting strong commitment on SLAs and legal / auditability aspects will remain a challenge for you. 

RFP General Principles - RFP for hardware / software with an integration project

Many people would want a complete RFP document sample, which would let them almost copy paste the document, adapt it a little, change the fonts and header and reissue the document. Before providing such examples, it is key to understand what are is the best way to break down an RFP in order to make it easy for you and the vendor to analyze, and understand your expectations.

The structure of your document I suggest is the following :

1. Overview 

- 1.1 Company Presentation : this gives an overview of your company, with global figures (employees, business units, sales or revenue figures, key growth drivers...) 

- 1.2 RFP Context : this is often omitted but more important than you think. It provides the general context of the RFP and lets the suppliers understand if you are just replacing a deprecated platform or planning something scalable to take on a huge business growth or increase flexiblity on your services

2. Project Expectations

In this section, add one chapter per expectation. Based on whether you expect the RFP to be service / SLA driver or a very technical design based on a BOM (bill of materials), you can put several sections. These sections can be related to availability, resilience, flexibility, capability to scale up or scale out the solution... but also be technical requirements such as imposing your standards regarding management network (do you impose a non routed OOB management network), security access (should everything be authenticated against your corporate active directory), do you have specific connectivity & protocols (e.g on a Nexus core stack, you would have LACP network connections, meaning specific teaming settings on network cards). specific plugins with other platforms, reporting and capacity mangement feaures (capacity and performance trending...)

3. Instructions to bidders

- 3.1 : Key contacts (name, function / role, email, phone): indicate the SPOC (single point of contact for the project). Usually, on big projects, you have a project manager, the project sponsor or team leader and a guy from the procurement

- 3.2 General information for the bidders : in all RFPs, you should given the global guidelines to the bidders to avoid any surprises when attempting to close the deal at the end of the RFP cycle. Such general information would be :

• Proposal acceptance requirement : indicate language in which you expect the bidder's answer, the currency in which prices must be given, if you impose a fixed exchange rate against standard currencies such as dollar (because your budget is stable since it is based on a hedged currency)

• Proposal validity period

• Non disclosure information

• Non compensation conditions : indicate that no kind of compensation will be provided for manpower and costs associated when participating to this RFP

- 3.3 : Timelines : it is compulsory to provide timelines with your RFP, so that bidders know precisely what is expected and when. This is usually summed up in a small table with the key dates (date, milestone, action owner, communication medium)

- 3.4 : Questions for clarifications : be clear about your rules on questions :

• Best practise would be that you have a milestone in section 3.2 Timelines indicating the hard stop for questions & answers

• In this section, you should indicate to all bidders if you allow yourself to disclose their questions anonymously to other bidders, should the questions be interesting to share

- 3.5 Evaluation criteria : be very clear on how you will assess their reponse :

• Is your project TCO (total cost of ownership) driven? 

• Are you going to check compliance of the bidder's answer with you RFP requirements?

• Are you looking for a solution with proven stablity & flexibility

• Will you expect reference calls and reference presentations to prove the bidders professionalism?

• Will you be expecting a very clear vision of the project, resources to engage, efforts expected on your side, planning...

- 3.6 Proposal Structure : this is where you impose a certain level of structure to the bidders' response. It is key to get this part neat. Indeed, if all proposed are aligned in a  "template" format, parsing the answers and comparing the bidders will be very simple. The usual information I expect in a response to an RFP is the following :

• Executive summary
• Bidder's presentation (I usually supply an excel sheet to impose the information I am requesting : turnover, operating income, best in class resellers and integrators, similar project references...)
• Technical solution : this is where you have to turn verbose mode on, indicating all RFP technical deliverables (high level design, low level design, power consumption, maximum capacity and performance of the solution 
•  Project Organization : explain all mandatory phases you expect the bidder / integrator to perform during the integration project (design workshops, activities, onboarding of your internal resources, reporting details and frequency)
• Financial Breakdown of the proposal : here again, provide an excel sheet the bidder should fill in and put all the fields you expect him to fill in (unit public price, unit proposed price, quantity, total price, taxes, non recoverable taxes , project costs, training and handover costs...)
• Terms and conditions : this is usually an internal document provided by your legal or procurement team