As a project manager, you’ve often heard of .NET, but you may not have had an opportunity to work on a .NET project since the strategy is relatively new. I've found that companies aren't exactly jumping over hurdles to migrate to .NET—at least not yet. The .NET Framework is still viewed by many as an early adopters’ platform and the industry needs more time. But, as the economy improves and IT budgets are kicked back into high gear, I’m confident that there will be a rise in .NET projects.
What is .NET?
.NET is essentially a set of software technologies designed to connect your world of information, people, systems, and devices. Therefore it’s an environment for building, deploying, and running Windows applications and services. A fundamental idea behind .NET development is the idea of common objects—objects that are accessible anywhere, anytime, and from any device. Also, .NET technology itself is based on XML Web services, which use standard protocols such as SOAP and XML data to connect applications and Web services.
What types of projects or solutions can you specifically build with .NET? For starters, you can start building Web sites using ASP.NET and also legacy Windows applications written in VB and Visual C++. Everything boils down to the .NET Framework. That’s an integral Windows component that supports building and running the next generation of applications and XML Web services. As such, .NET enables project teams to build Web-based platforms of services with a level of functionality more commonly associated with line-of-business applications than with traditional Web sites or Web-based applications. .NET enables a high level of software integration through the use of XML Web services—small, discrete, building-block applications that connect to each other as well as to other, larger applications over the Internet. What .NET really brings to the table is an elusive but important component of technology integration—speed.
By eliminating technology barriers with .NET technology, I believe organizations should see good returns on their IT investment, and this issue should be emphasized in the business case or ROI document developed by the project manager. But, let’s face it, not all legacy applications need to be ported over to .NET. I interviewed a number of executives who all have mixed feelings about .NET at this stage of the game. Some slam .NET for the following reasons: (1) it is too new, (2) a new language demands new skills, (3) it needs a complete new runtime and development environment, etc. As Carl Massien, a senior developer working on large enterprise app projects, said, “.NET is for new development, and for those apps that can justify the time and expense required to refactor them. I just don’t see a business case for it.” Similarly, another vocal opinion was, “As a developer, the real learning curve, no matter which path you take, will be the .NET Framework. It is a killer!” However, on a more positive note, many had already spent money on training and certifying their developers and were already engaged in turnkey .NET projects.
Project approach to .NET
I think the biggest challenge any project manager will have on .NET projects will be to attract the talent. .NET projects are a different animal, so you can't do things as you used to do them. As a project manager, you’ll need to bring on IT people who know how to architect and build .NET solutions. That probably means a few senior consultants, so it won't be cheap and you’ll have to budget for such resources. Just make sure that part of their task is to educate your (senior) in-house people. It is equally important to get upper management on board. To do that, I'd recommend you try a few pilot .NET projects. Make sure you pick a project that isn't so small that success is seen as no big deal. But, don't pick a project that’s too big either.
The composition of .NET
As Figure A shows, the .NET Framework is built from three core layers to support Web services for developers and users. The .NET Framework also makes applications easy to maintain, and reduces upgrade time, making it a good candidate for those companies that constantly upgrade their Web site(s). The core layers are:
- Common Language RunTime (CLR): This is basically the execution engine for .NET applications. It was designed with simpler and faster development in mind. It provides many services, such as: code management, exception handling, and memory management, which all support the Common Type System (CTS) for integrating multiple languages. Debuggers and wizards are also found in this layer. In Figure A, CTS stands out as being able to integrate multiple development languages such as C#, VB.NET, and C++.NET. Lastly, the CLS function is pretty cool since it allows developers to use other developers’ code (i.e., language interoperability).
- .NET Framework Class Library: This includes base classes covering areas such as security, the Web, XML, I/O, messaging, and configuration. It basically brings all APIs together into one library, which is universally available to your team.
- User and program interface/technologies: This is the topmost layer and contains program and user interfaces, including ASP.NET and Windows Forms. The ASP.NET piece provides a low-level development model for building Web services or Web apps. Additionally, by using Windows forms, project teams can also create standard Win32 desktop applications in a drag-and-drop GUI environment.
|The .NET Framework is built from three layers to support Web services.|
Understanding the .NET protocols—a key to project success
When managing .NET projects, chances are that you’re going to come across some specs or protocols, which I think are important to understand when working with your development team. They are:
- Disco: The Discovery (or Disco) protocol helps developers automatically determine what services and features are provided in a Web service. It defines both a discovery format based on XML and a protocol for retrieving that discovery document. The thing to remember is that Disco has to have a known URL to search for services.
- SOAP: The Simple Object Access Protocol (SOAP) is basically there for information exchange. Its specs define an extensible message format and binds to the HTTP protocol.
- WSDL: Web Services Description Language (WSDL) is an extensible service description language that is often used. It’s really an XML-based contract language.
- UDDI: Universal Description, Discovery, and Integration (UDDI) was created specifically as a way to discover service providers, without knowing the URL.
- XML: This is the most basic of them all; it’s the widely used standard for representing data over the Web and is the glue that secures the .NET Framework. Many Web services use XML in schemas to describe their data types.
Who’s using .NET?
Clients agree. There does seem to be a place for .NET and there are quite a few success stories. Sure, .NET is in transition and full implementation will take time, but take a look at what these clients did:
- Honeywell coded its solution in four weeks. It finished its project in 10 weeks, and came in under budget, thanks in part to Visual Studio .NET development and debugging tools, which shaved crucial hours off the final timeline.
- Telenor got eChannel up and running in three months using .NET, and the project came in under budget. The company figures alternative integration methods would have taken at least twice as long.
- The Central Bank of Costa Rica recently completed a successful migration of a turnkey payment system to .NET technologies. One of the keys to the success of this project is that it does not have to rebuild existing systems. The system is designed to benefit Costa Rica’s money market, eliminating technological boundaries and enabling it to be more agile. They were able to migrate over 1.3 million lines of code from previous Microsoft COM-based technology to .NET. It’s become one of the biggest .NET deployments of a core mission-critical application worldwide.
Early adopters of .NET have pushed out some initial project successes. My message to project managers right now is to start becoming familiar with .NET technologies because .NET seems here to stay.