Need to have an exit strategy

I believe it is time for me to get out of the business of IT. Here are the reasons:

• Deer in headlights: I talk to some of my senior managers and they look at me as a deer in the headlights when I tell them about the innovations of Ruby on Rails or noSQL databases. On the other hand, if I was tell them about client server technologies of the late 1990s then we have a conversation. I see myself going down the same path in the next twenty years unless technology is outsourced.
  



• Outsource IT: This brings me to the second point. IT is so commoditized. Within a couple of years, I won't need to worry about the operations part since most of this will be outsourced. I heard of government agencies outsourcing the whole Blackberry program to a third party vendor. WHAT?!!! All those jobs! I know this is a big part of the whole world we live in. Do I want my job outsourced in the next five years? I don't think so.




• Open Source - innovating out of existence: As open source technologies rapidly evolve, more businesses are relying on market analysis and large vendors to recommend what their IT strategy should be. Should a CIO look at open source technologies to enable their IT strategy or look to proven technologies which could be legacy in the next five years? I would guess the latter. As Oracle, IBM, Microsoft and Google start putting cloud services, they are going to bring down costs and at the same time bring down the IT salaries. I believe the days of an Oracle DBA making a decent living are history. An Oracle DBA will make a similar salary as a typical engineer, which is 20% - 25% less then a typical IT staffer. These companies will also start filtering the Open Source technologies and the open source world will become an R&D lab. This is the best bet for any business since businesses don't have the time to update infrastructure every quarter.

What should I do then? I need to refine my customer relationship skills well enough to say, "Would you like fries with that?" ;-)

Can't Base Everything On...

I have been following Gartner and Forrester's research content on SOA, EA and other IT concepts from 2005 till present and I have learnt the following:

• Do not base ALL your IT decisions on Gartner and Forrester's predictions and recommendations. I have seen large IT companies make investments in technologies and products where the investments have not panned out because their IT environments are quite different. For instance SOA was the hype in 2005 however current Gartner analysts are saying that SOA simply doesn't work well in most IT environments. Research analysts tend to do that alot since they are reacting and analyzing current trends and make predictions and later contradict their predictions.
  
• Scope Best Practices and Products using Research. Rather than testing ten separate products for your certain IT requirements, you can choose the top five products as assessed by Research companies like Gartner and Forrester. Do assessments on the top five products and see how well they meet your IT requirements and how well do they perform in your IT environment.
• Use Research for Initial Business Justification. If you are looking to address a business problem and you want to follow Gartner or Forrester's recommendations then use their material to carefully craft a business justification on why you want to prototype their recommendation. Please keep in mind that you should address Return on Investment even if the recommendations don't work for IT enviroment.
• Engage these Research Companies. You want to market your IT strategy and progress then I highly recommend that you keep a lively engagement with the Research analysts where they will refine their research using your enviroment's results and at the same time they will give insight into current best practices. But be careful not to waste their time or yours by not having a detailed strategy on how you want to execute your vision and how you want to collaborate and market with these Research companies.
• MOST IMPORTANT: Consider the Research material however stick to your vision and requirements in executing your vision. Afterall you know the 50K feet view and the 1 inche view and therefore it is your responsiblity to execute it.

Good luck!

Software Language Roadmap

As many of you heard that Oracle is the process of purchasing Sun Microsystems (Sun) and many techies like myself are weary on what will ever happen to current IT standard technologies like Solaris OS, SPARC workstations, MySQL relational databases and most important to the Java Software language. Sun did a good job of maintaining the Java language which inturn has matured and is currently quite popular in the development community. I have to give kuddos to Sun where the language matured from a bulky and clunky language with Enterprise Java Beans (EJBs) to a more streamlined software language which has be refined to a fine consistency. I, however, think that the Java has reached its pinnacle and now it will slowly fade in the mist where other legacy buddies like COBOL, FORTRAN, PASCAL, LISP, etc, etc are waiting for it.

If you are a Chief Technology Officier (CTO) of any mid to large size enterprise, it is time to ask your planners to hash out a Software Language Roadmap which should address the following:

• What sorts of languages will peak in the next 2 years, 5 years and possible 10 years?
• What sorts of infrastructure will be needed to maintain applications with these languages?
• What will the cost of development of these applications?
• Will it impact current applications?

Enabling the IT component of business with Service Oriented Architecture (SOA) was promising since it offered a closer alignment to business processes, and the wonderful level of flexibility. Unfortunately flexibility brings numerous levels of abstraction and system integrators working with process analysts to develop these flexible services. During the enabling process, enterprises have realized that there is a cost associated to the degree of flexibility. Is flexibility worth the price? Next came the promise of Web 2.0! Web 1.0 allowed users to discover information using Web. Web 2.0 allows users to discover information and aggregate information for their personal uses. It also allowed users to disseminate their perspectives on the information (kinda like this blog). Enterprises see the promise however they are leary in giving their users the power to disseminate information with their perspectives across their networks. Currently businesses regulate their users on when and where they can blog if the users are allowed to blog. Currently the most promising thing Web 2.0 component in the business community is the Wiki. Wikis are usually viewed as organic knowledge bases which are maintained by the users. I personally don't see Blogs and Social Networks (sorry ASpace!) won't take off in an enterprise. So back to the drawing board and we need to ask ourselves, "What next?" As a developer and as an architect, I believe application development will be done in scripting languages like Ruby and Grails. They follow the concept that it takes alot less time to modify a baselined application then to build one from scratch. These languages also imply that these baselined applications have the right architectural foundations like built with design patterns, and loose coupling. They are script based language which allows developers to save alot time by skipping on the compile step. They also provide unit-testing capabilities. I have worked with Groovy on Grails quite a bit and I really like it. I am still learning Ruby. I also see close source companies like Microsoft and Adobe following this paradigm in their new ActionScript or .net specs. Every executive asks about security vulnerabilities with these languages and security is addressed as these languages mature. I wouldn't ask my developers to build my business applications in Groovy on Grails or on Ruby on Rails yet since they are still new but I would start drafting my java exit strategies. Don't let your enterprise get lost but plan your roadmap and stick to it.