When you think about it, on-demand computing is really just another name for time-sharing; the venerable model of the pre-microcomputer computing age.
In those old days (which frankly were before my time in IT), tens, hundreds, even thousands of people shared a single mainframe computer which might be located hundreds of miles away. Commercially pioneered by the airlines who had to maintain very complex schedules in a dispersed geography, timesharing retreated to the language graveyard as other newer terms replaced it.
We moved from centralized processing and data to completely distributed processing and data, embodied by the microcomputer in the early and mid '80s, then to the distributed processing and centralized data storage of the "LAN Age" of the late '80s and mid '90s.
We are now realizing that distributed computing is expensive to maintain and support, and all of a sudden we're back to a centralized model.
The concept of service oriented architecture (SOA) may be a new concept if you discount that it may also be viewed as a called subroutine from the old mainframe days, but that's a stretch, so maybe there are new concepts and ideas floating around.
Yet in my work within the truly "commercial" marketplace, I find that most companies are no where near the cutting edge of technology, and focusing on making things work well and adding value to the organization continue to be the focus of most IT organizations.
So what does this all mean to the CIO of a company today? I think there are several lessons to be learned:
Don't be too quick to embrace the latest and greatest . Sure there are some very cool products on the cutting edge, but if you've been around for a while, you'll remember OS/2 or Turbo Pascal, or a myriad of other solutions, systems software, architectures or other components of the IT arena.
Some survived, others burned brightly for a while and, like a skyrocket, soon fizzled out. If you've read Nicholas Carr's controversial articles or books you know that he feels that IT provides a fleeting competitive advantage and is soon equaled by your competitors. So there's that delicate tension between embracing new technologies and achieving a fleeting competitive advantage, or waiting a while and minimizing risk.
You must always balance these two competing forces.
Spend a bit of time learning every new technology personally. Reading about the latest technology is one thing, but working with it a bit is something completely different.
Now it's not possible to come up to speed in great detail on many new technologies, but at some level it's important that you actually put your hands on the technology and understand it personally, otherwise you run the risk of having to totally rely on others in your organization.
Unless you're ready to bet your career and your company on their opinion, you should be able to add your own judgment; and that must come from empirical evidence, not the opinions of others
Insure your budget has an R&D component. We are in a fast changing environment, and unless your radar is constantly running, you risk a collision or missing something important. That radar must be constantly funded, for both "skunk works" projects and a dedicated research component.
How can you fully evaluate some of the new technologies unless you have a mechanism to evaluate them. This could include not only the technical R&D, but should also include the discipline to build the business cases necessary to justify moving technologies from R&D to a position where they can add value to your business.
This is not only technology research directly focused on the business, but don't forget that you're also part of the business, so start researching new methodologies, new research methods, and new ways to measure ROI.
Faith is good, but skepticism is just as valuable. The best way to develop a healthy dose of skepticism is to research some of the older technologies and see where they went.
Spend time asking your staff where they think things are going. Discuss technology with your younger staff, particularly those who are right out of college. They'll know the best in academic thinking, which may, or may not, have value in your organization. Either way, they will have some interesting ideas which are worth exploring, particularly about newer languages, methodologies and tools.
Most of the major vendors invest heavily in the academic environment so most of the students just out of school will have had access to the "latest and greatest." Unfortunately this exposure is mostly limited to development tools and languages. There is a dearth of experience in commercial applications, particularly the core business applications which run most businesses today.
I wish major universities would spend time teaching the intricacies of ERP or CRM in addition to the latest Java data structures.
Triangulate every vendor claim. There is nothing better than spending lunch with competing vendors asking casually about the claims made by their competitors. Every vendor is more than willing to assess the truth of their brethren's claims.
Triangulation is a navigational term used when you're measuring several points and seeing where they intersect. It's not a bad thing to do with vendor claims.
Hire a good research service and use it religiously. There are a number of good services available who spend literally millions of dollars researching the claims of technology companies. Their analysts have access to the management of companies, to the future roadmaps of the companies, and spend time assessing very narrow ranges of technologies.
You must chose your research service carefully to insure that they are not paid by companies they are researching however. You should ask them what percentage of their revenue comes from companies they review. This should be part of every IT budget.
Daniel Gingras has been CIO of five major companies and is a partner at Tatum Partners, a nationwide professional services organization of senior-level technology and financial executives who take on leadership roles for client companies. He has more than 30 years of IT experience and teaches computer science at Boston University. He can be reached at firstname.lastname@example.org