Microsoft

Consider licensing issues when architecting .NET solutions

When you design solution architectures, remember that you aren't operating in a vacuum. Keep these cost considerations in mind as you create the design for your application.


By Tim Landgrave

The rich facilities provided by Microsoft operating systems and application servers combined with the breadth of third-party tools available to system designers mean that we’re able to create and deploy higher quality solutions in a shorter amount of time on .NET than on any previous platform. However, software designers still need to make intelligent decisions about the features they choose to use, recognizing that there will be associated licensing costs. In fact, I spoke to one company that developed its application in record time but couldn’t afford to deploy it because of the high licensing costs for all the components and services they chose to use.

There are three key areas that you should examine for potential licensing costs when architecting your systems: Server licenses, third-party components, and Web services. Architects need to decide whether the time saved and the features are worth the cost of licensing third-party components when compared to designing, developing, and maintaining the facilities using their own development teams.

Remember the cost of server licensing
Building support for Active Directory (AD) into the core of the .NET Framework was not only a brilliant marketing move for Microsoft, but it also has the potential to save corporate developers thousands of dollars over the next several years. Why? Walk into any corporation today and you’ll find tens or hundreds of applications with their own custom-built user management systems and security management methodology. By using the built-in user management and security features AD provides, you stand to lower the overall operational costs of your solution, and you’ll be able to develop and deploy your applications faster. New .NET features such as code signing will make your apps more secure as well.

For organizations already deploying or planning to deploy AD, there is no additional licensing cost, so they’d be foolish to continue wasting money and time by developing custom user management schemes. However, if you work for a company that develops software for resale, you do have to consider the licensing impact using AD will have on your customers.

Coupled with AD, Microsoft’s SQL Server 2000 provides a robust, very secure, high-performance database on a Microsoft platform. So it’s likely that companies will continue to rely upon it for their database needs. One of the common misconceptions about SQL Server’s licensing scheme is that companies have to pay for licenses based only on the number of open connections rather than the number of system users. This is a common mistake made by system architects, but if you read the licensing agreement, you’ll see that you have to have a number of user licenses equal to the total number of users.

At $149 per seat, licensing by user could become prohibitively expensive when you’re talking about a Web site or a large corporation. Fortunately, Microsoft has a per-processor licensing scheme for SQL Server 2000, which is currently $5,000 per processor. At this price, SQL Server is still dramatically less expensive than DB2 or Oracle and outperforms both of them, according to the latest TPC-C benchmarks.

If you’re planning to develop solutions including e-mail, calendar, or workflow integration utilizing Microsoft Exchange or SharePoint Portal Server, you may want to take a long, hard look at the licensing terms for those products. Both of these products offer per-user pricing only, making it prohibitively expensive to use them in many solutions. Unfortunately, Microsoft doesn’t seem to understand that developers may want to extend solutions based on these products beyond their firewall and that the per-user pricing scheme makes it impossible to do so.

Using third-party components can be expensive as well
Although Microsoft provides a very rich set of services in the core .NET Framework, it doesn’t provide everything you’ll need. In many cases, developers still turn to third-party components to supply whatever functionality they find is missing from the Framework. These components are typically licensed in some combination of licenses per developer, per server, or per runtime seat.

Perhaps the best example of the need for third-party components is for reporting systems. Although Crystal Reports is included in the box with Visual Studio .NET, many developers have found deploying systems based on Crystal technology to be prohibitively expensive. There are licensing limits on the reporting system that ships with Visual Studio that many companies don’t discover until after they’ve already developed a system. Crystal requires a combination of per-developer and per-server charges that can dramatically increase the price of a solution that uses their technology. Don’t let this happen to you. Make sure you understand the deployment costs of a Crystal reporting solution before you decide to utilize Crystal Reports.

Charting and communications are other areas for which developers historically turn to third-party controls. Remember that each new component carries an associated license cost that should be considered in the overall cost of developing and deploying your solution. Shop around before deciding on a component: You may be surprised at what you’ll find available. For instance, ActiveReports from Data Dynamics is an excellent alternative to Crystal Reports that uses per-developer licensing and even lets you provide designer functionality to your end users as part of the core license.

Web services won't be free forever
Although they’re still in their infancy, you should expect to have a lot more opportunities over the coming months to include functionality provided by Web services vendors in your applications. I’m working with a company right now that’s implementing Microsoft’s MapPoint .NET Services for a location-based solution. The prevailing Web services licensing model right now is a per-transaction charge. Although companies will have to reexamine this model in order for Web services to become more widely used, architects implementing solutions today need to make sure they’ve budgeted for these fees as part of their solution’s cost.

That's the sound of money
The time to discover and disclose these licensing fees is during the architecture and planning phase, not during deployment. .NET Architects have more opportunities to use servers, components, and Web services to accelerate development than they’ve ever had before. But they also have more responsibility to deliver a solution that matches their functionality with the revenue or savings they provide.

Editor's Picks