2nd Generation Cloud Lessons

So where's the post on 1st generation lessons? I didn't bother to write one because I feel the popular press has done a good job of detailing the promise and shortcomings of the public cloud.  The fact we had to divide cloud into private and public (and the mythical hybrid cloud) underscores we started on a rough foundation.  Marketers have done a great job of making cloud as confusing as possible to the point that again, the term is meaningless because it's so misapplied and misunderstood.  Ok, off the soap box.

What I want to share are the 10 lessons I've documented by those in the throws of the 2nd generation of cloud which is primarily the combination of Public PaaS and Private IaaS.  These are listed in the order in which companies seem to run into each issue.

Lesson #1: The Fear of Automation

I have seen a tremendous fear of turning over the operation of an infrastructure to rules based management systems. First, the rules by which administrators operate are not as well defined and understood as managers would like to believe. More intuition and on-the-fly problem solving are involved than anyone wants to admit. Its hard to automate something that is not well understood and for which rule cannot be defined. However the bigger limitation seems to be fear; if we automate it we lose control of it. I would agree if the concept of fail-safes and emergency stops didn't exist.  If we can automate assembly lines to the point modern factories are often lights-out environments, we can automate the data center.  The same rules apply.

Lesson #2 Dynamics of Image Management

Imaging is an important part of rapid provisioning.  Each environment from operating system through the application is wrapped into a nice package for quick delivery to compute resources when required. However the constant need for patches, updates, emergency fixes and the like make images obsolete within days of creation. It is important to understand the days of a static, golden server image are over. There are several approaches of which at least three seem to prevail: active manual image management, automated image management, and image cascading.  Active manual management requires a subset of the team to rebuild images as necessary based on changes to ensure images stay up to date.  Automated management lets the team push the burden of updates onto a tool which merges changes into the image.  Image cascading de-couples the variety of installed components and does an automated install of each rather than a true image copy.  Each approach has it's merits and drawbacks, but the biggest issue to date is the quality of the available tools.

Lesson #3 Where's the "pay as you go"?

The economics of cloud are what make cloud such an enticing tool for the enterprise. Even in the single minded private cloud model, the business users who are paying the bills only want to pay for what they consume. Today the IT department solves this problem, if at all, by jacking up the per hour rate so the end result looks like the consumer is only paying for what they use. Per hour consumption of resources makes IT services a commodity and glosses over the value of what they provide. Hence there is tremendous fear in providing a "pay as you go" model to the business. However once some smart analyst compares internal costs to the public cloud all hell breaks loose and he explanations begin. In the end its this "trapped customer" opinion that will go a long way to unraveling a significant part of the on-premise private cloud. The end model needs to provide the business with options: host internally with all the control and security at X per CPU hour, host off-premise in a private cloud with a bit less control and security, or go for the bargain basement at Z for little control and minimum security. Of course when options Y and Z are on the table it will require the vendors to provide "pay as you go" just like the regular public cloud, and they fear this as much as internal IT.

Lesson #4 De-provisioning

Once the "pay as you go" mountain has been climbed, the next challenge is to actively manage the costs. Public cloud users have been on this bandwagon for the past several years, but its new to the Enterprise. As budgets for cloud are moving from IT to the lines of business for Public SaaS, it stands to reason they will for other technology services and with good reason. Want IT to be competitive? Require them to compete! The challenge is identifying servers which are at low utilization and migrating jobs off those servers to servers with capacity while not interrupting users. Tools, integration, and automation are all required to make de-provisioning happen in a meaningful way.

Lesson #5 Tool Maturity (and the lack thereof)

By this time organizations get pretty frustrated by the amount of integration and business rules development required, and the barriers caused by having disparate systems from vendors whose visions may overlap but rarely lead to the same future. Open standards and open source will be the keys, but both will necessitate patience which threatens the competitive advantage of cloud. Organizations that run complex IT shops well will benefit while others should understand what they are getting into. Moving to a software defined world will help, but it will not be the silver bullet.

Lesson #6 The Application Development Gap

Most Private IaaS implementations fail to garner the widespread adoption used in the business case to justify the investment, and a pattern has emerged on the reason why. Application developers are rarely invited to the party. As its name implies, implementers of Private IaaS tend to be infrastructure people who focus on hardware, virtual machines, and operating systems. To them the job is done once the self-serve web site is up and running enabling consumers to build the server which suits their need. Web developers tend to be comfortable in this model however they are not the norm. Most developers cannot double as system administrators and wouldn't know what to do if a Linux or Windows box fell into their lap. My favorite quote of all time from a Computer Science major was "My knowledge of the hardware is limited to the on/off button". And that's why I got my degree in Computer Engineering!  Application developers have needs too, and if those needs are ignored they will return the favor. Every large enterprise I know of with one exception has made same gaff.

Lesson #7 The Role of Automated Testing

