Oh Yeah!!! I mean OUYA!!!

Tech blogs and sites are talking about OUYA. OUYA is not a gaming console for the Kindle Fire or the Droid Razr but rather for the “old school” screen, the television. My research shows that OUYA is composed of a slick cube shaped console and a controller.  

OUYA's application programming interface (API) and its documentation, which are accessible via the OUYA website, show that the API clean and lightweight. The system is written on the Google’s Android OS which is written in Java. The OUYA API consists of six Java classes and it looks like the developers will have to develop interfaces on how they want the OUYA console to interface with their games. It’s a smart approach. The responsibility on how a game should interface with the OUYA is on the developers and not on the OUYA staff.

What does this mean for the gaming companies? The companies like ZYNGA and EA will need to have resources who will code the OUYA functionality for all of their games. The companies would also need to host their games. Can we repeat the words, “CLOUD COMPUTING” (again).  

What does the OUYA platform mean for customers? This approach is truly disruptive. This opens up the platform for traditional Java developers like me which in turn means more games will be developed.  

What does the OUYA platform mean for the business world? Businesses can now buy services where specific games can be built for their business needs. Game based learning is rapidly evolving into the main stream business. For instance the Federal Aviation Administration (FAA) is currently exploring games to train the next generation of Air Traffic Controllers. With a platform like OUYA, FAA can develop games a lot less cost since Java developers are not that expensive and publish these games to train new Air Traffic Controllers or even get a high school age person interested in managing air traffic.  

Even though the possibilities of OUYA are great, I worry about the security threats with a platform like OUYA. OUYA security access controls are based on its open source Android operating system (OS) and stores like Google Play don’t test the games for malicious code. Unless this policy has recently changed, OUYA may not be adopted by large organizations. If OUYA can provide a secure app store, OUYA’s potential is quite high otherwise it’s to be determined (TBD).  

In closing I will know that OUYA is successful when Stuart Scott to say “OUYA” rather than “Boo Yah” on ESPN SportsCenter.  Here is also a video I found on the OUYA website.

Marketing and Technical refresh

What happens when a services oriented company tries to get into a product business? It's not a great model. When I was employed by Northrop Grumman, I worked on the Grants.gov project.

This eGov program enabled grant seekers to fill out an XML based form and then submit it via the grants.gov website. The XML form in-turn was transformed to an XML instance and then processed through a propitiatory Northrop Grumman XML transformation engine.

Have you ever heard of this product? I don't even remember the product's name! This was in 2004. The product was a suite of open source java packages which were cobbled together to be a backend engine for a major eGov program.

I left Northrop Grumman to work as a J2EE programmer for a company called Conquest Systems. I worked on a great team with sharp engineers and a great a project manager. We built a resource management web application using Struts and Hibernate with an Oracle database in the backend. This application for was the US military with a small development and support team. Meanwhile the company spent a lot of time developing a visual analytics tool for another US Government agency. The agency allowed Conquest Systems to take the rights of the products. Unfortunately, the company is still struggling to make it big with this product. The product uses EJBs. I also heard rumors that the app server ran on vacuum tubes.

Now at my current employer, I see every small and big company trying to sell COTS product. Half of them are useless since it doesn't meet our requirements while the others are not enterprise enough.

What seems to be the underlying problem? The problem is that service companies, especially public sector centric companies, tend to spend more time creating the product for a client and are not geared to market the product or give it enhancements to keep it technically fresh. This was recognized by my esteemed colleague Gene Gotimer a few years ago.

The other major problem I see is that companies that want to build cool products rely on open source products. The initial cost is minimal, however a great price is paid to have smaller iterations of technology upgrade. How many products that you know of, which are built on Microsoft, IBM, SAP or a major vendor's infrastructure, have disappeared from the face of the earth? Not many, but you have to upgrade your product technology stack, otherwise you may end up with a robust Microsoft Visual FoxPro application. How many of you have worked on FoxPro? If you did then you must have had a mullet in the 80's.

The beauty of the cloud technology is that it will force companies to keep up with the technology upgrade otherwise the cloud provider may not support that old FoxPro app. Does Amazon EC2 support FoxPro? I didn't think so. Back to the mullet issue, just kidding. The cloud computing technology model may actually assist the services centric vendor to build boutique products. If it becomes a popular product then the cloud vendor may buy it from you. If that happens then you can be proud that you are now trading your keyboard for some car keys. Car keys to your brand new Ferrari. At least that is what every caffeinated developer dreams about. ;-)

I sound like a left wing donkey (aka Democrat)

I asked myself, "Will open source technologies ever fly?" after reading this article "Google asks US Patent Office Oracle Java patents". As businesses try to make a dollar or two from innovative minds who donated their "code" to better of man kind, I wonder if my children will enjoy the benefits of open source technologies. I don't know the answer but one of way of safe guarding these open source technologies is let government agencies take over the maintenance of open source software. I realize that I sound like a left wing "donkey" (aka. Democrat) but the open source community needs to address the bigger problem. How can brilliant works of engineering like Java, Ruby on Rails, Linux, Hadoop can be safe guarded from the hoards of entrepreneurs? I don't have a problem if a company like Cloudera and RedHat who make a living on supporting open source software. I however question when businesses fight the over basic fabric of open source software. Here is one idea we can look at:

• Apache and other open source organizations should be care takers of open source. These organization should be funded by government agencies and they should be regulated by a UN organization.

My right wing friends may ask the question, "why should the government get involved in managing open source technologies. I answer by saying do you want human safety compromised over a business indicator flashing red. Since IT is being used to track and guide flights, manage energy grids, and control access to vital information, I say the government should be responsible for managing open source technologies. Government has so much red tape that it reduces efficiencies but the red tape also safeguards the things under its control from the economic and political moods.

Frankly if things don't change then I will start working Objective C, C#, and reduce my investment as a developer on open source technologies.

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.