Chapter 15

Assessing the Organizational Impact of the Cloud Model

People don’t hate change, they hate the way you’re trying to change them.

—Michael T. Kanazawa, transformation change expert

If we look back at the evolution of technology from the mainframe days, to the birth of the personal computer to the Internet age, and now the cloud, the one thing that is constant about these transitions is that they all bring a tremendous amount of change. Along with the change in technology, come changes in how businesses operate. Each transition altered the operating model of businesses. In the mainframe days, software was primarily used to support internal business functions like payroll, accounting, manufacturing, and the like. Consumers did not interface with systems, they interfaced with people like bank tellers, cashiers, insurance agents, pharmacists, travel agents, and so forth. Business and IT alignment was much easier back then because IT’s sole purpose was to build applications for the business.

The PC era created a new operating model where software vendors would package and ship software to customers, who would install and manage the software within their own enterprises. This new operating model required organizational changes in order for companies to support software that was running at customer sites. New support organizations were formed, new sales processes were created, and new software requirements were prioritized to deal with software running at client sites. Pricing models changed, incentives changed, contracts and terms of services changed, and even the types of customers changed. Business and IT alignment started to fragment because now IT had many customers, internal and external. In addition, IT now had to manage infrastructure and software distributed within and outside the enterprise, whereas in the past everything was centralized on the mainframe.

The Internet era changed the operating model drastically again by allowing businesses to sell goods and services directly to customers 24 hours a day. Now businesses could operate around the clock and outside of brick-and-mortar buildings. As in the previous era, huge process and strategy changes impacted sales, legal, development, support, and so forth. IT now had not only to deal with internal and external customers; consumers now were directly talking to systems. On top of that, internal systems were now at risk of being compromised by all kinds of external threats that could enter via the Internet. This created a huge gap in IT and business alignment because even more non-value-added work was thrust upon IT departments.

Now the cloud is here and the pattern of change is repeating itself once again. Cloud computing brings an enormous amount of change to a businesses operating model. These changes go way beyond the IT department and companies need to be prepared to tackle them. Now IT is building software that runs in the cloud and customers access it via the Internet. The days of shipping software to a customer and making a killing in professional services and annual maintenance fees are over. Large licensing fees and large capital expenditures coupled with long implementation projects are a distant memory. The expectation now is that the software is turned on, always works, gets updated regularly, and we only pay for what we use. Talk about change! Let’s take a closer look at how these changes impact organizations.

Enterprise Model vs. Elastic Cloud Model

Prior to the rise in cloud computing, many companies participated in what is called the on-premises software delivery model, also known as the enterprise model. In this model, companies built and managed their own data centers and infrastructure and built software that was either shipped to customers or downloaded by customers. In the software delivery model, major releases of software were typically delivered annually or semiannually with small patches during the year to fix critical defects or release an important feature.

The software was built with the intention that the customer or a professional services company would perform an install or an upgrade of an existing install. Upgrades were disruptive to the customers’ day-to-day business. Customers had plenty of other priorities and did not want to be updating vendor solutions too frequently. The customer also was responsible for managing the physical infrastructure and the software, which included capacity planning, backup/recovery, and scaling. When systems were nearing capacity, the customer was responsible for procuring more hardware and more licenses. Purchasing this type of software required up-front capital for hardware, software, and human resources needed to implement the solutions. Many software products required long, complex implementations that might take weeks or even months. Other solutions required specialists to be brought in at outrageous hourly rates to perform the install of these proprietary solutions. Companies’ revenue models banked on professional services and reoccurring annual maintenance fees that averaged 20 percent of the initial cost. In this model, changes to the software happened infrequently, because of the complexity and the costs of performing upgrades.

Enter the cloud era and the new operating model, called the elastic cloud model. Randy Bias, chief technology officer of Cloudscaling, said it best in an interview that I did with him: “There is a fundamental shift in software that ships versus software that is hosted.” The shift caused by the elastic cloud model is as disruptive to businesses as the impacts of the Internet were back in the 1990s. In the enterprise model, once the vendors created and shipped a release, the onus was on the customer to manage the production environment. In the elastic model, the cloud providers are delivering a service that is always on, like a utility. Building cloud services raises the level of quality, speed-to-market, and customer focus that an organization must provide to stay competitive.

