Many of you might find this to be a funny question but almost daily I am asked, "what would you suggest as a platform for the development of XYZ Application --- .Net or Java?" or better yet "which one is better, .Net or Java?" Quite honestly, this is a loaded question and cannot be answered without significant analysis into both technical factors and a comprehensive review of the overall organization structure, existing investment, and review of why and what business problems XYZ application is being built to solve.

It is important to identify my skill set up front – I am on the business side of IT focusing on solutions and processes, which enable efficient, consumer-friendly government operations. As a result of my less technical perspective and background, I created a qualitative study for the CapTech technical brain trust to supply feedback to my review of this topic. As a fun experiment, I segregated the lines of communication between our Java and .Net development teams.

Although I was hoping our technical minds would take the bait and crank out prose on the benefits of .Net over Java and vice-versa – this was, in fact, not the case!

The overwhelming majority of CapTech respondents agreed that .Net and Java have similar tools, frameworks, and capabilities that can accomplish the same application outcomes. The consensus is that successful software delivery is a result of proper development methodology and not development language. This sentiment is best articulated by CapTech Managing Director and Sr. Architect, Doug Harvey, who wrote, "given two teams attacking the same goal with different vendor (or open-source) products, my money is on the team that uses solid design patterns, front-loaded testing methodology, continuous integration, and strong project management in a repeatable process."

My perspective is that software development decisions need to be made by analyzing the organization's capabilities, investments, and assets and by clearly defining the goals/objectives of the to be solution.

1. Skill Sets: The first place to start is to understand what skills does an organization have in place – are they moving from Mainframe to web-based applications, do they have skilled .Net or Java developers or do they have both? From the government perspective, IT staffs are usually too small to support Mainframe, Java and .Net based applications so it is should be a showstopper to acquire new skills or require significant re-training to begin developing in a language unfamiliar to the organization. If your organization is utilizing both Java and .Net it might make sense to begin to standardize to achieve significant economies of scale around the cost associated with maintenance, annual software service agreements, and decreasing staffing needs.

2. Existing Technology Investment: What investments have been made on software, hardware, etc…? Organizations need to constantly understand their state of technology – what capital investments have been made, what is reusable, are there existing frameworks that can be leveraged for other development initiatives, etc… There are many government agencies that have successfully created a standard development framework encompassing hardware, software, security models, etc… These frameworks need to be consistently maintained and updated to account for updates to technology and the organizations future strategic needs but, if properly executed, lay a foundation for reuse and define standards that have been proven to lower both your upfront development and long-term operational costs.

3. Solution Goals/Objectives: Java and .Net have capabilities to solve most, if not all, solution objectives but there are different costs associated with each potential development language. Since my perspective is derived mostly from the government arena, applications are often designed to interact with external stakeholders. It is often difficult to determine how many external users will adopt the system and at what frequency. I have seen instances where a great platform is built but the underlining licensing cost to expand to the external stakeholder community is cost prohibitive and in some cases impossible. These are cases when no one really thought about the adoption curve and the underlining objectives of the application being built.

This is not about what is so called the "best" but what is appropriate based on the overall business scenario of the organization. One comment from CapTech Architect, Phil Kedy, summed up my analysis "why don't you write about what is better - Vanilla or Chocolate Ice cream." His point is the most valid of all - This is a subjective argument on many levels. Java or .Net can both satisfy your needs from a purely technology position but your analysis must be indepth to derive an outcome worthy of your organization.