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.
Sign up for MIS Asia eNewsletters.