It's cheaper, too. When you look at the cost of an application starting with the initial business, continuing on with development and deployment, and finishing up with maintenance and retirement, you find that design and development consume only about 20 percent of the total cost. When you look at the whole life cycle, maintenance makes up the vast majority of costs. Therefore, if you want to save the big bucks, it's the maintenance phase you want to look at.

Because these base classes and declarative programming reduce the number of lines of code to produce an application (yes, I know, LOC is not a very exact metric but it comes close) and because we no longer have to include custom-built plumbing in our applications, long-term maintenance will cost much less for .NET-based products simply because there is less to maintain.

Furthermore, maintaining the code base is easier because the code that does exist is weighted more toward the company's business requirements and less toward the intricacies of the plumbing-type support services that the base classes provide. Thus, years after an application has gone into production, a company will still have knowledge about these key business processes, and it will be relatively easy to ramp up a maintenance programmer to work on the project. Conversely, it would be more difficult for someone to understand (and then safely modify) the particular implementation of, say, a network library or some other functionality included in the Base Class Libraries that she or he is not familiar with.

Okay, we have covered a little bit of old ground here because you probably already know that Microsoft .NET is a good thing. The key point here is that you now have an easier time taking advantage of .NET because it is a standard part of the operating system. As more and more companies roll out new servers with Microsoft's latest operating system and still more companies upgrade existing servers, the importance of developers integrating the .NET Framework into the operating systems will increase according to Metcalfe's Law. Put differently, developers will experience a network effect as the value of this infrastructure dramatically increases because more people have access to it.

For Windows developers, Microsoft's increasing reliance on open standards when it develops new products and designs their underlying protocols and architectures will be the key driver that reduces our maintenance costs. Microsoft has always built products with standards in mind. With Microsoft Visual Studio .NET, however, they have taken this to a new level. Not only is Visual Studio itself built on open standards, but the applications you build with it adhere to them also. When combined with the Windows .NET Server 2003 baked-in support for Microsoft .NET-based applications, this support for open standards further drives down development and maintenance cost.

