Consider the Source

Cloud and the Global Sourcing Market: Follow the Discussion at the NASSCOM India Leadership Forum

by Stanton Jones, Analyst - Emerging Technology, ISG

One of the key questions many traditional information technology (IT) service providers are asking themselves is: How will cloud computing affect my outsourcing business?

These providers are wondering whether cloud will take share from their existing managed services business. Or, will it create even more opportunities? Time will tell, but it’s clear that enterprise buyers want cloud as a part of their IT service delivery model, and they're starting to demand it from their providers.

Although it will take some time to fully understand the impact of cloud on the global sourcing market, some emerging trends in both the sourcing market and the cloud market provide an interesting glimpse into the future. First, let’s take a look at three of the four key, long-term sourcing structure trends discussed by ISG during the most recent 4Q11 Global TPI Index:

• A shift from longevity to disposability in outsourcing contracts
• A shift from pricing bands to utility pricing
• The new global shape the service provider community is taking 

What’s interesting here is matching up what’s happening in the broader outsourcing market to what enterprise clients are asking for in cloud technology. Here are a few of the recurring themes we’re hearing from chief information officers and business unit leaders when the discussion turns to cloud:

• We need to move faster and to be more flexible to meet business demand
• We want to pay for what we use and want transparency into our costs
• Who has the capabilities to help us meet these needs on a global scale?

Clearly, there appears to be a correlation between how the outsourcing market is changing and what enterprise customers want. 

To what degree is cloud responsible for driving this change? This is one of the key questions that we’ll be exploring at this year’s NASSCOM India Leadership Forum, February 14 – 16 in Mumbai, India. I’m thrilled to have the opportunity to moderate a panel discussion about this very subject on Wednesday, February 15. If you’re on Twitter, I encourage you to follow along using the official hashtag for NASSCOM ILF: #nasscom_ilf.

Look for a follow-up post after NASSCOM where I’ll summarize some of the key points of view around this exciting topic.

SAP Acquires SuccessFactors: Forecast Calls for More Clouds

by Michele Loux and Maribeth Sivak, Senior Advisors - CHRO Services, TPI

The shift toward delivery of Human Resources (HR) applications via Software as a Service (SaaS) in the Cloud continues with SAP AG announcing its planned $3.4 billion acquisition of SuccessFactors, a talent management software provider.

The fact that SAP agreed to pay a 52% premium for SuccessFactors indicates both the urgency it felt to increase its Cloud and SaaS credibility and its lag in internal product development. SAP expects to complete the acquisition in the first quarter of next year after which SuccessFactors will remain an independent company operating under the name “SuccessFactors, an SAP company.”

What does this acquisition bring to these organizations?

In a recent call, Bill McDermott, SAP’s Co-CEO, said “the combination of SuccessFactors and SAP will create a Cloud powerhouse.” SAP plans to use its scale to boost SuccessFactors’ revenue, which was $205.9 million in 2010 with more than 3,500 customers in 168 countries.

Lars Dalgaard, CEO of SuccessFactors, said “the deal would accelerate SuccessFactors' roadmap by 10 years.”

The TPI point of view

SuccessFactors will continue to operate separately, causing no immediate impact to its talent management clients. A number of HRO providers use SAP and SuccessFactors to deliver services. We do not expect this acquisition will impact the providers’ ability to leverage SAP and SuccessFactors to deliver service to their clients, even as we anticipate these underlying systems will continue to evolve and improve.  

This acquisition is a validation of the Cloud’s bearing on Human Capital Management solutions. When it acquired SuccessFactors, SAP acquired Cloud technical expertise and infrastructure, giving it a foothold in the growing market for Cloud services. Both companies should benefit from access to an expanded customer base.

The demands on HR technology are changing rapidly with a particular push for mobile access, social collaboration and business-driven analytics. Once they sort out their future technology path, SAP and SuccessFactors together should have the products and the experience in delivering Cloud, mobile, social and analytics applications to provide innovative HR solutions in the future. Whether they can do this quickly enough to compete effectively with Workday remains to be seen.

We expect to see more Cloud acquisitions in the future. These acquisitions should spur organizations to reassess their human resource technology roadmaps.

Cloud Security: Peeling the Onion

By Steve Follin, Director, TPI Cloud Services

Discussions around cloud security tend to be framed in terms of lonely ships sailing into uncharted waters: “You don’t know what you’re getting into,” we’re routinely warned.

Actually, we do.

The fact is, the fundamental security challenges confronting a company seeking to source IT infrastructure services in the cloud are essentially the same as those faced in traditional outsourcing.  Various potential risks – data center vulnerability, network intrusion, unauthorized system access, data privacy, natural disasters, etc. – must be assessed and addressed to provide an acceptable level of security for data centers, operating systems, storage environments, and networks. 

What’s different in a cloud setting?  It’s that the infrastructure “layers” involved may be more decentralized, are most likely shared with other customers, and have more complex IT operational processes, whereby processing may be moved among the provider’s data centers to load-balance. 

Due diligence therefore comprises focusing on exactly the same traditional security concerns, asking the same “first round” questions about each infrastructure layer, and following up with more questions as complexities emerge. Ultimately, what’s needed to solve the mystery of cloud security is to “peel back the onion” – to systematically evaluate the security of each infrastructure layer, and to then assess additional risks inherent in the provider’s cloud architecture and operational environment. 

Consider, for example, a virtual private cloud (VPC), where some, but not all, infrastructure components are dedicated to each customer.  In other words, CPUs and storage may be dedicated, while server racks and physical network segments are shared.  From a high-level perspective, assessing security may seem daunting as the environment is “new” and complex. But by systematically addressing the security concerns at each layer of the infrastructure “onion,” and then at the overarching cloud level, a viable approach readily emerges.

The first and foremost assessment question for a VPC is: What’s dedicated and what’s shared?  While this has to be understood at a very deep technical level in order to perform a security assessment, providers have this information readily available.  If the provider’s cloud solution has dedicated storage and servers, then the “first round” of due diligence is to use the customer’s “conventional” security criteria to assess the dedicated servers and storage security.  Specifically, the servers’ virtual and operating systems’ security is assessed as it would be in a traditional hosted server environment.

As for public clouds, in a VPC the shared infrastructure components and cloud operating processes create security risks above and beyond those in a traditional hosted server environment.  If server racks are shared, their architecture’s compliance with the customer’s security policies must be evaluated.  If the provider’s processes include moving data between data centers to balance loads, compliance with the client’s data privacy and security requirements must be addressed.

As a client, the key to evaluating cloud security is understanding the cloud implementation details and “peeling back the onion.” This approach leads to a series of tractable security assessments that can be addressed using conventional evaluation processes.  While the issues involved are complex, the complexity can be systematically addressed – layer by layer.

Being Clear on the Virtual Private Cloud

By Steve Follin, Director, TPI Cloud Services

The National Institute of Standards and Technology defines a hybrid cloud as a “composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability.”

That definition raises a key question: what does “bound together” mean? The unsatisfying answer: “It depends.”

An increasingly popular form of hybrid cloud, commonly called a “virtual private” cloud, has certain infrastructure elements, such as servers and storage, dedicated to each customer, while other infrastructure elements are multi-tenant (shared). This architecture addresses customers’ concerns about processing and data storage security, while still maintaining some resource sharing.

The mix of what’s dedicated to one customer versus what’s shared varies across vendors. From a sourcing perspective, it’s therefore imperative as a customer to understand the specific components and processes of a provider’s VPC solution, and whether they address the organization’s requirements for security, data privacy, redundancy, disaster recovery, and service quality.

For many VPC offerings, CPUs and storage are dedicated to each customer. Beyond these basics, however, little can be taken for granted, and customers must understand the technical implementations of how services are delivered.  For example, a solution that utilizes shared network links could be a problem, as the compliance requirements of some organizations preclude the sharing of any network infrastructure.

Pricing of VPC services also varies widely, creating further potential for confusion.  Some vendors offer usage-based models similar to public cloud pricing structures, e.g., charges for CPU utilization and disk storage.  Other pricing structures charge for the servers and storage dedicated to the customer so that, at least on the surface, pricing is similar to that of a traditional hosting environment. The latter approach is still called a “cloud” offering because it’s virtual and has pooled resources, broad network access, and self-service rapid provisioning – characteristics not typically found in a traditional infrastructure environment.

By taking advantage of the economies of scale of a cloud-based infrastructure, but in a way that is more secure than a fully public service, the hybrid/virtual private cloud model offers significant potential benefits. At present, however, the lack of standards and consistency for how vendors deliver and price VPC services makes it imperative for client organizations to have a precise understanding of the solution they are buying, as well as contractual provisions to address key considerations.

Cloud-Washed Contracts: You Could Be at Risk

By Stanton Jones, Vice President & CIO, TPI

As my colleague Bobby Neil and I wrote earlier this year, if you’re looking to buy Software as a Service (SaaS), it takes diligence. It’s important to understand whether you’re buying a true SaaS solution or simply a repackaged, “on-demand” version of the software. The same can be said for Infrastructure as a Service (IaaS). A true IaaS service can, at times, be difficult to discern from a more traditional managed service.

Unfortunately, many vendors continue to market and sell their legacy services as Cloud technology simply by retooling certain components. This is most commonly accomplished by repackaging the service to align more closely with some of the key features Cloud customers desire most; for example, usage-based pricing and the capability of rapid, self-service provisioning. This technique is known as “Cloud Washing.”

Buying Cloud-washed software or infrastructure creates risk for both the information technology department and for the organization as a whole. For example, take a quick look at the TPI Top 5 "Software as Service: Caveat Emptor," and turn each point on its head. You’ll quickly see that if you’re trying to buy Cloud technology but unknowingly buy legacy technology, you may end up with dated features, limited access, significant up-front investment and, potentially, a slew of customizations.

However, there’s also a contractual risk that has not received much attention. If you are not really buying a Cloud service, why should your contract include Cloud-like terms, which are typically very provider-friendly? There is a real risk here for enterprise buyers – a double whammy, if you will: You’re potentially buying legacy technology, and you’re getting unfavorable terms to boot. No CIO wants to be in this position.

How can you avoid this sticky situation? Given that there continues to be extensive debate about what is “true” Cloud technology, it helps to dispense with the term “Cloud” and instead think of the technology as a continuum, as shown here:

As you can see, if you’re buying a custom solution, you should fully expect a more customized agreement. As the technology solution you’re considering becomes more standardized, so should the terms and service levels. It’s a fair trade-off, as long as you have all the information you need to make a rational decision. As expected, service providers have a lot more information about the solution than you do, so it’s up to you to dig for more.

A great starting point is the National Institute of Standards and Technology (NIST) definition of Cloud Computing. The industry has (for the most part) agreed to this definition, so pull it out when you’re talking to your salesperson — but don’t stop there. Ask your Cloud provider other, more-probing questions. For example, does the provider’s application programming interface (API) framework remain stable when rolling out new features? What level of automation is in place for provisioning and failover? Answers to these questions will help you to understand where the service sits on the continuum.

Remember: the more Cloud-like the service, the more you should expect to see contractual terms and service levels that favor the service provider.

Bottom line: Dig deep into the nuts and bolts of the service you’re considering so that you don’t end up buying legacy technology underpinned with a Cloud-like contract.

Cloud Pricing Still Foggy

By Scott Feuless, Principal Consultant, Compass Management

One of the key benefits cloud computing promises to deliver is that of flexible, usage-based pricing for IT resources: use more, pay more; use less, pay less.  This model gives businesses transparency into actual consumption and eliminates – at least in theory – the problem of managing insufficient or idle capacity.  The result is optimized efficiency and a more agile enterprise.

The problem is, cloud pricing models aren’t yet capable of measuring IT usage in a way that’s granular enough to bill for it.  Consider, for example, CPU minutes, a basic pricing unit for cloud services.  Unless they’re running a mainframe, most internal and external IT groups today don’t have the monitoring tools to measure and log CPU minutes.  Moreover, a CPU minute on one machine can represent more or less processing than a CPU minute on another machine, so normalization is a challenge as well.

One potential solution is to charge for access time to a server “instance,” regardless of how many CPU minutes are required or used.  While this model provides some of the benefits of increased transparency and improved demand management, it still isn’t really a usage-based model, because an “instance” can be defined in the agreement to mean 750 hours of server time, and that turns out to be a full month.  The “size” of the instance is just linked to a specific hardware configuration, so although you seem to be paying for hours, you’re really buying access to a specific server configuration for a month, which isn’t all that different from what we had before.

Another issue is marketing hype.  Since there are no real rules about how some of the terminology is used, one cloud vendor may use the same words to describe interesting new ways to deliver services that another uses to simply slap a cloud label on a traditional delivery mechanism. 

Insight into the details of pricing and service agreements is essential, as is an apples-to-apples comparison of cloud options.  CIOs need to understand the true costs that will be associated with different pricing models, the different situations in which one or another scheme is more appropriate, and how their choices will support or undermine their overall IT and business strategy.

Ultimately, if you don’t account for the full range of business and technical requirements posed by the enterprise, the cost of a cloud solution risks becoming “in addition to” rather than “instead of.”

For another perspective on cloud pricing, read this recent CST blog entry by Stanton Jones, CIO of TPI.

Thinking About the Cloud? Don’t Forget These Financial Considerations

By John Cawyer, Director, TPI

Much is made of the importance of Cloud Computing, the endless options for what can be sourced to the Cloud, and the vast dollars that can be saved by moving services to the Cloud. But very little is said about what consideration should be given to specific financial structures and terms of a Cloud-based services agreement. 

Here are the TPI Top 5 financial considerations not to be overlooked when making Cloud-related decisions:

1.  Current contractual agreements should include commercial terms and pricing considerations to enable easy migration to the Cloud without financial penalty. Update termination language to include termination assistance for moving workloads or applications to Cloud-based solutions.

2.  Don’t expect the same terms and deal structures that you get in your existing hosting or outsourcing agreements. There are three distinct camps in the current Cloud space: 

•   Traditional service providers supplying Cloud services (IBM, HPES, CSC, etc.)

•   New providers specializing in Infrastructure as a Service (Rackspace, Navisite, Terramark, SFDC, Workday, and hundreds of other Software as a Service companies and their acquiring companies)

•   Traditional consumer companies rapidly evolving in the enterprise space (Microsoft, Google, Amazon, etc.).  Each of these firms is coming from differing backgrounds and experiences and has different contractual terms and pricing models based on their unique legacy experiences.

3.  Costs shift from capital expense (CAPEX) to operating expense (OPEX). You no longer own the software and hardware, so asset depreciation is removed from the book.  This is great news for companies trying to reduce CAPEX, but it requires better forecast and demand planning to ensure proper allocation of OPEX budgets.

4.  Expect greater transparency but more inconsistency in Cloud pricing. There tends to be different pricing structures based on whether Cloud is public, private or a hybrid.  Provider A may charge by processors reserved while Provider B charges by the CPU hour.  New total cost of ownership (TCO) calculators (examples below) and provider models are lending better insight into specific components of pricing, but be aware that these calculators only provide certain components of the pricing and that additional costs are likely.

•    CloudSizer.com (IDEAS International)
•    Microsoft Azure Pricing Calculator
•    Gogrid.com
•    Amazon Elastic Compute Cloud (Amazon EC2)

5.  The TCO, not just the base services price, needs to be fully understood when moving to Cloud solutions. While there can be great detail to the pricing, analysis of Cloud Computing models will usually be more difficult than legacy business case analysis. Whether produced from a vendor TCO calculator or not, the initial provider pricing will likely not include all expenses that will be incurred. Examples of costs frequently not included in Cloud solutions are:

•    Internal Level 1 service desk and technical resources to interface with the provider’s Level 2 desk
•    Migration costs to the Cloud
•    Additional network bandwidth (data transfer rates in and out)
•    Remaining book value of stranded assets and software
•    Remaining amortization of applications
•    Additional staff to manage new contracts
•    Cost of fulfilling minimum volume commitments in current contracts
•    Costs of partial termination of existing contracts

TPI Financial Analysis experts can help you make the most informed strategic move to the Cloud through objective advice, knowledge of your industry and experience with arrangements from simple to complex. For more information, contact John Cawyer, Director, TPI, at +1 972 342 1993 or john.cawyer@tpi.net.

