Monday, November 10, 2014

How cloud and SaaS can enhance I.T. agility

The advantages of the cloud and specifically Software as a Service (SaaS) are very well known. Everybody’s talking about them all over the net, at forums and in the pre-sales calls of the cloud companies. People are talking about financial benefits that SaaS brings in their P&L, several cost saving factors, security, portability and access etc. One more advantage that is less frequently discussed is this of the agility that SaaS brings in the entire I.T. function, structure and governance. In this post I’d like to focus on this exact point, thinking that maybe it is usually understated.
We must admit right from the start that agility is not a critical issue for some buyers, mainly the smaller businesses that adopt SaaS; for them portability, web access, cost savings may be more important; but what about the bigger fish in the tank? SaaS enthusiasts claim that the cloud is suitable for bigger installations, too. For these installations, qualities like agility, the ability to quickly adapt to new business requests, the ability to adopt new software solutions fast etc. can be very important. So, how is SaaS helping them achieve new, higher levels of performance when it comes down to these metrics?
I will not enumerate the metrics one by one, here. There is a large number of those, after all, and the reader could easily argue that this or that is of low importance and therefore not worth the conversation. Instead, I select to present some qualities of SaaS that make I.T.  more agile and adaptable. Let’s have a look:
  • The easiness of on-boarding a web-based SaaS service makes it even more attractive than the pure functionality the service offers, in the sense that when there’s a pressing issue to be resolved, it’s quite easy to register and start working in a matter of minutes or hours (at this point, the discussion opens for the Rogue I.T.). Of course, that is not to say that I.T. issues must be dealt with in such hasty manner. Due diligence must be executed, software selection process is always there etc. But there can be strategies that enforce a quick solution “right then and there”, while the final solution to the problem is still being investigated or planned. Such quick solutions were not possible in the “old days” when even the smaller piece of software had to be purchased, installed, probably customized and – at the end of the day – maintained as a piece of significant investment, that it was. Hence, the agility; the possibility of quickly solving a problem with a hand pistol while looking into the market for a larger “gun”.
  • In the same spirit as above, we can’t help commenting on the migration process. Migrating your old data to the new web-based service is usually a painless (or less painful, if you prefer!) process than it used to be. It is now clear to the SaaS software vendors that good functionality is not the only quality required to keep ahead of the competition. Fast and painless on-boarding is also a requirement and around this requirement, data migration is a central issue to look at. That’s why some services offer “plug and play, do-it-yourself” data upload mechanisms. And that’s also why the data migration issue is being observed even more closely by some specialized companies in the field.
  • When the time comes to abandon the SaaS service, it is usually equally easy to download whatever data you have inputted or calculated in that service. The form of the downloaded data is not in some proprietary format that I.T. Dept. or the next vendor can’t process. Usually, XML, txt or EXCEL file formats are what is being used. How does this enhance agility? Because migrating onto the new software is no longer a long and painful process nor does it require manual file processing, cleansing or conversion to another readable format. Therefore I.T. managers need to budget less for extra time and resources when they’re asked to estimate the effort of transition.
  • The easiness of adopting a new SaaS service is in direct proportion to the costs involved. We have heard time and time again that SaaS pricing models and Total Cost of Ownership (TCO) makes it easy to adopt. That is true when a new installation is designed. But it is also true when an existing infrastructure needs to be refreshed or updated or enhanced. The total lifecycle of a piece of software can be significantly smaller with SaaS, instead of waiting years to depreciate the investment that the company has made when it purchased a on-premise piece of software. Software is no longer an investment, rather it is a monthly expense and as such the commitment that the organization makes to it is much smaller.
We’ve been talking about “degrees of freedom” (a.k.a. agility) that SaaS brings into the organization, when it comes to internal scheduling, budgeting and costing. But there are also external factors that assist the continuous effort of the organization for I.T. flexibility and fast response:
  • Exactly because software vendors know that customer retention is a much bigger issue than it was for the on-premise software market, they are pushed to respond and act better and resolve issues and bugs faster than before. Churn rates are significantly higher to the Service business than in the License business. Vendors know that customers can move more freely in the SaaS market and thus they (the vendors) need to increase the level of service they provide.
  • Software updates are released must faster and they bring faster resolution of bugs but also significant new functionality, each month or trimester. The old days when, for example, a banking application had a new release every eighteen months are (almost!) over. Regardless of whether a new component was requested by the community or paid for in a Customer Support ticket as a custom enhancement, users see their issues resolved faster and better than before.
  • Role-based authorizations are surely expected in a SaaS application, while in traditional software this may not be the case. Features like that enhance agility for the daily business as system administrators can now configure larger parts of the data entered and the user interface than before. A typical example is that of a central Customer Database where the Accounts Receivable officer should be able to see and change different information than the CRM user. For traditional on-premise software such functionality may not be a standard feature and when it comes down to role-based distinctions perhaps programmer-driven customization is required, which means program changes, release planning, testing etc.

