Last week, in the first part of this two-part series on .NET development issues, we reviewed the first two of four key prerequisites that developers identified as what they needed to begin application development for the .NET environment.
Before we continue our discussion of the final two of those needs, however, it’s important to clarify a few issues surrounding the choice of development language in the .NET environment.
Revisiting Step 2: Direction needed on preferred languages
In the first part of this series, I mentioned the issues relating to the use of Java, Visual Basic, and C# as core development languages. I didn’t point out that there are over 27 languages available from Microsoft and other vendors for .NET. This is important for two reasons. First, whether the language syntax that you’re most comfortable with is a common business language (like RPG or COBOL) or a more exotic educational or engineering language (like FORTRAN, PERL, Eiffel, APL, or Python), you can use that language to develop applications on the .NET Framework.
Second, language is truly a lifestyle choice and not a functionality choice. And the implications here are enormous. What it really means is that your company’s ability to create robust applications on the .NET platform has much more to do with developers’ ability to consume .NET Framework classes effectively rather than the language chosen to develop applications.
This leads us to the third key need identified by the developers, and one that is also a prime example of the importance of the framework vs. the language choice: Developers need help with database skills and XML integration.
Step 3: Need deeper understanding of DBMSs, key Internet standards
Most developers with whom I spoke expressed frustration with the speed at which their companies were moving to adopt new technologies like XML. The vast majority of applications that they were working on were still simple two-tier, synchronous applications with some business logic still trapped within the Oracle or SQL Server database.
Developers understand the value of using XML as a language to describe the data and operations that would flow between sets of presentation objects, business layer objects, data objects, and the underlying data stores. But they didn’t think the executive (and much of their technical) management understood the technologies. They even agreed that although they understood it empirically, they had no idea how to implement it effectively.
Enter .NET. Through the use of the .NET Framework, developers can use technologies like SOAP and XML to implement advanced, multitier systems that can communicate both within and outside of the firewall. But even though most of the actual low-level plumbing required to implement these systems exists in the .NET Framework, developers still need a deep understanding of not only existing database management systems like SQL Server and Oracle but also key Internet standards like XML, XSLT, XLANG, WSDL, DISCO, UDDI, etc. It’s much easier to understand implementation details, and the need for these standards, if developers implement a system incorporating these standards, rather than just reading about them in technical journals.
Step 4: Right pilot application must be selected
Choosing the most appropriate pilot application may ultimately determine how successful a development team will become with .NET. Many companies will approach this decision as dependent on whether they should write a new application or upgrade an existing one to run on the .NET platform.
Quite frankly, I see little value in simply taking an existing application and upgrading it to use the .NET platform without adding additional functionality. If the application is working and serving a purpose, then leave it alone. I recommend that those considering .NET choose to write a new application (or a new version of an old application) rather than trying to update an existing application. (This doesn’t mean that you have to have two sets of production systems, however. ASP and ASP.NET applications will coexist on the same server, and loading the .NET Framework on existing production servers in order to facilitate coexistence won’t adversely affect the existing servers.)
I also recommend that developers select an application that uses .NET capabilities to solve a real, existing business problem. For example, if your company is still struggling with the cost and difficulty of deploying rich client applications, then develop a new Windows forms application that highlights the touchless deployment capability of the .NET Framework. If you are in the middle of an enterprise application integration effort, or are still struggling to find an efficient way to allow internal applications to talk with partners’ applications outside the firewall, then develop a series of objects that expose internal business processes as Web services consumable by other internal or external systems.
The support for mobile devices in .NET also lets a company developing a WAP-, WHTML-, or Windows CE-based mobile application do so in a fraction of the time with much more capability than is available using existing tools.
Is it too soon to start now?
One thing I expected to hear from developers was that they weren’t going to get started until they saw a production release of the .NET Tools from Microsoft. Surprisingly, they felt that Microsoft’s distribution of Release Candidate 1 of the tools at the Microsoft Professional Developers Conference and at worldwide Developer Days events was sufficient proof that the code was stable and almost ready for final release.
Most are also aware that major sites like MSN and Microsoft.com are already live on the beta 2 version today. And although they weren’t necessarily ready to bring up any of their applications in .NET yet, most knew that Microsoft offered an ASP.NET Go Live licensing program that allowed them to bring up a finished .NET application.
Given the positive response about .NET from developers, I would expect that any CIO with Microsoft developers on staff should already have a plan in place to get ready for .NET. If not, it should be near the top of tomorrow’s to-do list.
Do you have a .NET plan in place?
Where is your development team in terms of .NET development? What hurdles are you dealing with? Write us and share your .NET development plans.