Cloud Pricing: The Transparency Trend

By Stanton Jones, Vice President and Chief Information Officer, TPI

Microsoft recently released its Windows Azure Pricing Calculator, adding to the growing list of simple, web-based pricing calculators for cloud platforms. Amazon Web Services, a public cloud pioneer, has had a pricing calculator in place since 2009. Of course, in true cloud fashion, it’s still in beta. Cloud hosting providers have also embraced the “transparency” trend, with Rackspace, GoGrid and Navisite all displaying public pricing on their web sites. Some have had this level of cost visibility in place for years; others are just now going public with their cloud pricing.

But it’s clear – the transparency trend is growing and it’s growing quickly.

The good news: IT leaders are gaining unprecedented visibility into how much it costs to run key parts of their infrastructure and applications in the cloud due to this trend. The bad news: cloud calculators don’t represent the real cost to operate in the cloud, and many IT leaders are finding this out the hard way.

It’s analogous to buying a car online. The base price looks extremely attractive, but when all the options, tax, title and license are added to the base price, the cost may be as much as 50% more. The same can be said for enterprise cloud. When you add in everything else you’ll need for a true enterprise solution – training your staff on how to re-factor apps for the cloud, re-working your authentication framework, and building in business continuity and disaster recovery solutions – the cost may actually be more than what you’re spending today.

All of this translates into cost, cost that is incremental to what you are spending at the cloud provider. For example, let’s say you’ve made a call to move an important line of business application from your data center into Microsoft’s Azure Platform in order to speed up your release cycle. While the Azure Pricing Calculator indicates it will cost “X” per month to run this app, you’re still on the hook to re-factor the app to take advantage of the scalability and redundancy of the Azure Programming Model, figure out how you’re going to authenticate to it since the application is no longer sitting behind your firewall, and, if you’re not 100% confident in Microsoft’s service levels, make sure that you have a very recent copy of the data somewhere other than its data centers.

Usage-based cloud pricing can be very attractive, and warrants serious consideration for enterprise-grade infrastructure and applications. However, it’s also very important to remember that cloud platform and infrastructure providers are in the business of growing revenue via these emerging services and are very adept at marketing and selling these platforms to IT leaders. One way they do this is by being transparent with their pricing using polished, easy-to-use web-based calculators; however, these calculators won’t give you a true “apples to apples” comparison. That’s why the pricing usually looks so attractive.

Key message: just because you’ve chosen to process and store your data in the cloud, don’t forget about the other costs inherent in your IT environment: your staff’s skills need to be updated, your authentication framework needs to be rock solid, and you need to be confident your business continuity and disaster recovery requirements are met. Cloud pricing calculators won’t show you these costs (yet).

TPI’s seasoned transformational sourcing experts can help your company define the right strategy through our experience, objective advice, industry knowledge and depth in all aspects of information technology and business process services. To learn more about how cloud computing can benefit your organization, or to find out more about TPI’s cloud computing strategy offerings, contact Stanton Jones.

 

Amazon’s Outage: Architecting for Failure in the Cloud

By Stanton Jones, Chief Information Officer, TPI

 

The uproar surrounding the partial outage of Amazon’s EC2 cloud services platform got some new life last Friday, when the company released a detailed post mortem of the incident. The summary includes a surprising level of detail into the root cause of the outage, information on a service credit for impacted customers, and, finally, an apology from Amazon.

To recap: on April 21^st, Amazon made a configuration change during a network upgrade that caused a cascading series of events that resulted in what it calls a “re-mirroring storm.” As a consequence, Amazon’s storage service was essentially “stuck” and unable to locate new storage space for either new or existing customers. This led to a significant period of degraded functionality and downtime for major Web 2.0 sites such as Reddit, Foursquare and HootSuite, as well as a plethora of bad PR for Amazon, a cloud computing pioneer.

Interestingly, though, some other sites were only moderately affected, or not affected at all, most notably Netflix. Why did some sites sink, while others sailed through the storm? As with any complex system, there is no one answer. However, organizations that “architected for failure” tended to fare better than those did not. Netflix, which recently released its lessons learned from the outage, built its platform around the assumption that services and/or zones within EC2 could be unavailable for extended periods of time.

