The Enterprise: I’m Not Sexy And I Know It

Editor’s note: Rodney Rogers is chairman and CEO of Virtustream. He is also chairman of Teliris and lead director of Greensmith Energy Management Systems. Follow him on Twitter.

I am a large enterprise. I employ many people and make a good deal of money.

I am a large enterprise. A vast array of technologies – with varying degrees of purpose and tenure – are required to run me. I have a complex, heterogeneous technology landscape. I have hundreds of millions of dollars of technology assets deployed on laddered refresh cycles through a variety of delivery models, all supporting highly differing divisional requirements across a number of development platforms. I employ thousands of developers, architects, and technical managers. I own just about every form of software known to man.

I am a large enterprise. I am not sexy. I am complicated. This will not change.

Cloud Idealists, Generalists And Extenders All Bore The Crap Out Of Me

I hear my legacy hardware providers oversell the cloud capabilities of their latest gold-plated appliances. I hear them fear-monger over my security and performance vulnerabilities.

I also hear those “cloud purists” that condemn me for being lethargic to adopt “real” scalable cloud technologies. They tell me that if my applications are not smart enough to use the public cloud efficiently, then I simply need to rewrite them.

I hear those that vigorously espouse the virtues of open source technology. The obvious benefits of accessible source code often carry support and extension technology costs with them. I’ll use open source all day if a) the software works, b) its capabilities align with my use-case requirements, and c) the math makes sense.

If you unnaturally extend or generalize cloud solutions to me, or if you pontificate cloud idealisms without providing tangible platforms that can service what I am, then you waste my time. When you waste my time, I discard you.

Please don’t misdiagnose this as me being slow to adopt your solutions.

Which Cloud Delivery Model? Um, Yes.

I believe my cloud IQ has come a long way over the past year or so. I feel like I can now defend myself from the incessant white noise of the cloud washers:

• I need public cloud for scalability and savings. I’ll ignore anyone that tells me otherwise. Anyone pitching me on the cost-efficient scalability of V-blocks, ESXi, SAN, etc. just loses credibility. My online retail applications alone generate half the revenue that Netflix does as a company. They drive massive instantaneous volume and go quiet just as fast. They need distributed hypervisor architectures, not hierarchal ones. They need direct attached storage, not block storage, etc. My mobile apps are largely in the early innings of their development, but it will be the same thing there as well.
• I need private cloud for security and performance. I’ll ignore anyone that tells me otherwise. I have millions of dollars of sunken technology assets well within their useful life. IaaS (public or private) for some of my divisions may just not economically work (yet). I do have the need for data isolation in certain areas. This is as much driven by my customer’s requirements as my own. Compliance certification is another area that tends to drive private cloud for the same reason. Oh and yes, the latency requirements of my global commodity trading desk? Come on. It goes without saying that true automation and self-service are required, otherwise private or not, it’s not a cloud.

Hybrid cloud: It’s not a buzzword for me, but rather a requirement. Further, my public and private clouds will need to communicate and rely on each other.

SaaS? Yes! From big SaaS (Salesforce, Workday) to emerging SaaS (Box, Zoho), I love them. We’ll migrate (or rewrite) applications to leverage the advantages of public cloud and/or SaaS as much as we can, as fast as we can.

ERP? Well, now that’s, uh, difficult.

The Death Of ERP Has Been (Unfortunately) Grossly Exaggerated

I need to make billions of dollars worth of product across thousands of SKUs every year, then store them, pick them, ship them, and invoice them. My products require complex recipe formulation, and in some cases, hundreds of bill-of-material subassemblies. I have a vast fleet of moving stock and so on. I need heavyweight functional systems to transact this.

This means that right in the middle of my cloud strategy sits a very large, highly integrated, very functionally intelligent, and very expensive “dumb app” (as you may refer to it from a “cloud-aware” perspective). I’m a very large SAP customer, and I spend more on this application and its supporting infrastructure than on any other one technology I own. It’s for this reason that it amazes me that most cloud providers simply punt when in comes to large-scale integrated ERP in the cloud.

Will large-co ERP and its legacy deployment model give way to big SaaS? Probably. Will that happen anytime soon? Not likely. Salesforce and Workday are not replacements for SAP and Oracle. They can enhance them, or replace some of their applications, but not wholly replace them. They just do not have the integrated business application breadth. Period. Have you ever tried to capacity-plan a packaging floor on Salesforce? Have you ever tried to run MRP, pick a pallet, and then run the resulting transactions through inventory accounting on Workday? Didn’t think so.

Can cloud really benefit ERP? It can, and to be clear, I’m not talking about running SAP on a virtualized appliance. That is so mid-last-decade.

As Freddie Mercury once sang:

Gotta find me a future, move out of my way
I want it all, I want it all, I want it all, and I want it now

To run SAP in the cloud, here is what I need:

1. Application-level SLAs without giving up the economics of multi-tenant: If you deploy an architecture that can control my compute and storage IOPS within your multi-tenant stack, you can give me application-level latency guarantees. With this I can then trust production instances of SAP, and thus my revenue generating systems, on your cloud.
2. Cloud sauce: Make this dumb app smarter by way of reverse engineering away (and thus limiting) how inefficient it can be. Use your cloud provisioning scripts to intelligently and dynamically downsize the application server landscape running my SAP instances, and then spin them up only when I need them.
3. Mainframe solutions: Some of my SAP database systems are running on Unix ;. Multiple hypervisor options, including things like PowerVM, are critical. If we are going to transition mainframe to an x86-based cloud, I’ll also need help with the migration.
4. Automated and embedded data replication features: I need to reduce my RTO from days to hours. I’m not even sure where Iron Mountain’s mountain is. I want instantaneous modernized DR for everything including ERP baked into your cloud service.
5. Landscape leverage: I, like many, have not kept up with precise serial iterations of SAP release upgrades. Utilize SAP golden images within your cloud service so I can test my “current version” data with “future version” system images. This will save me a huge amount of time and money on SAP release upgrades. Get me on-demand copies of entire landscapes for training or testing purposes.
6. Infrastructure cost savings over basic virtualization: You won’t get there via provisioning cloud in large, medium and small VMs. You’ll need to do better than that by way of pooling and utilizing the resource attributes of those VMs in a manner that essentially eliminates the inefficiency of sizing VMs to peak application workload requirements. And meter it so I only pay for what I actually consumed, not based on the size of the VMs you allocated to me.

You want adoption? Give me this and web scale, and I’ll adopt your face off.