The battle has been raging for a decade between on-premises data centers and the cloud, but it's now clear that the cloud has won. Sure, there'll be on-premises systems in use for years, just as there are mainframes and Cobol apps in use today. But the on-demand cloud model is becoming the norm.
But perhaps not as you'd expect.
The cloud battle is usually portrayed as a choice between highly customized, highly managed, purpose-built internal systems that take an army to manage but deliver very specific competitive value versus more generic cloud services that take fewer resources to maintain and secure but at the (perhaps small) price of standardized processes and options that force companies to find nontechnical ways to differentiate themselves.
That "differentiation through technology" notion was an article of faith in the last decade, and it's why every company customized its ERP system to the point of collapse and spent buckets of money investing in technology innovation across operational and analytical systems.
Moving to the cloud involved more than a loss of control over systems, it meant giving up technology as a secret weapon. It turns out that "secret weapon" thinking was simplistic, and the common result was a mess of systems whose complexity undercut their purported business advantage.
But the age of generic technology also hasn't happened, even if the cloud has allowed companies to take advantage of less-complex systems, creating space for meaningful innovation. A great example of that shift occurred at Tribune Media, which got the rare chance to do a greenfield technology deployment. It ended up with a mixture of cloud technologies (such as SaaS), cloudlike technologies (in the data center), and a small portion of traditional technologies.
What it shows is an example of the postcloud world now emerging. Vanilla shouldn't be the only flavor, and the cloud's "the sky's the limit" on-demand pricing model and the issues of bandwidth and latency create new costs that are often as unreasonable as the old approach of going super custom and thus super complex -- for infrastructure, applications, and data alike.
What instead is happening is the triumph of a few key notions whose deployment depends on the right combination of price, complexity, responsiveness, flexibility, and strategic advantage. Let me state it this way: How you deploy is a tactic, not a goal. That's the biggest lesson to learn in the post-cloud world.
What are those notions?
Design for change: Whether it's a browser or an analytics engine, know that needs and context around information and business needs will change, so don't tie yourself to brands, formats, tools, or providers when you don't have to. Containers like Docker are the latest instantiation of that notion, and containers won't be the last.
A modern cautionary tale is the concept of big data, which originally meant preserving data context rather than transforming it ETL-style beyond recognition, limiting its future utility. Unfortunately, big data today is becoming more and more like cloud-powered data warehousing, confusing the small advantage of on-demand processing with the intrinsic advantage of preserving context for multiple possible uses on demand. That's not cloud, but 1990s IT.
Minimize customization: IT went way overboard in the ERP days, encoding lots of dubious behaviors that users were sure were the absolute best way to do something. That pattern persisted in other "blood flow" applications such as CRM and HRIS. That's why so many early ERP deployments ended up with negative ROI -- they tangled themselves up into unworkable systems that couldn't evolve at any reasonable cost.
You should minimize deviations, exceptions, and variances because the truth is most don't do you any good, no matter what your users believe.
Yes, some customization is necessary, but not that much, so the burden to justify customization has to be high. Cloud systems, because they require large-scale adoption to make profits, are biased against customization and toward configurable multitenancy, providing a new method for discipline you can apply even in the system you build.
Keep it as simple as you can: The corollary to limiting customization is encouraging simplicity. Simplicity is not easy to achieve, but it pays back in so many ways, including user adoption, technical support, adaptability, and -- most critical -- achieving a results focus.
Again, the need to scale and support multiple types of use cases means the cloud favors simplicity in design and deployment.
Don't overrate performance: Computing devices get faster and faster, leading to an insatiable desire for instant gratification. On the other hand, the Internet's performance is variable, a fact of life for everyone that should teach us speed is not the ultimate goal -- reasonable performance is.
Achieving reasonable performance is much less expensive and time-consuming than achieving maximum performance. But remember that the goal posts will move over time, and today's reasonable will be tomorrow's slow.
Still, achieving reasonable performance is a good yardstick for deciding when to go on-premises or in the cloud. If you can't achieve it in the cloud for a system that truly matters, you have to go in-house, whether that on-premises system is an old-school system or one built using private cloud techniques.
Favor results over control: The cloud requires loss of ownership because public clouds are not your systems. You're a renter, with limited rights to your space. Control is overrated and has a large cost. If you get the results you need from someone else's efforts at a lower cost or burden, you don't need control. Like customization, control is sometimes necessary, but not as often as people believe. Be both explicit and clear-eyed when making that decision.
Why do I call this postcloud? Because the cloud itself isn't the point. It's an architecture, a method, a pattern. What makes a good cloud good also makes any data center good. The "private cloud" notion has been abused to mean "my data center under a new name," which is too bad. There's a real place for a private cloud, meaning systems that have the characteristics I've outlined and that happen to run on premises or in a colocation because that's the best place for them to run.
If IT can get past the notion of on-prem vs. cloud and instead focus on the underlying principles of cloud computing, it won't matter how those principles are instantiated. That is, the cloud will no longer mean where, but how. That's postcloud. And we're already on our way.