Software as a Service and Cloud Computing have been in the tech news lately, and lots of companies are pitching these two areas very heavily. I use various services that fall into these categories, so I thought I’d clarify the area a bit.
All the things that make up computing technology fall into these general categories:
- Computers you use directly (like laptop and desktop computers and hand-held devices like BlackBerries and iPhones). These can be called “clients.”
- Computers you use indirectly. These are usually called “servers” because they serve up things, like data, email, video, etc.
- Data Storage. This is a sink of “space” that is used to store structured information, like accounting data, and unstructured information, like documents and music. Data storage can be local (a hard disk or CD), or remote (network “drive,” ftp server, Storage Area Network (SAN), web server, or shared locations on others’ computers).
- Networks. These link computers of all types together. The Internet, the telephone network, home and office networks (both wired and unwired), mobile phone networks. This would include all the devices that are used to access or traverse the network, like routers and modems.
- Printers, screens, keyboards, etc. These are the things you use to physically interact with computers.
- Applications. These are the programs you use to interact, work, and play with computers. Applications are programs like email programs, spreadsheet and word processing programs, internet browsers, music and video players, and enterprise systems such as accounting/financial systems, Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) systems. Applications are also called Software. The computers, devices, networking equipment, and data drives are called Hardware. There is an area in between in which Software acts like Hardware, which is virtualization.
So, in short, you use a computer or device to work with (or play with) data (“stuff”) from either your own computer, or from other computers, using applications.
In addition to using computers, you can also be someone who provides or manages applications for others to use. In this category are software vendors, information technology departments, consultants, and designers.
So, given the above, we have a number of ways we can do the above.
One way is to have all the equipment at our location or locations. We have laptops, desktops, servers (each running one core application – email server, database servers, security server, file server, etc.), networking equipment, racking, power back-up systems and conditioned power, tape and disk back-up systems, fire suppression, air conditioning.
Another way is similar to the above, except that we virtualize the servers, meaning that instead of one application per server, we have a few really beefed up servers and data storage, and software such as VMWare ESX to run virtual servers. A virtual server is software acting like a real physical server, except that it’s not. So, we can have twenty or thirty of these virtual servers running on four to five beefy servers running VMWare, XEN, or similar. This is an important concept in cloud computing, but cloud computing is not the same as server virtualization.
Another way is to have some or all of your computing environment hosted at a hosting vendor, such as Rackspace, Terremark, or RagingWire. You pay them to set up, maintain, and manage your servers and data storage, and you run your applications on them remotely. These are physical servers and data storage.
Note, as we do this, that we are moving away from everything at your location managed by your people, to everything off-site, managed by someone else. But we are not done.
Now, take the server and data storage hosting idea, and make two changes. One, make the servers virtual servers, and the data storage virtual data storage. Two, make them location-less. That is Cloud Computing. Cloud Computing means running your applications on virtual servers and infrastructure located somewhere else, usually reached by the Internet.
As an example of Cloud Computing, Amazon has “Amazon Machine Instances.” These are virtual servers running on Amazon’s equipment. You choose the operating system, and you pay by the hour when its running. Other than the region of the world it is in (the U.S. or Europe), you have no idea where it is physically located. And, it does not matter. Same with the data. In its Simple Storage Service (“S3″) data is stored in “buckets,” again, in the U.S. or Europe. You ask Amazon to save it, and you ask them to bring it back, and they do. All the complexity of maintaining machines, backing up data, physical security, racking, cooling, swapping broken disks, replacing broken servers, upgrading and refreshing hardware every few years… that all goes away. In its place, you get a virtual server floating somewhere in space, accessing data stored somewhere else in space.
Now, for a person who uses computers, this does not mean a whole lot, because when done right, someone opening a file from a server, or opening a web page, or accessing email, or posting a G/L transaction will really never know where the server is anyway. But, for a provider of applications, like software companies, IT departments, web designers, etc., it is huge. You remove all the complexity of managing what is really very complex equipment, which allows you to focus on the applications you want to provide to your constituents. If you run a web-based company, for example, that sells flowers, you can get your company to runs its web applications “in the cloud” allowing you to focus on the features of your web store. If you are a CIO, you can move your corporate applications to “the cloud” and remove the requirement for a huge data center and people to even think about how to manage a Windows or Linux server.
Cloud Computing is also huge for executive management, especially CFOs and CEOs. Because maintaining IT assets is such an expensive endeavor, and because for most companies IT skills have nothing to do with the product they are selling (in other words, IT is “not core to the business”), Cloud Computing allows the company to potentially save a lot of money as well as focus its employees on the job at hand: making and selling the company’s products. Now, there are risks that need to be weighed as part of the equation, but the potential is huge.
The term “cloud” has been used for quite a while in the networking world. It is easy to contemplate: You have your own network at your office or home, and you connect to the internet (these days) to get to other computers. While you have a pretty good idea of what comprises your own network (a router, perhaps a switch, maybe a firewall, some wires, some antennas), once you connect to the internet, you have no idea what makes it up, and you have no idea how it gets to the other systems, but it does. There is no guarantee that each data element transmitted takes the same route to the recipient, and in any event, there is no need to know, as long as the data eventually get there. It is as if you connected to a cloud. Hence the name.
We are still not done. Cloud Computing is really something that affects the provider of applications, as noted above, not the user of applications. With Cloud Computing you still have to think about things like servers, data storage, network addresses, inter-process communications, and a host of things application providers have to think about.
At the level above Cloud Computing, we get Software as a Service, or SaaS. These are applications you access from your computer or device via the Internet, and which are not running on your own computing infrastructure (on-premise, hosted, or Cloud), and for which you usually pay a fee to use. Depending on the application, this removes most or all of the thought of computing infrastructure from the equation. You go to a web site, sign in, and you are up and running. SaaS can mean any application you can access via the Internet using a web browser, such as Yahoo or Google email, or blog hosting companies such as Blogger and WordPress.com. Generally, however, SaaS refers to business applications, specifically CRM or ERP applications.
The “300 lb. Gorilla” in the SaaS world is Salesforce.com, which is a CRM application. Up until Salesforce.com, in order to have an Enterprise CRM application, you needed to install Big Iron, and lots of infrastructure. In addition, since CRM, especially the Sales Force Automation (SFA) component, has users that are mobile and are not sitting in the office, “traditional” CRM had to have some serious technology to accommodate remote access and remote users. Salesforce.com came along and created their application that runs from the Internet, requiring no infrastructure investment to use. Since it is run from a browser, it can be run anywhere you can get an Internet connection. The timing was almost perfect, since Internet connectivity got more ubiquitous, faster, and cheaper, making a web application the perfect choice for CRM.
Instead of paying the usual huge up-front license fee, and then paying 15-22% per year for software maintenance, SaaS applications are pay as you go. The usual arrangement is X dollars per month per user. This does three things: one, it smooths out the cost of the application to be pretty much level over its period of use; two, it moves the entire cost of the software out of Capital and into Operating Expenses, which is a more attractive accounting treatment for some companies; and three, it makes it easier to scale the usage up or down without buying or forfeiting costly licenses. These can all be very attractive reasons to go SaaS for some companies.
From an IT management point of view, SaaS removes a big bunch of headaches. When you run a SaaS application, you no longer have to worry about the infrastructure that runs it. It is all the vendor’s problem now. You have three operational concerns when running SaaS applicatons. The first is that you need to be connected to it to run it, so you need reliable, correctly-sized Internet connectivity. The second is that you may need to have it interface to other applications you run and to printers and hardware on-site, so there is work and maintenance there. The third is you need to know the administration protocols for running the application, such as data recovery, user maintenance, etc.
SaaS removes so much IT infrastructure that you can usually start using it without the involvement of IT at all (this, however, is not recommended!). A departmental sales organization that is part of a larger company can easily sign up for Salesforce.com and get up and running that day, with zero involvement from IT. Anyone who has a Mac or PC can sign up for any of the SaaS data backup services (like JungleDisk, for example) that back up your data to the cloud. You can get a gmail or yahoo email account and run it from the web browser.
There are caveats to SaaS and Cloud computing. The most often mentioned one to me is data security — your operational data is located on servers that are not your own, and therefore is seemingly more vulnerable to being breached. This is a valid concern, of course, but the issue needs to be viewed in context. Your, say, financial data that sits in your General Ledger program is sitting on servers in your data center. Physically, that is one place it exists. It is seemingly secure. However, it also exists, potentially, on paper reports that sit in in-boxes, or in briefcases, or in the trash. And it can exist as Adobe PDF files that get emailed out into the open Internet. And it can be accessed by using any number of user IDs of people who left the company. Or it can be accessed by your “computer guy.” Or the backup tapes can be lost or stolen. Or, the server it sits on has no backup, and it fails. For most companies, the security standards of a typical reputable SaaS vendor are far better than the ones in their data center. So, while this is a valid concern, in context, it is only one of several factors to consider when reviewing SaaS vendors and applications. It is not a one-line deal-killer for SaaS.
Availability is an issue. SaaS applications are reached over the Internet, so your Internet connection must be reliable. However, this also allows you to access your application from anywhere you can get an Internet connection, so you trade off a bit of risk on the Internet connectivity side with a much greater capability from an access side.
You don’t hear this much, but performance is an issue with SaaS applications. Running an application from a browser is often times slower than running a native application. When running SaaS, there is a natural data delay just because you are traversing the Internet. This can be mitigated by programming wizardry on the part of the SaaS vendor, but it is hard to overcome network latencies that can be 50-100 times longer than the user experiences in-house. That matters in some applications, not so much in others.
Overall, both Cloud Computing and Software as a Service are definitely “ready for primetime,” and while they don’t make sense in all applications, anyone doing anything in enterprise computing must consider Cloud and SaaS in their deliberations. The technology that makes it work is only getting better and cheaper, and the reasons for going in this direction are very compelling.
A year ago today I decided to get a Mac to see if I could do my job with one without resorting back to Windows. I received the computer on March 5, 2008. I am writing this post on the MacBook Pro I bought. Despite being a year old, you can’t tell – it is as cool now as it was then, and it works great. I use it every day. I cart it around everywhere. The battery life is long. There is no evidence of wear. It is worth the money paid for it. I would buy the same computer for the same money – only now I would get to buy a better Mac for the same money.
Some interesting changes happened along the way.
One is that I always used a mouse with all Windows-based computers. I never liked trackpads or “eraser-head” mice. I used a mouse with the MacBook when I first got it, too. But, I found myself more and more using the trackpad on the Mac. The multi-touch aspect is wonderful, and the pad is very accurate. I don’t use or carry a mouse anymore. My only wish is that this Mac had the new multi-touch trackpad the new MacBook Pros have, but the one I have works great.
The other change is that I left the Windows control-freak world behind. Not just the operating system, but the whole Active Directory/Exchange/Microsoft-centric world that goes along with it. A security update last year broke the Mac’s printing capability using Active Directory-oriented printers. It didn’t break printing, but just printing via Microsoft Windows Server-based queues. I was upset initially, but then I realized: who cares? An Active Directory-based scheme attempts to control access to printers based on user profiles, group memberships, and such. That works fine if the printer is attached directly to the server, but no servers are directly attached anymore, not in real companies. They are all attached directly to the network just like the computers are. And, since they are already on the network, you can just send the print-job directly to them without the middleman, and everything turns out. You could argue that printing directly bypasses Windows security, but again, so what? If you can bypass security just by printing directly to an IP addressed printer, there is no security anyway. Why go on with the charade? (By the way, the way to handle this problem, if it really is one, is with network security, VLANs, and other methods).
A really great change was that I stopped thinking about what is going to happen when I suspend the computer by closing the screen or just suspending it. It suspends. That is what it does, and it comes back when you restart it. It does not suspend for a while, then give up. Suspend in the Mac world does not mean “suspense,” in which you are on pins and needles wondering if you’ll get it back, or lose it all and have to reboot.
The Mac was a great choice. It is a great machine. I’m glad I did it.
I tend not to watch too many videos on line, and I very rarely watch videos of any length. However, Charlie Rose’s interview with Marc Andreessen that aired last night was wonderful, and well worth the bandwidth. Andreessen discusses social media, internet banking, news media, the economy and investing. Well done.
There is currently a fad on Facebook in which you list twenty-five random facts about yourself on your Facebook profile. Then, you “tag” twenty-five people to do the same. The idea is to let your Facebook friends know a little more about you. Some people choose to list some pretty personal stuff — it’s almost like they are playing “Truth or Dare.” If you have read my blog you know that I am pretty down on having personal information too available on the internet, because while your intention may be to share yourself with your friends, you are in fact sharing yourself with everyone, good or bad. The Internet’s spotlight can be pretty harsh.
However, a friend of mine tagged me on his Facebook profile, and so I decided to participate, but in a slightly different way.
I have recently moved from being a highly regarded IT Executive heading up the IT organization for an art publisher to being a highly regarded IT and CRM consultant who helps clients use their IT well. As a result, my daily activities now include business development and “Personal Branding,” which is a trendy way to say “self-promotion.” Self-promotion usually has a negative connotation, especially when used in the phrase “he (or she) is a genius at self-promotion.” But Personal Branding, that’s different. Personal Branding is the way to promote “Product: You!“
Now, if you read that and felt just a touch queasy, you can see how it is. It is hard to strut out like Mohammad Ali and yell “I am the Greatest!” even if you are. Ali could get away with it because he was the greatest, but it is extremely rare to have extreme self-confidence and extreme competence. People usually have one or the other. But if you are competent, especially in IT, in which competence means everything is working great and no one has a reason to hate you, you have to get over some of that natural modesty and get your name known. Doing that is Personal Branding.
So, in the interest of honoring my friend’s “tag” for 25 random facts, and Personal Branding, I am posting:
25 Random Facts About Me, Programming Language Edition.
All of these programming languages I can say that I know. I have produced production code in most of them, meaning that the programs were used and relied on by my clients/customers to run some aspect of their business. Here they are, in general chronological sequence of my use.
- BASIC. This is the first language of pretty much all pre-1990 programmers. I wrote my first program in BASIC when I was nine years old, and it was something like:
FOR X = 1 to 10
PRINT “HELLO!”
NEXT X
I also wrote a whole budget application in 1983 on a TRS-80 computer in BASIC. - Business BASIC / IRIS BASIC. In my first official job as a programmer, I edited and enhanced existing code for a Data General machine for an accounting department in Hollywood.
- Turbo Pascal. I self-taught myself this language from the Borland Turbo-Pascal manual, which specifically said “This manual is not to be used as a guide to learning Pascal.” Well, I did anyway. I wrote a program to play craps, and tested betting theories. Found out what everyone usually finds out when they play craps: eventually, you lose everything.
- Pascal. I took my learnings from Turbo-Pascal and was awestruck by what real Pascal could do. Object code? Linking? UNION structures? Wow! The Pascal I used was for programs running on a DEC PDP/11.
- Batch for MS/DOS. Yes, this is a language. I did a lot of operating system-level upgrades, updates, and selective program calls by a judicious use of AUTOEXEC.BAT and branching batch files.
- DataFlex. This was my bread and butter language and environment for several years, from 1987 to 1993. I built accounting packages (General Ledger, Accounts Payable, etc.), work order programs, and convenience store management systems using this language. Some were still in use as recently as 2004.
- Bourne Shell. Xenix was my first “flavor” of UNIX. Xenix was a Microsoft product and was actually pretty good. Shell scripts were the glue that pulled our application together – DataFlex, some C programs, and uucp communications scripts.
- C Shell. Similar to Bourne Shell, but we did not use this in production.
- C. C was my aspirational language. Despite my expertise in DataFlex, Pascal, and shell scripting, I did not feel complete until I finally “groked” C. Pointers were my downfall, until one day they just clicked – it truly was an epiphany – and then there was no holding me back. I wrote a lot of supporting code and utilities in C – wrote a pretty cool formatted-text based reporting tool that would print reports on the screen or to the printer very nicely. The screen mode would freeze headers, footers, and whatever column you wanted while scrolling data rows, and the printer mode would properly print the headers and footers and paginate correctly. Also, I ported the “curses” UNIX screen library to MS-DOS using C, so I could write code once and have it compile for both DOS and UNIX/Xenix. Wrote a few TSRs (Terminate and Stay Resident… does that bring back memories to you old DOS users?)
- REXX. I love REXX. REXX is an IBM language that was their official scripting language. It is amazingly powerful for parsing text files and doing conditional execution. I did a lot of communications work using servers running OS/2 and a communications package called XcelleNet, and REXX allowed me to write scripts to move data to and from servers and the client’s mainframes, and ensure all systems were running properly. An elegant language.
- Make. Make is not a true language in itself, but it is a very cool tool that acts like a language. What it does is “make” programs. Virtually all applications are made up of a collection of component program parts. Make keeps track of all this, so that if you update a source module somewhere, it knows it, and follows your pre-configured directions to re-build the application, recompiling and relinking all those source modules you updated. It is close to my ideal of making computers do what they are supposed to do. You literally type “make my-program” and it does it.
- 8086 Assembler. This is the baseline, you can’t-get-closer-to-the-machine-without-going-crazy, programming language. And, it was 8086 code, which is not easy, because of the Segment:Offset memory addressing scheme the Intel used to allow a 16 bit computer to address 640 Kilobytes of memory. I used it to write the resident part of the TSR I mentioned earlier, and some key pieces of some communications device drivers I put together for reading cash register data.
- C++. This is the object-oriented version of C. It does not force Object Orientation — you can actually write pure C code and compile it with a C++ compiler — but, it had what was needed to create real OO programs. I put a lot of this rigor already into my C programs, but C++ made it easier.
- awk. This is a quirky little program that processes and parses text files. Like REXX, you can do a lot of things with it, and I used it to do some deep file manipulation on the UNIX side of things.
- SQL. Structured Query Language. This is the core language for the Oracle database, IBM’s DB2 database, MySQL, Microsoft SQL Server. Each has their own extensions, but you always get code that looks like “SELECT X from TABLE-Y WHERE X > 100″.
- Actor. This is an object oriented language similar to (maybe even based on) Smalltalk. I got it to learn object oriented programming. It was slow as a dog.
- Visual Basic (VB). This is the variant of BASIC that was the standard for non-C Windows programming and scripting. Not only did Microsoft push it, but a lot of business applications, such as Clarify, used it as well. I always felt that VB was more like Pascal than BASIC.
- Borland Delphi. This is a great language, which is essentially Object Oriented Pascal geared for programming for Microsoft Windows. I did not write enough production code in Delphi – My colleagues shied away from it as Borland seems to always have been on the verge of going out of business, which supposedly would have killed Delphi. Well, Delphi is still alive and well.
- Siebel Meta Language. In 1994, I was dispatched to Siebel’s headquarters to find out what was going on. Before Siebel had its development environment, before it even had a product, it had a configuration language that told the application what data was needed, and how the application should run. This was the Meta Language. I wrote a REXX program to parse the core configuration files, which ended up being the source of the first documentation Siebel had.
- PL/SQL. This is Oracle’s variant of SQL.
- perl. This little gem essentially took over from Bourne scripts and the whole library of UNIX utility programs, like awk and sed. It takes all of these, and puts them together into one language, which ends up being almost, but not quite, kludgy. It even took some of my favorite concepts from REXX. I wrote a few amazing text-parsing and communications programs using perl. And, of course, a lot of web back-end processing.
- HTML. This is not a programming language, really, but a language used to tell a web server how to display content.
- JavaScript. This is not Java, but looks kind of like it. Used for web pages. Javascript, HTML, ActiveX, and the rest of the web development toolset annoyed me when they came on the scene, because of the lack of standardization of web servers and browsers. As a result, you had to write your pages with a lot of “if/then” type statements that generated code based on the brower that the user was running. That is still true today: too many sites are written only for Microsoft’s Internet Explorer browser, and do not work correctly when being run using Firefox or Safari, or other browsers, or by users accessing them from Apple or Linux computers. The problem still exists thirteen years later, but Cascading Style Sheets and other advancements have made it less of a problem. But it is still a problem. The issue I have is that developers should focus on what problems their applications are addressing and not spend countless cycles debugging differences in how the application looks from browser to browser.
- Java. This is a language I can respect. Object oriented, not as low-level as C++, interpretted as opposed to pre-compiled, and portable across operating systems. Written for use on the web. Standard, since it is defined by one company, Sun Microsystems.
- Ruby. I am learning Ruby. Ruby on Rails is one of many ways to build web 2.0 applications. I like it because it is clean, fast, and well thought-out.
This Random Facts listing has been an interesting exercise – when I started listing out the languages, I did not really know if I could come up with twenty-five, but there you are, and the list is not complete. My work with these languages form the core of my knowledge regarding what Information Technology can and can’t do. No matter which language is chosen, they all eventually compile down to the ones and zeros, the ons and offs, that dictate what the computer systems, storage systems, routers, switches, smart phones, iPods, and other devices do. Each language has its strengths and weaknesses, its proper and improper applications, and each has its following. There is no single tool that does everything – not even close. You can have competing tools to do similar things, but not one tool that does it all. In fact, you can have applications competing with development tools, such as spreadsheet programs being used to import or export financial data or contact lists. And now, especially, you can choose a lot of off-the-shelf (or off-the-internet) applications that do what you need without resorting to coding it yourself.
The diversity of the languages and applications I have used in my career have taught me to be very fluid about which technology to use to address various business or programming challenges. It has liberated me from forcing my view of problems through the lens of a given programming language, platform, or application. It has broadened my view to know that there are a lot of ways technically to address these challenges, not just one or two, and that many times these issues can be resolved without resorting to some new panacea technology. It has taught me that what really matters is what you are trying to do with the technology, not the technology itself. Technology does not solve problems. Technology helps you to solve problems. There is a big difference.
There is a recent article in the Computer Business Review in which Lawson CEO Harry Debes both slams the Sofware as a Service model, and predicts the demise of Salesforce.com. Salesforce.com is the industry leader in Software as a Service (SaaS).
There are two primary methods of running business applications: “traditional,” for lack of a better term, and “Software as a Service,” or “SaaS.”
The traditional model is that you have the software, but also need to have the infrastructure and personnel to run it. Oracle, SAP, PeopleSoft, JD Edwards, Siebel, etc., are all software systems you run on your own equipment and network. They require two types of people to run the applications: Functional and Technical. The functional people understand the application and how it works (like, how to post the A/P to the General Ledger, how to set up charts of accounts, etc.). The technical people understand how to keep the application running, reliable, and safe. They tune the databases, do backups, configure servers, upgrade equipment, etc.)
In the traditional model, you have the large capital cost to set up the data center, buy the equipment, and pay for the software license, and then you have ongoing costs of personnel, hardware and software maintenance, data center refreshes every three to five years, and 18-22% of retail price (not what you paid) per year application software maintenance. You can mitigate the data center cost somewhat by having the servers hosted at a company like Rackspace.
Then, there is the SaaS model, a method popularized and promoted by Salesforce.com. In this model, the software runs in the vendor’s data centers. Database tuning, backups, server and software maintenance, technical support, are all borne by the software provider. You just connect to it via the Internet, and run it. You pay a monthly or yearly fee.
In other words, you sign up, boot up your laptop, connect to the Internet, and log in, and you are running the software. No data center. No servers. No backups. While there are challenges to this model, which I will not get into in this post, this model is generally far superior to the traditional model.
Why is SaaS generally superior to traditional? The one primary reason is that SaaS eliminates a company’s need for a sophisticated data center and all the IT personnel, procedures, and costs associated with it. This means that that company can instead focus resources on their core business: Marketing, sales, production, delivery, and customer service.
I visited Hewlett-Packard’s Executive Briefing Center last year in Cupertino, California. It was beautiful! They had a state-of-the-art data center, complete with water-cooled racking and a dedicated data center administrator. All the latest “cool” servers and data storage devices were there. It was all hooked up to HP’s support teams, so that if you pulled the plug on a server, the HP support personnel would call the center to see what was wrong, and try to correct the issue. So, here I was, the VP of IT for a company that publishes art, looking at this. And even though I am a technologist and love this stuff, I could not help thinking: why should my company have to buy, install, maintain, and run this stuff? What does this have to do with art publishing? Why should I pay for an expensive dedicated data center administration staff, a staff who has the specialized knowledge necessary to keep this beautiful Cadillac running but who has zero knowledge of our business? I came out of the meeting with two conclusions: one, I want my applications to run on HP equipment, and two, I don’t want to run the equipment.
SaaS lets you do that. You run the application. You do not run the servers.
So, what is Harry Debes’ problem with SaaS? Well, for one thing, he is in the traditional software business. And, two, he is paying a ton of money for Salesforce.com when he knows he can run similar software in his data center. But the difference between Harry and you and me is, he is in the business of software and data centers and all that they entail, and you and I aren’t. If I am paying $1 Million per year to Salesforce.com, it means I am not paying $1.5 Million per year in depreciation and ongoing maintenance costs, and I am not trying to keep a very talented IT staff happy in a business that has nothing to do with IT.
So, why, to Debes’ point, aren’t more companies doing Software as a Service? The answer is: It is hard. Hard for the vendor, not the customer. The vendor needs to absolutely keep things running, because a second of unavailability is a second of unavailability for every single customer they have. They need to keep their customers’ data safe, and unique to each customer. It will not do if the Bide-a-Wee Biscuit Company’s customer information is mixed up with Joe’s Auto Parts’ customer list. The vendor has to abide by the strictest security requirements, because a data or access breach, again, affects all customers. The good news about this is that all this rigor goes way beyond what any individual software customer could do, save for companies in the $Billions of revenue range, and so the data, when entrusted to a company that gets it right (like Salesforce.com) is more secure than it would be in your own data center.
SaaS vendors distribute the cost of infrastructure, security, and maintenance across all customers. The customers, therefore, get this benefit at a cost far less than what they could do themselves. And, of course, SaaS customers just run the software, allowing them to focus on their work, not worry about keeping the system running.
The bottom line is that Cloud Computing and Software as a Service are here to stay. Salesforce.com isn’t going away. As computing platforms and software become more and more sophisticated, it becomes less and less valuable for companies to invest in their own IT infrastructure, and more and more desirable to let the gear-heads run the infrastructure completely out of sight. Even if the absolute cost is about the same, which it is not, SaaS still makes sense, because IT becomes less of a distraction to the business. That is very valuable.
