Is hard return on investment all there is? In exploring business (and tech) projects, we have a tendency to think about the immediate, quantifiable ROI. Yet, there are times when the soft costs or other benefits outweigh any measurable ROI, and sometimes are even worth a negative ROI... in the short term. This was highlighted to me again yesterday. A colleague of mine is heading up a project to move tens of thousands of VMs from on-premise to the public cloud.

At the Container Summit, I was speaking with a colleague at a booth, when a potential customer of his walked up and engaged in conversation. He asked an interesting question: How do I know if my software is ready for the cloud or for containerization? While an interesting discussion ensued about the company's technology, the most important points of the conversation were three key lessons: Just about any software or application can be containerized.

Yesterday, I had the pleasure of attending Container Summit NYC, arranged by the great folks at Joyent. The first speaker, Dave Bartoletti of Forrester, gave a broad overview of cloud computing - private and public - and container adoption. One of his themes was the methods by which companies adopt new technologies, particularly cloud and containers, and the benefits they gain. New technologies enable new ways of operating. While some technologies simply make it easier or cheaper to operate in the same way as before, most enable new methods, new processes, new ideas that previously were difficult or impossible.

If you want to change technology that requires a change in process or, more seriously, culture, then you need to change the culture first. Get your people on board and then make the changes. Right? Perhaps not. Or at least not always. If your culture is flexible and open, people collaborate across groups and you are staying competitive, then, yes, change some of the culture to new ways of working, then adopt new technology that requires the different mindset.

This morning, Adrian Colyer posted his morning paper on a "functional programming." Most readers of this blog are not deep into different programming paradigms, so I will give a very short layman's overview here. For those who are comfortable, jump ahead a few paragraphs. (For the real experts, please do not nitpick on the details; the point is only to give an overview, not to debate the fine points.)

What do you do when you want to move towards more rapid deployment, perhaps as close as possible to continuous delivery, but the culture and incentives push against it? This is the exact issue I have had at several clients over the years. When brought in to improve their operational performance, I found that, with all of them, a major issue was instability due to deployments. The flow looked something like this:

You are reading this blog on WordPress. It is not a secret; any technologist with experience managing WordPress can look at the page and see that it is run by WordPress. How does WordPress show you this page? Here is what WordPress does, simplified: Look at the requested address, showing right now in your browser's address bar. Translate that address into a specific article. Retrieve the text for that article from the database.