Developing applications in the cloud is half the battle; the other half is testing. Clouds tend to be built on web technologies (Apache, server side scripting languages, web services, HTML5 and CSS3, etc.) using web approaches (frameworks, Agile methods, etc.) which result in a much faster pace of development and release. As a result its important to be able to test the application in each iteration; add in the constant patches and updates and it becomes paramount. Without automated testing cloud development is stillborn.

Lesson #8 N+1

Ugh. From the stories I've heard and situations I've experienced, this is the one challenge that catches EVERYONE off guard. Moving from one cloud version to another is not for the faint of heart, but it's a reality. Major upgrades in capability or underlying components are often the cause of significant outages at even the big players like Amazon, Netflix, eBay and Facebook. The only way to avoid this is to grow new clouds next to existing clouds and migrate over time using automated testing, keen observation, strong alerting and exception management, and a bit of prayer. Falling back to the previous environment is a requirement. It's the change management gurus ultimate test!

Lesson #9 Security Scares

At some point the security team needs to get comfortable with the idea data will sit off site. I know of no Fortune 500 with a well defined policy on what data can be stored in a cloud off-site and what corresponding standards, processes and tools are to be used. yet every Fortune 500 company has data stored off-site. If for no other reason, the proliferation of data and the emerging business value of mobility will compel the business to need capabilities outside the traditional data center. 

Lesson #10 Leader Egos and Agendas:

Managers build kingdoms of control, leaders unify kingdoms into nations. However many a great leader still has an ego and an agenda and the wheels came come off the cart quickly when leaders clash. As the budgets move to the business and IT moves toward a commodity, the claws will come out. CIO's are increasingly a competitive threat to COO's and I believe will be the next generation of CEO's, a view shared by several friends in management consulting. I have to believe CFO's will have a say, a traditional source for Fortune 500 CEO's for decades. In my humble opinion the CIO role will dissolve and CIO's will become the next generation COO's for all the right reasons: technology and the business will be viewed as one coin instead of two sides.

Enterprise PaaS is a Great Strategy

When the CxO's get together to talk about strategy in our technical world, where is the conversation focused? Increasingly the discussion includes catch phrases like mobility, cloud, social media, and big data. In my experience the discussion starts with the business process, recently they've added the customer experience to the conversation, and about as deep as they go is down to the data. Why is that important to understand? In the world of the CxO they don't care about any technology below the apps and data (with the obvious exceptions of the CSO and the CTO who, often enough, only cares down to the integration layer). Every thing else is "staffed out" to their senior execs then down to senior managers, then managers, and then to the teams responsible. I'm painting with a broad brush I admit, and I'm not saying there are CxO's who can't talk stored procedures or network design, but it's not their focus. When it comes to cloud, the platform for mobile applications, social media, big data and business collaboration, the C-suite gets it! CEO's love the time to market benefits. CFO's love the capex vs opex and asset light approach of cloud. CIO's want the agility just as much as the COO's. CSO's like the private cloud model keeping everything inside the four walls.

Today the cloud strategy at large enterprises starts with building an infrastructure only private cloud build-out, often built upon a VMWare foundation. Company by company the consistent learning is mass virtualization does not lead to native cloud application development, the ultimate goal of cloud. Whether from a vendor or developed internally, native cloud applications deliver tremendous benefits including continuous availability, software reuse, efficient use of resources, and easier integration. What is missing at first, and often added quickly after adoption of the infrastructure private cloud fails to meet adoption goals, is the development of an Enterprise Platform as a Solution capability to engage the in-house developers and bring them into the cloud.  Enterprise Private PaaS is a significant part of the Fortune 500 Ready Cloud.

Simply put, a PaaS solution provides both a framework and supporting services to simplify the development of native cloud applications. An Enterprise PaaS scales the concept to meet the needs of the enterprise instead of an individual developer, team or small company. It may appear inconsistent that someone who advocates the use of Public Cloud (off-premise, multi-tenant) is advocating a Private Cloud focus. True, however here are my arguments in favor of Enterprise PaaS:

• Developing Native Cloud Apps - drives developers up the learning curve on developing native cloud applications by reducing barriers and providing a platform for learning. Nobody can learn to develop for a cloud without a cloud.
• Leveraging a Hybrid Cloud - CFO's and CIO's are keenly interested in tapping into the economic benefits of using someone else's IT assets (private off-prem or public). This is where the agility benefits are realized; the ability to scale up and down and deploy on demand as needed.
• Taking Out Costs - infrastructure costs run 4-15% of an IT budget whereas applications comprise 30-50%. In addition the application costs are directly related to personnel costs which are an expensive, difficult to attract and retain resource.  Developing enterprise cloud services provides a significant opportunity to reduce development, testing, and people costs.  It helps that cloud solutions are largely predicated on open source and not proprietary solutions.
• Moving to an Asset Light Foundation - cloud provides the opportunity to unchain ourselves from the evil reality of asset ownership, so driving adoption with Enterprise PaaS helps drive the benefits of asset ownership reduction.
• Third Party Web Services - Nobody wants to reinvent the wheel, especially when it means starting back at the beginning when the wheel was made of rock shaped by another rock and lots of elbow grease.  Third parties are building and offering API's as a means of deeper and broader integration.  In the future many solutions bought today as services, and even applications, will be replaced by automated integration via web services.
• Talent Management - Its already tough enough to compete for talent against companies like Google, Facebook, and Amazon.  Providing access to the same technologies will go a long way to attracting and retaining talent who don't want to fall behind their peers.
• Path to the Public Cloud - you knew it was coming, my argument for how private cloud benefits public clouds.  As one who as warned about the pitfalls of private clouds, the benefit that outweighs the cost is ITS STILL CLOUD! Any step that increases the understanding of cloud is a positive step. Let the security and economic considerations play out over time. I have cast my lot with the group who expect the public cloud will win in the end. I don't care how companies get there.