Here is an analogy that sums up the difference between the enterprise model and the elastic model. The enterprise model is like selling a generator to a customer and the elastic model is the equivalent of providing the electricity to a customer 24 hours a day. Once you build and ship the generator you are done with the customer interaction except for customer support calls. When providing electricity, the job is never done because the electricity must always work. If the generator breaks, only one customer is unhappy. If the electricity does not work, a lot of customers are unhappy. Obviously, the company providing electricity requires a very different organization than the company selling generators.

IT Impact

The following sections highlight the areas within IT that are impacted when moving from an on-premises enterprise model to an elastic cloud model.

  • Deployments. Deployments in the cloud happen frequently and in flight without downtime as opposed to shipping patches or full releases and relying on customers or field service technicians to install the software.
  • Customer support. The cloud vendor will be responsible for all infrastructure, autoscaling, patching/upgrading, security vulnerabilities, service level agreements (SLAs), and more. Customer support will expand beyond application support and will now extend to 24-by-7-by-365 real-time support of a highly reliable, scalable, and auditable platform.
  • Regulatory. Cloud-based software is held to a much higher standard than shipped software. Because customers are giving up control of the infrastructure, data, security, and the SLA, they shift a lot of responsibility to the cloud vendor. Along with that responsibility come regulatory requirements such as SAS70, SSAE 16, HIPAA, SOX, PCI, and more. Customers that are bound by these regulations will require that their providers are compliant, as well.
  • Monitoring. Running a real-time platform requires rigorous monitoring, logging, and system-level metrics collecting. The best platforms take a very proactive approach and look for variances in their data to head off problems before they become catastrophic. For example, if a certain API is called 1,000 times a day on average but all of a sudden it is called 5 times or 5,000 times, somebody should look at the logs and see if something is starting to go wrong. Organizations must be more proactive in their monitoring in the elastic model.
  • Availability. With shipped software it is up to the customer to manage the infrastructure and perform the appropriate capacity planning. With hosted software the vendor must meet or beat published SLAs. To do this the vendor must deliver extremely high-quality software that can be updated seamlessly without downtime. In addition, the software must automatically scale up and down to handle traffic peaks and be able to fail over automatically in the event of a data center failure.
  • Independence. With shipped software, customer independence is easy. Each customer gets software shipped to it and each customer is mutually exclusive from any other customer. In a multitenant environment this is much harder to achieve. Most cloud vendors will want to use shared resources as much as possible to keep costs down, but they may also need to segregate certain components like data, billing information, and performance so that clients can’t access competitor information and to prevent a performance hit in one client from impacting the others.

Business Impacts

Cloud computing’s impacts go far beyond the walls of IT. It is critical that the business impacts are understood, as well. The following sections will discuss the impacts to the accounting and finance, legal, sales, and human resources departments.

Accounting and Finance

Cash flow is one of the most important pieces of financial information that investors and shareholders look for in financial statements. Cash flow is simply the difference between how much money flows into the company (revenues) and the amount of money that flows out (expenses). Cloud computing changes both the sources of revenue and the outgoing cash. In the enterprise operating model, packaged software was purchased up front before the software was installed and put to use. There was usually an annual maintenance fee that ranged from 18 to 20 percent of the initial purchase price. Sometimes there was also a professional services charge for the installation of the software, which might be a multiweek or multimonth effort. From the seller’s perspective, sales were fairly predictable because the pricing was a known entity and easy to forecast. For buyers, a large up-front investment was required, which negatively impacted cash flow. It would take time for the revenues generated (if this even was a revenue-generating tool) to cover the up-front capital expenditure.

In the elastic operating model, the cash flow story is much different. Most cloud services are sold as a pay-as-you-go model where buyers have no up-front costs and only pay for the amount of services they use. Some cloud services charge a monthly subscription fee, but there is still no large investment to get started. As a buyer, the capital expenditure (CAPEX) is removed from the equation, and the cost of the service is categorized as an operating expense (OPEX). The buyer pays for the cloud service at a rate that is proportional to the rate at which it brings in revenue or value to the organization. For example, a company leveraging Infrastructure as a Service (IaaS) pays for the amount of compute capacity required to launch its first customer. As the company starts to acquire more customers, it ramps up its spending with its IaaS provider in support of the increased incoming revenues. If managed properly, the company scales its costs with its revenues, and the costs are considered OPEX. This approach frees up working capital to invest in other areas of the business.

One challenge that the pay-as-you-go model presents is that the predictability of revenues and costs is much more dynamic than in the enterprise model. In the enterprise model, a customer paid an initial cost, which was a one-time fixed cost. Annual maintenance costs were very predictable. If the customer needed to buy more, it went through a procurement process, which was easily tracked. In the elastic model, the seller has very little control over the amount the customer spends because the customer is consuming services on-demand as needed. One month a customer may use 25 percent more services than the next. Forecasting becomes much less predictable as both the revenues and the operating expenses fluctuate based on usage.

The product team should work closely with the finance team to determine the optimal pricing structure that satisfies the needs of both customer acquisition and corporate finance and accounting.

Legal

Contracts for cloud-based software and services are much more advanced than contracts for shipped software. These new contracts have specific language around privacy, data ownership, and numerous other regulations such as SSAE 16, HIPAA, PCI, and more. The due diligence process for both the buyer and seller of cloud-based software and services is much more robust and time consuming than in traditional enterprise software because the vendor is taking on more responsibilities on behalf of the customer. Also, the laws and regulations are changing as regulators are being pushed to update their policies to accommodate the digital era. In my experience, buyers of cloud services are much more demanding and more rigorous in the vetting process, especially around privacy, security, SLAs, and certifications. The amount of time it takes to close a deal for a cloud-based B2B service far exceeds what it took when I was making noncloud-based software sales to enterprises.

The legal department should prepare for more requests and more thorough evaluations of products and services. If this group is not prepared for the increase in work, it could become a bottleneck and slow down customer acquisition. In extreme cases where the competition is fierce, a bottleneck in legal could cause the deal to be lost. A best practice is to produce a document that spells out all of the policies and procedures pertaining to privacy, security, regulations, SLAs, ownership, and so forth. Some companies create two documents. The first is a high-level public document that does not require a nondisclosure agreement to be signed and that can be handed out to potential customers and even posted on the company website. A second document is a more detailed standard document that sums up all of the legal information that would be in a contract. The quicker the seller can put the customer at ease, the faster it can close the deal. Without these documents there is a risk of endless requests for information from customers.

Sales

Selling cloud-based software and services requires that salespeople upgrade their technical skills. Salespeople must, at a minimum, understand the basics of cloud computing and be able to discuss things like privacy and SLAs at a high level. For the next few years until cloud computing becomes the norm for companies, salespeople will have to spend as much time selling the value of cloud computing as they will selling the value of their product.

Selling in the elastic model is very different from selling the enterprise model. Obviously the pay-as-you-go pricing model is very different from the large up-front acquisition model. In many cases, buyers are not locked into long-term commitments and simply pay by the month. The time it takes to implement a solution is drastically reduced as well, in most cases. In the past, there was usually a long procurement process that included hardware, software, professional services, and project plan for implementation. In the elastic model, many services can be turned on instantly as soon as the buyer agrees to the terms. Often the entire sales process occurs with no intervention from the seller. Buyers can go to the sellers’ websites and click a few buttons and start consuming services. In such cases, the selling process is more focused on advertising and raising awareness through social media, conferences, e-mail campaigns, and many other media outlets.

Just because cloud software can be turned on with the click of a button and the registration of a credit card, does not mean that enterprises will forgo the evaluation process. It really depends on the service that is being provided. An IT team looking for a collaboration tool may make that decision without a robust evaluation and sign up quickly to start using the tool. A company trying to decide between IaaS vendors may perform a very thorough evaluation, including several meetings with each provider with detailed discussions concerning finance and legal.

Human Resources

Many companies do not have the required skill sets for cloud computing, so human resources (HR) will be asked to find cloud-ready employees. Not every city has a surplus of cloud talent, which will require recruiters to look both nationally and globally. Many cloud experts will not want to relocate, so remote employment will be a key to acquiring talent. HR will have to balance leveraging full-time employees with consultants to get the right mix of talent required to take on the challenges of cloud computing. There are a large number of cloud consulting companies, but buyer beware. Just about any company that was in the consulting business is now magically a cloud consulting company. There is a good chance that anyone who reads this book front to back knows way more about cloud computing than the high-priced consultants that claim to have expertise. Interview these consulting firms as if they were applying for full-time positions within your company. Don’t be fooled by the marketing slides and fancy business cards. Cloud computing is very new to enterprises and very few people or companies have relevant experience yet.

For companies building cloud solutions, it is highly recommended that they evaluate existing rewards and recognition programs to see if they make sense for today’s software development methods. In Chapter 14, we discussed how important it is to break down the silos in IT. Throughout this book it has been stressed how critical it is to build loosely coupled services. HR and IT should brainstorm ways to foster this desired behavior. If the current incentives do not encourage people to make this change, then it is foolish to think that things will magically change. Evaluate the existing organizational structure and make sure it is optimized for information sharing, learning, and silo busting. Create a DevOps culture that prides itself on teamwork and collaboration. Reward people for the new behavior and discourage the old behavior.

Organization Change Planning

In order to succeed as an organization, our fictitious company, AEA, needs a change management plan to lead it through this transformation. The CRM project is just the tip of the iceberg for change. There is substantial change required to deliver the future version of the auction site that will be a Platform as a Service (PaaS) solution connecting third parties to the auction engine.

The consequences of organizational resistance to change are poor implementations, projects that take too long and cost too much, and projects that don’t deliver expected results. In the most extreme cases, the company does not embrace the change and reverts back to its old ways. To combat these undesirable results, change expert John Kotter recommends an eight-step process to lead transformational change through the organization:

1. Establish a sense of urgency.
2. Create a guiding coalition.
3. Develop a vision and strategy
4. Communicate the change vision.
5. Empower people to drive the vision.
6. Create short-term wins.
7. Consolidate gains and produce more change.
8. Anchor new approaches in the culture.

Let’s see how Acme eAuctions (AEA) used Kotter’s eight steps to deal with the resistance from within the organization.

AEA Case Study: Organization Change Planning
In Chapter 3, we discussed the internal resistance of the AEA SaaS CRM project. The development team that wrote the legacy CRM system was resisting the decision to replace it with a new, modern SaaS solution.
After several months of not making any progress on implementing the new SaaS-based CRM application, AEA’s CIO, Shirley Davidson, hired Fred Sanders, a long-time expert on organizational change management. Fred worked with Shirley to start a communication strategy for AEA. The first step was to create a sense of urgency. They drafted a message that talked about how the new system would empower the sales force with mobile and social capabilities, thus allowing the team to be more responsive and customer friendly. The message also talked about the financial benefits to the company, including reduced costs, opportunity costs of redeploying internal resources to high-priority initiatives, and less hardware and software to maintain, patch, and upgrade. The third part of the message discussed the real-time and analytical capabilities that would give the sales team a competitive advantage by producing better lead generation, more collaboration, and more personalization for customers. The final piece of the message was to tie the delivery of this initiative to the critical path for sales hitting their stretch goals for the year-end. This would help the company reach its target numbers, thus giving all employees a chance to receive their full bonus at the end of the year.
Shirley and Fred then assembled a team (the guiding coalition) that was responsible for the delivery of both the project and the transformation. The team was made up of people across the organization who were both influential and respected. The team had a representative from finance, one from human resources, a middle manager from the infrastructure team, a director from application development, and an architect. Each one of these people had a center of influence within his or her area of expertise and could explain the question “What’s in it for me?” (WIIFM) for each employee. At the heart of all change is answering WIIFM for each person affected. Once people know why they are being asked to change, what that change means to them and the organization, and why it is urgent, the odds of their supporting the change increase dramatically.
Once the team was formed, it was tasked with taking the urgency statement and creating a vision to be communicated throughout the organization. The vision clearly articulated the future state and the improvements to the overall effectiveness of sales due to these changes. Once the vision was formed, the team created a communication plan that included a town hall meeting to discuss the urgency and the vision and answer any questions. Each member held small team meetings with various teams throughout the organization to discuss the change in terms that were relevant to each team. For example, the finance team meeting focused on the changes involved from buying software licenses and hardware up-front to paying for services on demand. The application development team’s discussion focused on moving away from building noncore-competency applications in favor of integrating SaaS solutions. Each team meeting zeroed in on what was most important for that group. Different members of the guiding coalition blogged about the project and wrote articles in the monthly newsletter. They communicated the vision often and through multiple channels.
The team was empowered to make decisions, including removing any obstacles in the way, whether those obstacles were created by conflicting priorities or by resistance. Any blockers that they could not resolve would be referred to Shirley. In one instance, Shirley had to let go of an employee because of the negative influence that the person was creating. Once the communication plan kicked in, the project took off again, and in one month the program to migrate the data from the old system to the new SaaS-based system was developed and tested. The cutover was scheduled for early one Saturday morning. The data was imported into the system. The users and testers accessed the data all weekend and the team cut over on Monday morning. The feedback from sales was tremendous, and the team was rewarded with a catered lunch and gift cards to share with their families.
The next step was to use this project as a case study to promote more change within the company. The people on the team could now be evangelists for more SaaS-based solutions going forward. Fred’s job here was done. He and Shirley had created change and institutionalized that change as the new way to do business. Without the investment in organizational change management, AEA would likely not have completed the migration to SaaS and would be continuing to pay for a legacy system that was not meeting anybody’s needs.

Change in the Real World

I realize that the AEA change management example may sound more like a fairy tale than a real-world solution. Many years ago, I led a large service-oriented architecture initiative that required drastic change throughout the organization. Not only did it require IT to work across silos, it also required the business to drastically change business processes. There was a tremendous amount of resistance that was interfering with progress. At the time, I was earning my MBA at night when I discovered Kotter’s work in one of my classes. His ideas hit home and I bought and read more of his books on change. Feeling optimistic and energized, I returned to work and started implementing Kotter’s eight steps. It was challenging because we were already far down the road and resistance had already been established. But we made progress, especially where we could get the middle managers engaged. Some folks were just never going to get on board and it wasn’t easy, but had we not started implementing organizational change management plans, the project might have failed. The lesson learned is to implement this plan early and create a positive vibe before resistance settles in.

Summary

Moving from an enterprise model to an elastic compute model is an organization-wide effort that should not be underestimated. Not only is it a shift in technology strategy, but it is also a shift in strategy across all departments. Management should analyze each department within the company and identify the changes required to move the organization into an elastic cloud-operating model. Companies that recognize this and make the appropriate changes throughout the organization will have a higher degree of success than those companies that see it only as an IT project.

References

Kotter, John P. (1996). Leading Change. Boston: Harvard Business School Press.

Kotter, John P., and Dan S. Cohen (2002). The Heart of Change: Real-Life Stories of How People Change Their Organizations. Boston: Harvard Business School Press.

The Open Group (2013). “Building Return on Investment from Cloud Computing: Discussion: Financial Value Perspective of Moving from CAPEX to OPEX and Pay-as-You-Go.” Retrieved from http://www.opengroup.org/cloud/whitepapers/ccroi/disc1.htm.

Ross, S. A., R. W. Westerfield, and B. D. Jordan (2012). Fundamentals of Corporate Finance. Boston: McGraw-Hill Irwin.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.53.216