The defining moment came when I was in Grade 8. My social studies teacher, Mr.Thiele, told us how and why Japan became a manufacturing leader after World War II. He had a theory. As the Japanese were forced to rebuild factories and infrastructure from scratch, they used cutting-edge technology to leapfrog other nations like Canada and the United States. My classmates were not convinced. How could it be an advantage to start all over again? Mr. Thiele contended that by building anew, Japan had access to newer and more efficient technologies that were beyond the reach of other countries. Combining modern management techniques and new infrastructure, Japan surpassed nations burdened by antiquated infrastructure and no money or compelling motivation to invest in new technologies.

I'm not sure Mr. Thiele got all his facts right, and I don’t mean to trivialize the challenges faced (and overcome) in post-war Japan. But starting from scratch with newer and better technologies can allow a company to gain a competitive edge. In this context, the Thiele Principle has guided me throughout my IT career.

Japan to Greece: A Thoughtful Approach for Improving IT Processes
When I investigate how an IT process works and why it came into being, I like to use the Socratic method to stimulate critical thinking and to generate new ideas. One of my favorite questions to ask IT staff is, how would you approach this if you were starting from scratch today? Usually the question gets the creative juices flowing, and people brainstorm new solutions. Which leads me to ask the next question: Why don't we go ahead and make the change then? In my opinion, this is a more effective way to solicit input rather than asking people to think of change simply in terms of cost-benefit analysis. It often turns out that IT staff see sunk costs as the biggest hurdle. That’s not good enough. I believe that sunk costs are irrelevant to the debate and lead to paralysis. Let me demonstrate the method with a real-life example.

The Road to the Cloud: From On-site to Co-located Servers
An employer had all its servers located in-house, with the exception of the web and incoming mail servers. This practice led to all kinds of problems. Water was often turned off in our aging office tower to allow for plumbing repairs. With water unavailable, the air conditioning did not work, and we had to turn power off in the server room to avoid over-heating.

In-house servers also required our staff to maintain them and transport backups to an off-site location on a daily basis. Capital costs were running too high. Most importantly, with no 24-7 on-site staff to troubleshoot server crashes, our European employees and partners had no access to the system during their working hours.

"How would you approach this if you were starting from scratch today?"

"Well, I'd have our servers moved to a co-location facility with guaranteed power, 24x7 staff, and have them do the backups."

"Why don't we go ahead and make the change then?"

Nobody could think of a good reason not to make the change, so we went ahead. The switch to co-located servers solved some of our problems, but not all of them. And new issues arose. Scaling on demand was unavailable due to hardware constraints and custom software design. It still took months to requisition, configure, and put new servers into production.

Once again I asked, "How would you approach this if you were starting from scratch today?"

"Well, I'd go with virtual servers instead of our own co-located ones."

"Why don't we go ahead and make the change then?"

This time, staff came up with legitimate reasons why we couldn't just toss our existing servers and move to a virtual infrastructure. It was simply too costly to terminate co-location contracts with external vendors. It also meant we would have to rewrite all our applications to make them work in a virtual environment. Still, we decided to use the then fledging virtual private server technology for our new projects. We achieved mixed results. While we could spin up a physical server in an instant, it would be unprovisioned with our environment, and required middleware and heavy-duty IT involvement to make it work. Development, staging, and production environments were not identical, which resulted in many errors.

"How would you approach this if you were starting from scratch today?"

Silence.

In reality, there was no good solution to the problem at the time. At least until the private Platform as a Service (PasS) came along.

Private Platform as a Service: Opening the Path for Innovation
In the last six to eighteen months, the advent of viable enterprise private PaaS products has significantly changed the IT landscape. PaaS guarantees an identical environment throughout the development and deployment cycles, can handle any language, and is automatically configured and scaled on demand without IT intervention. PaaS effectively removes all the barriers that delay project rollouts, and allows staff to focus on real business problems rather than waste time fixing the IT infrastructure. With PaaS, innovation becomes possible.

Technology changes so rapidly that a business will be left behind if it does not constantly consider newer and better ways of doing things. Innovation starts with asking the right questions. When reviewing legacy systems and practices, ask your team, “How would you approach this if you were starting from scratch today?” The Japanese taught us that a frog in a well does not know the great sea. Chances are that if you are not thinking out of the box, looking ahead, and making continuous advancements, your competitors will. And it may take you years to catch up if you miss the boat.