Think about the last few maintenance projects you have managed, been involved in, or observed. With the exception of releases targeted specifically at fixing bugs (and presumably there aren't too many pure bug-fix releases because eventually you either fix all the bugs or throw out the software), I'd bet that most of those projects have been related to integrating a handful of systems together or bringing a new system (or legacy system, depending on which side of the fence your application sits) into an existing environment.

The very nature of open standards makes integration easier. To see the effects of open standards (or lack there of) in action, compare e-mail and instant messaging (IM). Because e-mail has a set of well-defined standards (SMTP, POP, MIME, and so on), you don't need to worry what e-mail client your colleagues use or what network provider delivers their mail. You can confidently fire up Microsoft Outlook®, compose a message, and send it off and be assured that your colleagues will receive your message regardless of whether they also use Outlook or whetherthey use Lotus Notes or even an old text-based client such as Pine or Elm. Conversely, when you chose an IM client, you instantly limit the universe of people with whom you can exchange messages. If I want to send a message to a friend using MSN® Messenger (let alone open up a voice chat) who is still using AOL, I'm out of luck unless one of us installs a second IM client.

Open standards make communications easier between individuals, and the same reasoning applies to enterprise application integration (EAI). Although this statement is certainly true, it is a bit overly simplified; EAI is much more complex than simply sending a message between two people. However, rather than diminishing the value of open standards, these complexities make them even more important.
When you are sending an e-mail message, you are simply sending data. For an EAI "message," you need to not only send the data you want to share but also invoke some logic on the remote application-otherwise you are just doing data export and import. (Dutiful-or overly critical-readers will note that sending e-mail has implied remote logic-namely the "read this" method.) Besides these minimum requirements of a remote method call and corresponding data, in most cases you also need to include additional information such as the transactional context, a valid set of credentials for the target application, and so on. On top of this, you need to provide some level of orchestration that, among other things, routes the integration message to the proper destination, provides a monitoring and management layer, issues compensating transactions should the remote method call fail, and insures the privacy and integrity of the message along the way.

Traditionally, the approach to EAI has been to go in and kick off a maintenance mode project and extend the functionality of the target application so that it is aware of the other applications you want to integrate with it, and then add one-off implementations of all these additional layers to handle routing, monitoring, security, and so on-not once, but for each application! The problem with this solution is that if you have 10 applications, you end up with no less than 10 factorial (10!) hand-coded point-to-point integrations. You probably have to create each of these interfaces in proprietary development environments, so you cannot share skills across projects. Moreover, in a rather sick twist, each of the maintenance projects requires ongoing maintenance. Worse still, each application is tightly coupled to all the others, so the entire fabric is very fragile, with even small changes in one application cascading to the others

Alternatively, applications using open standards such as those targeting Windows .NET Server 2003 are much easier to integrate. First, because they are based on open standards, they are inherently less brittle because the key protocols and interfaces are defined by the standard. You can look at support for standards as a public interface in COM; you are free to change your implementation as long as you don't change the interface contract. However, with COM you can always introduce a change and then alter your public interface if you so choose. Not so with open standards: as soon as you stray from the documented standard and stop implementing its requirements, you are no longer standards-based.

This leads to the second benefit of open standards: standards-based products are more modular. (I can replace Eudora with Microsoft Outlook Express and continue receiving and reading new e-mail messages.) Therefore, integration becomes less point-to-point and you avoid the n! problem. You can develop a single integration component that can support multiple target applications as long as they have similar interfaces. Looking back at my e-mail example, imagine an SMTP-based integration layer with a single component that targets applications running Lotus Notes, Microsoft Exchange, or Novell® GroupWise®. Because they all support the SMTP standard, you don't have to develop a separate component to communicate with each of them. Granted, you would still have to do some development specific to each vendor's mail server to process the results, but you have still cut the work load in half because now you need to worry only about one side of the integration.

Finally, the use of standards enforces a common approach, so you are able to share resources across the applications rather than having to maintain different groups of people to work in each proprietary environment.

Out of the box, Windows .NET Server 2003 includes the .NET Framework and supports countless standards, including everything from XA for transactions to SNMP and WBEM monitoring and management (yes, it supports POP and SMTP for mail, too).

 

So far, I have intentionally left out one important topic of the discussion. Throughout the article, I have talked about the cost savings associated with the .NET Framework and the importance of open standards without saying the magic words that bring them together-XML Web services.

Most articles about Microsoft .NET and application integration start off talking about the wonders of XML Web services and how to build them. However, they rarely address the underlying approach that XML Web services take to solve the common business problem of maintaining and integrating applications. In other words, XML Web services are not, in themselves, the solution to this complex problem.. Rather, the solution is a decoupled, standards-based design. It just so happens that XML Web services represent a great-probably the best-implementation of this approach.

This leads me to my final reason that applications developed for Windows .NET Server 2003 will cost less over the lifetime of the project-the extensibility of the XML Web services model. Once you have developed an application and exposed its key functionality as an XML Web service, you can pretty much leave it alone. If you need to add or change functionality over time, you can easily do so without breaking anyone else by extending our existing application. In many cases, you won't have to touch the application at all because you can simply front-end your existing application with another one that provides a slightly modified behavior or aggregates several XML Web services and presents a single result to the end-user or application.

To summarize: The inclusion of the Microsoft .NET Framework in Windows .NET Server 2003 is a huge benefit because it dramatically reduces the total cost of your applications. At least, that's the line to give to your management. It's true, don't get me wrong, but the real benefit that you and I care about is that we can immediately start taking advantage of all the cool new functionality and productivity enhancements provided by the Microsoft .NET Framework. Better yet, because maintenance is so much easier, you can get out of those horrible assignments to update some awful application because "you are the only one who knows about it."

This month I start off my discussion of why the inclusion of the Microsoft .NET Framework in Windows .NET Server 2003 is so important. Because you can be assured it is always available, it will be easy to build and deploy Microsoft .NET-based applications. This leads to greatly reduced maintenance costs primarily because of the efficiencies afforded by the .NET Framework. In this article, I covered the importance of open standards and showed you how the Windows .NET Server 2003 reliance on open standards will make application integration significantly easier, further driving down the total cost of your applications. Finally, I talked about how XML Web services will change how we approach maintaining and integrating our applications.

To learn more about Microsoft Windows .NET Server 2003, your best bet is to pick up a copy of Introducing Microsoft Windows .Net Server 2003 by Jerry Honeycutt. Although this book is primarily directed at IT professionals, it is a critical read for developers. Not only does it cover the new management and monitoring features that IT pros will use to administer their applications, it also covers the key security changes in Windows .NET Server 2003 that will be of immediate value and importance to developers. It also includes a chapter on testing for application compatibility that will help you make sure your applications are Windows .NET Server 2003-ready.

For general information about .NET, refer to the following resources: