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.

It's cool like that!

For the last few days, I have been playing with Ruby and Groovy. I have to say it very exciting to play with these technologies. Like typical Java applications once you figure out how to configure the application, the development of these applications is very straightforward. I don't have have worry about compiling the files, generating a Web Application Archive (WAR), and deploying the WAR file on the servlet container. Ruby and Groovy for most part take care of this issue. From a software architecture perspective, these two technologies promote software best practices by having built in capabilities to design pattern.

The core philosophy is that it saves time by simply customizing a baselined web application rather than build each class, jsp and configuration file. I was amazed when I built a simple prototype in Ruby and Groovy. It is also takes less time to learn the technology because folks learn alot more when they plan with the code rather than reading a O'reilly book or a Recipe book. It's exciting!

The downsize is that it takes alot more time to understand how the code actually works since the inner working have been abstracted out. I also notice that I would use a standardized approach in naming methods, pages, and classes.

To increase my learning, I have been doing Groovy on JetBrains IntelliJ. It's great and it's better than eclipse. Enjoy!