Software as a Service turns software into a commodity rather than a product and as such it is more easily consumed (but also “recycled”!) when it’s no longer needed. In a fast changing world, I.T. is there to assist those agile business processes and models. Therefore, I.T. should be agile, too, in itself. Software – which is only a part of I.T. – must follow this general rule and SaaS makes it more possible than ever before.

Wednesday, May 14, 2014

IT chargeback/showback and SaaS

In this post I’d like to approach the issue of whether and how Software as a Service (delivered of course through cloud technology – don’t let them tell you otherwise!) can assist an organization implement an IT chargeback / showback strategy. For those that haven’t heard the terms before, IT chargeback is the methodology or strategy that applies/allocates Information Technology costs on the business unit that is actually using an I.T. resource (be it software, hardware, professional IT services etc.) Chargeback can go as far as internal expense management where the business unit actually experiences cash outflow (or budget consumption) in order to implement an IT function. In other cases, there is no actual cash movement; all calculations are done on reporting level only in order to have a clear image of the costs incurred by each business unit to the organization, for planning and budgeting purposes. This is called “IT showback” where numbers are “shown” but are not actually “charged”.
But how can Software as a Service assist the organization implement IT chargeback/showback strategies? The answer is “in a number of ways”.
First of all, the very nature of SaaS is “pay as you go”, which means that SaaS costs increase as long as your needs grow. The “growing of needs” can be measured in many ways, depending on largely on the nature of the SaaS product under question and can be tracked down to who has that new requirement. A few examples are the following:
  • Sales department is on-boarding new salespersons so it needs new seats for the CRM SaaS application that is using. Seats are the usual metric for business applications.
  • Marketing department needs additional disk space for new digital material is has generated. Storage figures are the usual metric for large objects storage.
  • Management needs new reports and dashboards to track the monthly business. Such needs are measured in hours devoted to Customer Support Requests by the vendor.
All of the above usually originate from a specific source (business unit) to cover the new needs of that unit. Therefore, the relevant cost can be easily attributed to the specific business unit (or “cost center”, to borrow the accounting term). Now, because the costs are clearly defined in any SaaS deal, we come to the conclusion that cost center accounting of this nature is facilitated by the “as-a-Service” costing model.
Another aspect that we need to factor in is the recurring costs that XaaS does not have. I’m referring to the yearly maintenance cost of a perpetual in-premise license. After initial installation, the customer is requested to pay a standard yearly fee for the maintenance and upgrade tasks of the software installed. This is usually a fixed number and does not follow the growth or shrinking of each business unit that uses the software. For example, if new users are hired in Sales Dept. then the yearly maintenance fee is not increased, if the license scheme initially offered is a “perpetual license” one (which is usually the case). So, even if there is an initial breakdown of such costs, done based on some metric (e.g. number of users per department) this breakdown may soon become obsolete.
One more point to make is that of additional works after the initiation of the XaaS project. The XaaS monthly fee does not include any additional works that the customer may ask. Therefore, whenever a business unit is asking for something new or additional (new functionality, additional disk space etc.) the new cost can be easily attributed to that specific cost center, since SaaS is not an “all-inclusive” deal. On the flipside, a yearly maintenance fee of an in-premise model may include some portion of such additional works. The vendor may for example offer a number of free working hours to resolve issues or implement additional requirements, per year. In these cases, the cost has already been prepaid and it is not easy to attribute this or that work to the corresponding business unit (since there is no actual invoice to forward).
The above show that the “as-a-Service” costing model (and the technology that comes with it – in my personal opinion a XaaS deal cannot work efficiently with in-premise software and hardware, although we have seen such deals) facilitate the IT chargeback/showback strategy of the organization. Of course, that is not to say that this fact should be a decisive factor when the “cloud vs in premise” question pops up; nor that IT chargeback cannot be implemented with traditional costing models. The point is that in this area, too, “cloud makes it easier”.

Friday, April 18, 2014

Comparison of Private and Public clouds

So, you’ve decided to move some of your apps to the cloud. The next question that you need to answer is “public or private?”. Each direction has its pros and cons and you’d better look at all possible Performance Indicators before you decide where to lean. Every problem has its solution and every solution has its cost. The term “cost” is usually translated in monetary terms but this is not the whole truth. The “cost” can be compromises that you are willing (or not) to make in terms of security, availability, scalability etc. The “cost” can also be the downside of what today seems inexpensive (for example, the cost of a SaaS application that is quite low to begin with, but requires extensive customization on your existing software to integrate).

