Balancing the need to integrate new technology into a company’s infrastructure with the need to maintain existing systems based on older technology is one of the most difficult challenges for senior architects. With the introduction of the .NET platform, Microsoft made this job not only more rewarding but also significantly more challenging. But with adequate planning, .NET architects may ensure that their development teams create high-quality, supportable, and maintainable applications by making solid recommendations for creating or updating standards and processes that consider the advances in the .NET platform.

There are two major considerations for architects contemplating updating or creating their standards to accommodate .NET. Architects must consider how development standards should change and how to modify development processes to account for the new RAD capabilities of the platform and its requirements for development and deployment environments.

Development standards
The introduction of a new development platform carries with it the need to reevaluate existing development standards. But the .NET platform brings so many opportunities for new and exciting application types that you may need to make radical changes in your standards. Some areas will only need minor tweaking. For example, naming standards and conventions and documentation standards may not need to change much. But all new application development utilizing the .NET Framework will effectively view applications as an aggregation of loosely coupled components with well-conceived interfaces. Although many C++ developers won’t find this kind of thought process difficult, most VB.NET developers will. The discipline and knowledge required to develop classes appropriately will have to come from the .NET architect and not from the VB developer whose experience with classes has more to do with taking them than designing them. Developing an effective class design, integration, and naming strategy is essential to the success of new software initiatives based on .NET.

In addition, the new .NET security features force system architects to reexamine previous assumptions regarding security management issues. Like COM systems before it, .NET can use a single set of security credentials to control access not only to disk files and executables but also to database tables and stored procedures (using integrated security in SQL Server—the preferred security method in .NET). But .NET adds the ability to request or demand permissions for code to operate on system resources using code access security. In fact, .NET architects must consider how assembly management and application domains require them to reevaluate all of their current assumptions about managing trust boundaries within and between applications.

The other major standards area that architects must consider is data access. .NET applications using ADO.NET are more likely to be disconnected and stateless by nature, whereas COM applications based on ADO favor a highly connected, stateful environment. Development recommendations for handling concurrency issues using pessimistic locking simply cannot be implemented effectively in a .NET environment that favors optimistic concurrency. Architects need to establish standards and methods quickly for handling concurrency issues consistently across the enterprise.

Development process
Updated standards are not enough to ensure success when adopting the .NET platform. The RAD functionality enabled by the platform requires architects to reconsider the software design process and overall application life cycle management issues. When your developers use new .NET Framework features like DataSets, DataGrids, and the ASP.NET Design environment to create robust, almost deployable prototypes, then it is time to reexamine your software design process. VS.NET enables developers to use new methodologies like extreme programming to create new, full-featured, iterative releases of software systems at blinding speed (compared with the old tools). Given the proper guidance on maintaining the standards previously discussed, this results in quicker turnaround times and more feature-rich applications—as long as architects move fast enough to enable these new design processes.

In addition, I have seen a huge surge of interest in source code management and build systems based on Microsoft technologies. Once the forgotten stepchild, Visual SourceSafe appears to be coming back with a vengeance. Companies that have invested thousands of dollars in the VS.NET toolset are loath to invest even more money in a third-party source code management system. Many companies in the COM world ignored the need for shared source code because they followed the one-developer-per-project rule. But because of the highly reusable nature of components developed on the .NET platform, more applications are being developed using teams that create reusable components or subsystems rather than individuals developing isolated systems. These environments need effective source code management and the use of the source code system to be an integral part of the developing, building, and testing process.

Moving forward
The .NET Framework is a major shift from previous Microsoft development strategies. It requires both developers and system architects to step back and examine the details of their development process. The result of this process is architectural standards that allow everyone to be on the same page.