.jpg)
Post number 5 in a series of 12 from one of our provider partners, NTT.
My original foray into the world of IT was as a Project Manager for a project where we were migrating an application that ran on a proprietary database to one that was using an Informix database. There were always numerous deadlines on the project. The more time it took to develop the application, the more the project cost the company. It also affected the end price that they wanted to charge the customer, as well as when they could actually sell the product to recoup the cost of development. Timeframes were either self-imposed or thrust on us by outside situations. For example, we were recently working with a large service provider who was creating a cloud-based solution for their educational customers. We started talking to them in the September time frame. They wanted to be up and running by the start of the New Year. Their reasoning was that most universities had an extended holiday break so they could take down the systems and migrate the data with less impact.
On countless occasions we have worked with customers that had a specific date that they needed a project completed. Whether it was for a big rollout of a product or some drop-dead date for a project, there was an end date that had to be met. Vendors and customers would go back and forth haggling over price and features and benefits of the proposal. In the process of negotiation time slips away and the deadline comes closer. When a decision is finally made, super-natural feats by both the vendor and the customer need to happen in order to accomplish the project in the compressed time frame. For the customer that I mentioned above, it took them two months to decide on the vendor.
There is also a lot more involved in purchasing hardware than evaluating the options and pulling a trigger. There is a timeframe for availability of components from the vendor, there are delivery time frames, there are holidays, people’s schedules, and setup time involved in getting everything ready so someone can start doing the real work. Any one of a hundred things could (and often does) go wrong to push back the schedule.
If a project has a very short time frame and hardware procurement may end up being an issue, you may want to look at a Public or Hybrid Cloud environment. Cloud environments provide great alternatives for those people experiencing a time crunch.
• Infrastructure can be stood up (or already is) in a matter of minutes. And better yet, instead of paying maintenance on a purchase that may have sat on a loading dock or a staging facility for months, you only pay for it when it is used.
• You don’t have to wait for other infrastructure components to be built out, like construction, cabling, cooling, space, etc. Many people make the decision on a project without looking at the entire scope. They may assess the cost of servers and storage, but forget about determining where to put things, how to power and cool them or how to connect to them. I have had customers purchase hardware that sat in the facility for several months because they didn’t fully plan out the project. They did a good job of getting the hardware but a poor job of making sure there was a place to put it. This is not a problem in public cloud environments.
• From a project management standpoint, both the cost and timeframe of a project can be reduced. A reduction in the cost of developing or rolling out a solution means a better ROI for the project.
• Cloud providers’ service-level agreements have some teeth to them. If you were to create the environment on your own and fall behind schedule you would have no one to blame but yourself. Cloud providers give you SLAs that have penalties for not meeting deadlines that you wouldn’t get internally.
• Building your own individual private cloud can provide some of the same benefits, but someone still needs to make that upfront investment. And someone still needs to manage it.
There are some considerations when thinking about using the cloud for projects with tight timeframes, including:
• Make sure that you plan for the permanent state of the applications. If this is a development project that eventually will make it into production, you need to analyze if the production instance will also run in the cloud or will you bring it in-house. If you are bringing the project back in-house, how easy will it be to migrate it back into your environment?
• Can the vendor work with you to ensure that your IT policy and procedures are adhered to?
• Do you have the appropriate security in place for your project?
• What about LAN and WAN connectivity to the cloud provider?
You have to think about all these factors, but in the end I think you will find that the cloud can help you satisfy the need for speed.
Next Post: Moving Enterprises to a Public or Hybrid Cloud Part 6- Moving, Upgrading, or Consolidating Datacenters
Contact StrataCore to learn more about NTT America Cloud services (206) 686-3211 or stratacore.com
About the author: Ladd Wimmer
Ladd Wimmer is a valuable member of the NTT Communications team. He has over 15 years of experience implementing, architecting, and supporting enterprise servers, storage and virtualization solutions in a variety of IT computing and service provider environments. He worked as Systems Engineer/Solution Architect in the Data Center Solutions practice of Dimension Data, most recently serving as technical lead for the roll out of Cisco’s UCS and VCE vBlock platforms across the Dimension Data customer base. Ladd has also run two IBM partner lab environments and worked for an early SaaS provider that created lab environments for Sales, QA testing and Training.
{{cta(’35f3e6a4-addc-4538-b9d9-fc6e80c42539′)}}