Enterprise Private PaaS is a significantly important step in the direction of cloud adoption. Without the ability to write native cloud applications the true value of cloud, revenue generation, cannot be delivered. Writing these applications requires a shift in the mindset of developers, new tools, new programming skills, and steady movement up the learning curve.

Enterprise PaaS is the gateway to cloud innovation - step on through!

Creating the Cross Channel Customer Experience

We all know it can be pretty frustrating today. You start doing something on line, but the phone rings. You have to run so you grab your keys and head out the door. Luckily there's a break in the day so out comes the mobile phone but the app has no record of what you were doing. So you call the company for support where you spend the first 10min in a queue followed by 10min of trying to describe to the person what you were doing. The empathetic agent is willing to help, but you need to start over. Of course the piece of paper with the information you need is on the desk, at home, next to the phone.  When you get home you rush to your desk, jiggle the mouse so your screen turns back on, only to find out your session has timed out.

Ugh.

Today companies are struggling to provide a consistent customer experience across the variety of interaction channels. Is it unreasonable to expect what you start via one channel you continue via others, bouncing back and forth as needed, until the transaction is complete? No. However at the technical level it's no easy task to accomplish. The online application comes from the eCommerce team, mobile application from the Mobile team, CRM from the contact center group, and the retail outlets only have their Point of Sale system which is not the most friendly tool. We've spent alot of time and money getting to "one view of the customer", bringing CRM into the shared services IT organization as the golden record of the customer. We've spent more time and money integrating our other tools to the golden record; some are new enough they had access from day one. So we know who the customer is, what they've bought before, every time they've called, and even how valuable they are as a customer. However what we don't know is what they are doing right now with us. Some of the systems don't track it, often in the name of security despite the customer having passed multiple tests to initiate the interaction. Why didn't we solve for this problem at the same time as we did the golden record? Simple. We had fewer channels, customers had a strong preference for a single channel, and we were focused on the customer identity, not their goal.

How do we solve this problem? We need to start tracking what the customer is doing and sharing that data across channels. Many web sites are good at solving at least part of the problem enabling a customer to pick up where they left off, or signaling for help when they get confused. However this capability is integrated into the channel. Do we want to build a solution for each channel? If so how do we keep transaction components in synch especially now that there is no channel affinity? I believe the answer is building a transaction index.

Building a transaction index service enables each channel, including ones not yet main stream such as the connected car and M2M (not familiar with M2M? Worth doing some research) to work in concert. As expected the transaction index would uniquely identify every transaction by person and identify every transaction type. Combined with date/time stamps, channel indicators and device identifiers, a developer would have enough information to make intelligent decisions to maintain the customer experience throughout the transaction across all channels. As a service its designed for scale, reliability, and availability with geographic caching to aid in speed (keeping the data local while transactions are in a pending state). Every time a transaction is initiated the index is consulted to determine if the transaction is a continuation of a previous interaction or new. Should any doubt arise the customer could be queried. The index identifies the current step in the transaction, provides access to the data already collected, and returns this information to the requesting application. Each transaction step updates the index so it contains the most current information. Once a transaction is complete it is removed from the index, whether deleted or archived. Existing policy management would continue to govern what processes and data are available in each channel.

Such a solution enables a more robust customer experience. Transactions can be aged to trigger escalations or support. Abandoned transactions can trigger proactive responses from outbound emails and calls to a query from a retail employee to determine whether or not the customer needs assistance.

As a challenge I've been considering for the past few years, my wife's experience with a well known web site over the past 12hrs prompted me to put forth my idea. With an account she accesses via the web as well as an iPad app, she did some preparatory work on the web site last night. She decided this morning to complete the work on her iPad. When she went to save her work, she had to sign in to the service. After doing so, her three hours of work on the iPad app disappeared and only the preparatory work done via the web site remained. Honestly there was no excuse yet I totally understand why it happened. At a minimum you'd hope it would ask you a question. However the online and app versions were written by different teams, at different times, and the transaction data is siloed even though they obviously share a common golden record.

Perhaps my idea is naive, perhaps its genius. I see it as an extension of a tool, the index, into an area where a problem has emerged. Like most problems I expect people to look at the most common solution; building new capabilities into each channel application. I prefer the cloud approach. Build the service as a native cloud app and you gain all the scale, reliability and availability attributes while operating at the lowest possible cost. What's not to like?