Clearly, not every EC2 customer has the technical chops to build Netflix-like applications, and Amazon needs to make it easier to increase redundancy by taking advantage of multiple availability zones. However, this is a public cloud platform, and customers that did not take full advantage of Amazon’s redundant architecture, or that did not create their own replicated solutions, ended up paying the price.

While architecting for failure in the cloud may appear to be a purely IT responsibility, it’s not. TPI views cloud as one component of your service delivery strategy, and regardless if they are delivered in-house or are outsourced, effective planning across all components is vital.

Business continuity planning (BCP) and Disaster Recovery (DR) are two critical parts of this planning process. Unlike a traditional outsourced agreement, in which the supplier takes on a significant level of responsibility in the delivery of the BCP and DR plans, the public cloud requires that customers retain a significant amount, if not all, of this responsibility, as well as the associated risk. In return they get a highly scalable, cost-effective and fast-to-provision computing platform.

Bottom line: Some organizations are finding out the hard way what happens when they don’t integrate cloud with their overall service delivery strategy. By including business continuity planning and disaster recovery in the cloud architecture design process, enterprises can significantly reduce the risk of business disruption.

 

 

Software as a Service: Caveat Emptor

By Stanton Jones, Chief Information Officer, TPI; and Bobby Neil, Director, TPI

Here’s a challenge: Go to any enterprise software vendor’s Web site and try not to find a reference to the terms “Cloud” or “Software as a Service” (SaaS). These terms have become so pervasive that they are almost indistinguishable from the software itself.

A surprising number of applications are marketed and sold as Software as a Service, but in reality, they are hosted or “on-demand” versions of an application that may have been built many years ago. How can you decipher whether the product is truly SaaS? And, more importantly, why should you care?

Here are the TPI Top 5 ways to determine if you are buying authentic Software as a Service:

1.  New features are included and are delivered often: SaaS is designed and built on a “multi-tenant” architecture, which means you share the application software and hardware with other customers. Given that the vendor only has one code base to manage, they can enhance that code base often; think weeks and months rather than quarters and years. Why you should care: The vendor can focus its efforts on improving the product as opposed to planning and executing numerous custom implementations. This means you benefit from enhanced features and functionality delivered faster and more often. 

2.  Access it from anywhere, including your smartphone or tablet: Most SaaS applications were built recently; therefore, they were architected for the Web with mobility in mind. Why you should care: given the exponential growth in the mobile computing industry and rising expectations from a global, virtual workforce, SaaS applications are ready to take advantage of this explosive mega-trend.

3.  Pay for what you use: SaaS pricing is typically focused on unit-based pricing, e.g., users, bandwidth and storage — not software, hardware or maintenance costs. Why you should care: while a less capital-intensive approach to software is inviting to many CIOs and CFOs, it’s important to plan for the unexpected. If you acquire a company or triple your storage requirements, your price may increase substantially. On the other hand, if you divest or the business moves in a different direction, you may have the ability to rapidly scale down your costs.

4.  Configure, don’t customize: Generally speaking, when you change a SaaS application to meet your needs, you’ll do so through vendor-provided customization screens accessed via a Web browser rather than via code. This is because the underlying system is shared by all customers, so it cannot be changed unless the vendor changes it. Why you should care: Given the standardized nature of SaaS applications, it’s important to make sure your requirements can be met via available configuration options rather than deep customization. Otherwise, you may be saddled with an application that does not meet your specific needs.

5.  The price is flexible, but the service level agreements are not: Given that all customers share the same infrastructure, and that the vendor’s business is built on economies of scale, SaaS suppliers are usually hesitant to negotiate on “customizations,” which can include custom service levels. Why you should care: If highly specific and transparent service levels are important to you, you may have difficulty getting what you need from a SaaS vendor. However, remember that the vendor’s unit cost goes down with each new customer they add, so adding more users may allow you to negotiate a lower price.

TPI CIO Services experts can help you separate fact from fiction through objective advice, knowledge of your industry and experience with arrangements from simple to complex. Need help evaluating the myriad of IT options and their potential benefits or pitfalls? Contact Stanton Jones or Bobby Neil to learn more.