Netapp's Val Bercovici, AKA Big Data Czar, says that, in the cloud hierarchy, data is foundational and most valuable and that we can reach it and share more easily than ever before. It is because of this that we are able to use it in ever more creative ways such as Big Data (yes, big B, big D) to create value for our organisations.
He also said that the amount of data stored tends to exceed the capability of the network to carry it and why analytics and Big Data are done locally to the data rather than remotely. Cisco and telecom companies will be happy to note that uploading and downloading data is not simple and subject to the contraints of the network forcing any organisation or person who wants to move these quantities of data to buy more bandwidth.
Ultimately, the infrastructure planning and architecture should depend on where data will be stored, your governance, minimizing data movement, and maximizing data use.
Showing posts with label TCO. Show all posts
Showing posts with label TCO. Show all posts
Oct 15, 2012
Live Blog -- Cloud Launch: Jeff Seifert
Cisco's John Seifert discussed their cloud strategy and the rationale behind building a pool of compute and storage resources that is embodied in the UCS and how workloads and storage can be moved dynamically from data centre to data centre using the fabric.
Seifert pointed out that Cisco has been developing flexible IT for some time now and has reduced the time to deliver from 6-8 weeks to 2-3 weeks to around 15 minutes.
The cloud is not just one thing, according to Seifert, because of regulatory environments, the needs for security, connectivity, cost structure etc. And all of this over a public-->private continuum. So true.
Seifert pointed out that Cisco has been developing flexible IT for some time now and has reduced the time to deliver from 6-8 weeks to 2-3 weeks to around 15 minutes.
The cloud is not just one thing, according to Seifert, because of regulatory environments, the needs for security, connectivity, cost structure etc. And all of this over a public-->private continuum. So true.
Mar 7, 2011
Basic strategy for moving to the cloud
Flexibility is key. Spinning up instances, regardless of whether they are with AWS or not, needs to be easy, scalable, and allow for various operating systems, development environments/programming languages, and databases.
There are 2 basic strategies that are common to Startups, SMBs, and Enterprises: create new services/apps; migrate existing services/apps.
Justification for the business depends on TCO and must balance the cost of capital to acquire infrastructure vs. the expense of leasing temporary infrastructure.
Going to take a closer look at the AWS "economics" later.
There are 2 basic strategies that are common to Startups, SMBs, and Enterprises: create new services/apps; migrate existing services/apps.
Justification for the business depends on TCO and must balance the cost of capital to acquire infrastructure vs. the expense of leasing temporary infrastructure.
Going to take a closer look at the AWS "economics" later.
Sep 24, 2010
Two years on and SaaS is still around!
I came across an interview I read a while back (August, 2008) in which Harry Debes, CEO of Lawson, claimed that SaaS was a passng fad that would pass like its previous incarnations, "service bureaux" and "application service provider".
Well, here we are, two years later, and SaaS has picked up steam. The main strength of SaaS is the huge savings on CAPEX that Debes neglects to mention in his interview. It's true that, on the surface, SaaS appears to be a form of software license financing; a monthly charge per user that includes licensing and support/maintenance instead of an upfront license fee and annual maintenance fees.
That said, there are benefits for both the customer and vendor. The customer, obviously, benefits from the reduced investment in infrastructure required to run software on premises. The vendor, however, can leverage the same environment for multiple customers which increases the utilization rate of the infrastructure but lowers the monthly cost to its customers (or pockets the extra margin).
Organizations use SFDC because it works and it's relatively cheaper than installing servers and DBs to run a CRM application on premises. If it were not available in a SaaS format, would it be as popular? Possibly. But if it didn't work that well, would it be as successful as either a SaaS or on premise offering? Probably not. The market has a way of weeding out bad software.
Theoretically, all software that is offered on premises and as a service has a tipping point at which the decision to build or buy is made. This is why, regardless of what Harry Debes or Larry Elllison say, organizations need to evaluate the costs of each option, the total cost of ownership, and make an informed decision based on that information and not the hype.
Well, here we are, two years later, and SaaS has picked up steam. The main strength of SaaS is the huge savings on CAPEX that Debes neglects to mention in his interview. It's true that, on the surface, SaaS appears to be a form of software license financing; a monthly charge per user that includes licensing and support/maintenance instead of an upfront license fee and annual maintenance fees.
That said, there are benefits for both the customer and vendor. The customer, obviously, benefits from the reduced investment in infrastructure required to run software on premises. The vendor, however, can leverage the same environment for multiple customers which increases the utilization rate of the infrastructure but lowers the monthly cost to its customers (or pockets the extra margin).
Organizations use SFDC because it works and it's relatively cheaper than installing servers and DBs to run a CRM application on premises. If it were not available in a SaaS format, would it be as popular? Possibly. But if it didn't work that well, would it be as successful as either a SaaS or on premise offering? Probably not. The market has a way of weeding out bad software.
Theoretically, all software that is offered on premises and as a service has a tipping point at which the decision to build or buy is made. This is why, regardless of what Harry Debes or Larry Elllison say, organizations need to evaluate the costs of each option, the total cost of ownership, and make an informed decision based on that information and not the hype.
Jun 9, 2010
More on ROI and the Economics of Cloud Based Services
InformationWeek::Analytics issued a report earlier this month entitled, "Cloud ROI: Calculating Costs, Benefits, Returns," which compares the costs of acquiring hardware and the costs of utilizing cloud based services and the associated ROI. While the basic analysis of the costs makes sense, the comparison is flawed: the difference between the two is cost savings, not ROI.
The spreadsheet attached to the report is fairly straightforward. All costs involved in the acquisition of capital assets vs. leased assets (i.e., on demand) and the related costs are listed and compared. A present value calculation is performed to show the total cost of ownership over a number of years. It is evident that cloud based services are cheaper than acquiring capital assets for the same purpose. This forms the basis for the ROI calculation but the report never actually calculates the ROI; it gives the reader just enough information to be misinformed...
To make the numbers make more sense, the report needs to add a revenue stream. That revenue stream would allow the reader to find the breakeven point. And, if there was enough time, the report could go further and examine the impact of asset lifecycle and the replacement of capital assets versus using leased assets over time. In this case we would see the economic value of using assets on demand instead of acquiring them.
The one statement, from Lew Moorman, Chief Strategy Officer of Rackspace, with which I agree is that organizations need to evaluate how to make cloud based services fit into their IT service catalog rather than whether they can save money by migrating everything into the cloud. The latter discussion is probably not going to be very productive since not all services can be or should be moved into the cloud though, financially, it might make perfect sense. IT and Finance often butt heads.
In previous posts (here and here) I discussed ROI of Cloud Based Services and how it is often confused for cost savings, touching briefly on the concept of breakeven.
The spreadsheet attached to the report is fairly straightforward. All costs involved in the acquisition of capital assets vs. leased assets (i.e., on demand) and the related costs are listed and compared. A present value calculation is performed to show the total cost of ownership over a number of years. It is evident that cloud based services are cheaper than acquiring capital assets for the same purpose. This forms the basis for the ROI calculation but the report never actually calculates the ROI; it gives the reader just enough information to be misinformed...
To make the numbers make more sense, the report needs to add a revenue stream. That revenue stream would allow the reader to find the breakeven point. And, if there was enough time, the report could go further and examine the impact of asset lifecycle and the replacement of capital assets versus using leased assets over time. In this case we would see the economic value of using assets on demand instead of acquiring them.
The one statement, from Lew Moorman, Chief Strategy Officer of Rackspace, with which I agree is that organizations need to evaluate how to make cloud based services fit into their IT service catalog rather than whether they can save money by migrating everything into the cloud. The latter discussion is probably not going to be very productive since not all services can be or should be moved into the cloud though, financially, it might make perfect sense. IT and Finance often butt heads.
In previous posts (here and here) I discussed ROI of Cloud Based Services and how it is often confused for cost savings, touching briefly on the concept of breakeven.
May 19, 2010
More on Cost Savings and ROI
I recently came across the following Google ad on a UK web site.
(The ad, admittedly, was much more fun to watch on the site, with spinning dials and all...)
It was also a link to a calculator to estimate the cost savings that an organization could realize by migrating their users from the traditional MS Office suite (Outlook, Word, Excel, PowerPoint, etc.) to Google Apps provided over the web (Gmail, Docs, Spreadsheet, Presentation, etc.). (This link brings you to the international version of the calculator.) The site allows visitors to calculate their potential savings on a 3 year engagement based on the number of users served, the hourly cost of the IT manager's time, and some basic assumptions on hardware and license costs. By itself, this is a compelling argument to switch to SaaS.
The interesting thing about this ad, is that Google called it the 'cost savings' and not the 'ROI' of switching to Google Apps. The calculator does the calculations and then shows the costs of both MS and Google scenarios and the difference in TCO between the two. If one is lower than the other, there is a cost savings for switching to the solution with the lower TCO.
Kudos to Google for getting it right!
May 17, 2010
What, exactly, is ROI?
The acronym, ROI, means 'return on investment'. In other words, if I make $1.10 for every $1.00 spent on a project, my return on the $1.00 invested is 10%. Used in the context of cloud computing, this is incorrect.
When we talk about the economic benefit of cloud computing, we assess the difference between the total cost of ownership (TCO) of owning and operating the necessary infrastructure to make our applications available to customers and the TCO of of leasing that same infrastructure on demand. All else being equal, more than likely, the cost of owning and operating will be higher than leasing on demand. This is a cost saving proposition, not a ROI. In this case, we should be looking at the breakeven point--the point in time at which we have paid off the expense and get into the black.
What is usually missing from the evaluation of these cost savings is the sunk cost of application development: either way, those $ are going to be spent and are considered to be an investment. Aha! Now we're talking about investment. If TCO is (assumed) to be lower when leveraging a cloud environment, then it follows that the ROI will be higher.
Consider the following basic scenario:
Note that the OPEX is higher in the lease/on demand scenario. This is because most of the CAPEX that would have been incurred in an ownership scenario become OPEX in a lease/on demand scenario. So, when comparing the ownership and lease/on demand scenarios, the economic benefit, or return on the initial development investment, would be greater in a cloud based scenario. If we had considered an pre-existing application and its displacement to the cloud, then we would have been discussing a cost savings, and not a ROI.
When we talk about the economic benefit of cloud computing, we assess the difference between the total cost of ownership (TCO) of owning and operating the necessary infrastructure to make our applications available to customers and the TCO of of leasing that same infrastructure on demand. All else being equal, more than likely, the cost of owning and operating will be higher than leasing on demand. This is a cost saving proposition, not a ROI. In this case, we should be looking at the breakeven point--the point in time at which we have paid off the expense and get into the black.
What is usually missing from the evaluation of these cost savings is the sunk cost of application development: either way, those $ are going to be spent and are considered to be an investment. Aha! Now we're talking about investment. If TCO is (assumed) to be lower when leveraging a cloud environment, then it follows that the ROI will be higher.
Consider the following basic scenario:
Subscribe to:
Posts (Atom)