In the following table, I have compiled a list of issues that one should consider or address when having reached the crossroads “public vs private”. You see, the cloud has reshaped Information Technology but the very basics of the I.T. realm have not lost their significance: deployment, cost of ownership, knowledge capital costs etc. are some of the issues that have been troubling CIOs across the globe and will surely continue to do so for the foreseeable future. Let’s have a look at them:

Private Cloud
Public Cloud
Security can be designed and implemented according to your needs and corporate policy. Also, it can be revisited, anytime the business requirements change. Obviously, you are free to select the level of security and find the balance between that level and the cost of implementation and maintenance.
You have to follow the provider’s security guidelines. Customization in that area is not very probable or – if it is – it will come for a high price.
Sure, security is an issue that you will examine before you make your vendor selection; but things can get tricky when you find the SaaS application that best suit your needs, but the security level does not live up to your expectations.
Availability is entirely up to you. You can set very high standards but you are the only one who can make sure that these specifications are met. You have to deploy your own resources and controlling mechanisms and you have to periodically revisit the issue and probably budget for new costs.
The positive side is that you don’t have to rely on the “open internet” connection speeds. If you choose to build your private cloud on the backbone of a guaranteed internet service (such as VPN) you can stay relaxed about the throughput of your connected points.
It is not you that is troubled with that headache. As long as you have set your standards beforehand and your vendor can live up to these expectations (through a signed SLA, of course), you can rest assured that the availability will be what you expect.
Of course, high availability comes for a price and you should definitely set the roof to your expectations. The fact that the headache is not yours to handle does not mean that you should go ahead and ask more than you actually need.
You have better visibility over the various cloud components, such as computation resources, storage, network devices and the corresponding bottlenecks.
Your vendor is the one that handles and nurtures, so to speak, the entire infrastructure. They may be extra careful and professional in what they do but they can’t be as time-sensitive as you, running your own business. If, for example, you know that you have increased computation requirements from 19:00 to 23:00, you can plan for it better and more accurately, if you run your private cloud. And if worse comes to worse you are free to select services that will be downgraded in favor of the more important ones.
Because you provide service to only one set of users, the actions for orchestration and planning of the resources can be faster since complexity is lower and bottlenecks are more predictable.
A good cloud provider can perform just as well. They may also have deployed automated load balancing and other resource-planning systems. But it is a question of how fast can they respond and how accurate the can be in their “fine tunings”
Update process
The update process, pushing new releases or bug fixes to your users is entirely in your hands to plan.
Testing of new releases can be planned and executed according to your standards and take as much time as you need to ensure good results.
Also, the implementation of a separate test environment is probably a very easy thing to do and maintain.
In many cases, upgrades are pushed from the vendor with just a small notice (if any).
Also, test environments are not available or, if they are, the test planning cannot fit to your exact schedule. If every customer of that public cloud service was asked when it would be the best time for the test to start and end, it would most probably never be executed.
Finally, it is possible that separate test environments are available by the vendor, for an additional fee.
As in the update and testing process, customization is yours to decide, plan and execute.
In fact, if your governance includes a great deal of “customization” (instead of deploying “best of breed” or “off-the-shelf” products), a private cloud may be your only option.
Customization may be impossible, that’s the worst case scenario.
Customization may be possible but it will surely be implemented by vendor staff, which automatically sets the issue of “additional fees” on the table. Even if your I.T. staff was as capable as the vendor’s, the cost of customization in a public service would be so much more expensive as to cover the vendor’s profit margin, per work hour.
If your enterprise operates under a strict legal framework, then implications in terms of security, availability or other issues may be such that cannot be easily met by the average public provider. Then, the implementation of a private cloud may be the only way forward.
Assuming that your operation framework entails several strict guidelines, you may have a hard time finding a public provider that abides by these guidelines. If you find them, the additional “level of service” (which is translated into additional technical clauses in your SLA) may significantly increase start-up and/or recurring costs.
Take banks for example: how many of them operate in a public cloud?
On the other hand, for SMEs of typical nature (such as service providers, stock movers, retailers etc.) there is no question of “governance”. I.T. function may be totally absent in such small businesses and therefore the Public Cloud may be their best option for deploying almost-zero-headache top-of-the-line applications.


You may get the feeling that Private Cloud wins over Public in all of the above performance indicators. This is a generalization that is not at all true. As always, you have to carefully put down your requirements (both business and technical ones) and see how far you need to go. Then put these requirements on the balance with the budgeted costs. Finally, make your market research and find out if there are public services able to meet your standards and a cost that you can take today (and also with some buffer for the near future). Then, the answer to the “private or public” dilemma will start to be made clear…