Prepare your analytical applications for earthshaking changes
A major geological change is in progress. You've felt the tremors, but you might not appreciate the magnitude of the upcoming event. Pay attention to the warning signs because the .NET shift is coming, and you're probably developing analytical applications today that will be obsolete tomorrow.
When designing an application, every software developer needs to decide how much time to spend planning for the future. Every time you develop an application, you have to choose how flexible to make the application so that you can adapt it to changing needs in subsequent revisions. If you want to make the application infinitely flexible, it will take an eternity to develop. If you solve only the business problem you face today, you might end up rewriting the whole application when the next problem crops up. My strategy is to build infrastructure for changes you can anticipate and use modular programming techniques to make isolating future problems easier.
You can prepare for .NET's upcoming changes now as you develop your current applications. Watch for these major changes over the next 12 to 18 months:
- .NET will be king of intercomponent communications, and COM will gradually go away.
- XML will be the format for storage and communications.
- XML for Analysis and ADOMD.NET will be the analytical programming interfaces of choice.
The final .NET shift will come in the commercial release of the next version of SQL Server, code-named Yukon. Preparing for these upcoming changes makes sense—and is less risky than continuing your current programming habits.
.NET Rules
Software development organizations have taken a while to realize what .NET's true benefits are. What's made this understanding particularly difficult is that .NET encompasses a collection of technologies, including XML, ASP.NET, C#, Visual Studio .NET, Simple Object Access Protocol (SOAP), and the Common Runtime Language (CLR). None of these technologies is particularly revolutionary by itself. But the sum of these technologies—and the programming approach that these technologies espouse—is what makes the .NET shift truly earthshaking. One piece of .NET brings most of the benefits: the .NET Framework. Built into this collection of programming interfaces is the ability to control Internet technologies such as XML, SOAP, Dynamic HTML (DHTML), and more.
The .NET Framework is language-independent, so Visual Basic .NET, C#, and Visual C++ .NET can all use the same interfaces. Language independence means that .NET has its own standard for intercomponent communications. Without .NET, when you want to access a Visual Basic (VB) software component from a C++ component, you use the component object model (COM). With .NET, COM isn't necessary. A common concern is whether .NET will make COM obsolete or will coexist with COM indefinitely. I believe that developers will use COM less frequently, but COM won't become obsolete for a while because of the vast amount of COM-based software in use. Even Microsoft will take some time to retrofit its existing applications to .NET. Microsoft recognizes that its customers can't simply rewrite everything to .NET. Every software release needs compelling new benefits to win customers, and the work that developers will have to do to make the .NET Framework part of their systems will include rewriting existing code. Rewriting code for its own sake isn't compelling, but exploiting the capabilities of .NET to bring new features to your customers is.
The fact that .NET isn't compatible with COM is a roadblock to seamless adaptation of .NET. You can call a COM application from .NET, but a native .NET application isn't necessarily compatible with an older COM version of the same application unless the .NET application was written to support COM. For example, if Microsoft changed its Office applications to .NET, existing third-party COM add-ins such as Hyperion's Essbase Spreadsheet, Business Objects BusinessQuery, or Business Reporter (which my company, ProClarity, produces) probably wouldn't be compatible. So, should a company release a version of its product that's half .NET and half COM? Should it develop a whole new product based on .NET? If so, how will the company make the new product COM-compatible? Every Windows software-development company will have to weigh these questions to decide how to move to .NET.
XML for Storage and Communications
XML is a proven technology. If you're not already using XML to develop new applications, you should be. My company is on its third generation of XML-based products, and I can't imagine going back to pre-XML technology. XML is an open-architecture format, which means it's easily integrated with other applications. Previous methods were platform-specific (e.g., limited to Windows or Intel platforms). And XML is a self-documenting, extensible format for storing or communicating data (i.e., passing structured data between software components such as Web services).
XML is verbose, so many developers have resisted using it. XML can use more than twice the storage space that binary data uses. XML requires parsing (interpretation), so reading it is slower than reading binary data. However, these limitations have largely been mitigated by compression and easily available, high-performance parsers. Compression techniques significantly reduce the size of XML when you transmit it over a network. Examples of currently available XML parsers are Microsoft's COM-based parser, which is named Microsoft XML Core Services (MSXML), and a public-domain parser called Simple API for XML (SAX). The .NET Framework also has a high-performance native XML parser. Because XML is a simple, standard, cross-platform, open-architecture format, its benefits far outweigh its limitations.
Choosing XML for Analysis and ADOMD.NET
Analysis application developers have to choose which programming interface to use and suffer the consequences—or reap the benefits—of that decision. Some third-party interfaces exist. For example, ProClarity's Analytic Platform and AlphaBlox's AlphaBlox are both third-party interface options. But the leading programming interface choices are ADO MD, XML for Analysis, and ADOMD.NET.