Using ASP.NET 2.0 to Streamline Web Application Development

Technical Case Study

Published: March 15, 2006

The HRIT group in Microsoft Information Technology (Microsoft IT) wanted to reduce developmental inefficiencies in the Web application space at HRIT and, at the same time, enforce a standard look and behavior for new Web applications being developed. The solution that the HRIT group created may help other organizations build Web-based solutions by using the new functionality of ASP.NET 2.0. This case study is intended for chief information officers, technical decision makers, and business decision makers who need to create Web-based applications with an organization-wide look and behavior that also provide single-source core functionality for Web-based applications.

Background

Microsoft has about 65,000 employees and has a dedicated Human Resources (HR) department of about 1,100 staff members to help administer and deliver HR functionality to its employees. The HR department is responsible for setting strategies to identify, acquire, develop, and retain top talent that will enhance organizational performance. To support the HR organization, the HRIT group maintains one primary employee-facing Web portal, in addition to 70 other HR applications.

Situation

The HR organization at Microsoft needed a new application to enable delivery of richer career and talent management discussions through the capture of key attributes by and for an employee. Talent management is a key goal at Microsoft with the following closely related HR functions:

• Staffing. Hiring of the best candidate for an open position.
• Performance management. Evaluation of employees based on their past performance.
• Talent management.Assessment of employees' competencies, and career development planning.

Talent management requires knowledge of an employee's competencies, experience, aspirations, and potential. Previously, HR staff members entered these personal competencies into a variety of tools that were not integrated with one another. For example, the Mid-Year Career Discussion includes some talent management information, but that information is stored in separate Microsoft Word documents for each employee. Therefore, managers have not been able to easily review the talent profile of their entire teams.

At the same time that one team within HRIT was reviewing the requirements for the new employee talent management application, another team within HRIT was reviewing the efficiency and consistency of applications in the HRIT application space. Microsoft HR uses a variety of Web-based applications to conduct its business. These applications, built through Active Server Pages (ASP) and ASP.NET, were developed separately by different teams within the HRIT group. No clearly defined organizational directive was in place to define application architecture and design. Also, these applications were developed over a period of many years. Therefore, no consistent UI or structure existed between these applications.

Because new users could not use their knowledge of one application to run other applications, HRIT experienced increased costs to train users to use newly developed applications. Also, because no application standards existed, application development was not performed as efficiently as possible. Both of the following situations existed within HRIT:

• Code duplication. Developers created duplicate code between applications, solving problems that had already been solved in other applications.
• Inconsistent UIs. Developers spent time creating new UIs instead of taking advantage of existing UIs from other applications.

Because of this lack of a standardized architecture and design between applications, HRIT experienced increased costs in application maintenance. For example, HRIT recently spent several thousand dollars over a three-month period to update the privacy statements throughout the HRIT application space. This lack of standardization did not only cost HRIT monetarily, but also in lost productivity. Developers from each team in HRIT had to put other projects on hold while they updated these privacy statements. HRIT estimated that if the current HR applications had been built on a standardized template, the time to update the privacy statement could have been reduced to only an hour or two.

Formerly, HRIT used ASP and ASP.NET version 1.x to create a uniform look and behavior within each application. By using ASP, HRIT developers could use server-side includes (SSIs), ASP directives that include the contents of a different file at the point in the page where the directive is written. HRIT developers found this approach less efficient than they wanted because development systems such as Microsoft Visual Studio® do not recognize the included contents. Therefore, developers had to run the code to view the page layout. Also, the included code was not integrated with the containing code and could not interact with it.

By using ASP.NET 1.x, developers could create user controls to obtain a uniform look and behavior within each application. This method involved the HRIT developers creating user controls for each region of a page that they wanted to be uniform throughout the application, and then adding those controls to each page file. They registered each control on the page and then declared that control. HRIT found this technique to have advantages over ASP. However, the HRIT developers still experienced significant difficulties with this approach. Chief among these difficulties was that HRIT had no single recommended method to implement this model. Therefore, different applications could have significantly different implementations. HRIT therefore could not easily enforce design standards between applications. This lack of design standards increased the time spent in maintaining applications in the HRIT application space.

In addition, because no easily enforced design standards existed in the HRIT application space, core functionalities such as an e-mail service or security mechanisms were duplicated between applications. HRIT developers spent time solving problems that had already been addressed in other applications instead of working on the unique functionality of their application.

Solution

To address its application-creation issues, the architecture team within HRIT, which has a cross-HRIT focus, developed a shell application called Shell Assemblies. The HRIT architecture team developed the application to provide core functionality and to act as a template application that other HRIT teams could use during the development of HRIT Web applications.

At the same time, another team within HRIT started the development of the CareerCompass application. CareerCompass is intended to provide a single, flexible, Web-based solution to help gather and assess employee talent information for Microsoft HR.

Because both of these application developments began at the same time, and because both development teams had the common goal of creating efficient, standardized, and reusable code, both development teams worked closely together throughout the development process.

Shell Assemblies

The HRIT architecture team determined that it could use the master pages available in ASP.NET 2.0 (described in the "Master Pages" section later in this paper) to create a shell application on which to base all new Web applications in the HRIT application space.

The HRIT architecture team did not intend the development of the Shell Assemblies application to generate an immediate cost savings to the HRIT group. However, by basing future Web applications on the Shell Assemblies application, HRIT would save a considerable amount of money in development costs, as well as in future training costs for those applications. By using ASP.NET 2.0 master pages to create a shared solution that other application developers could take advantage of, the HRIT architecture team considered that developers could reuse all the following core functionalities (or assets):

Shell

Portal

Global navigation controls

Secondary navigation controls

Contextual content

Intra-application task management

Inter-application task management

Application profile

Roles

Additionally, developers could reuse the following secondary functionalities:

Employee profile

Application support

Security auditing

The HRIT architecture team divided the typical HR Web application architecture into separate modules to help identify where development time was spent. Figure 1 shows this architectural breakdown.

Figure 1. Development time for HR Web applications

The development of the Shell Assemblies application took a team of two developers two and a half months to complete. The HRIT architecture team calculated the following savings percentages in application development times that the Shell Assemblies application has made possible through code reuse and standardization:

UI component: 6 percent

Application layer: 3 percent

Services: 12 to 13 percent

These percentages give HRIT an approximate savings of 21 percent in development costs for each Web application that uses the Shell Assemblies application. Additionally, by basing future Web applications on Shell Assemblies, HRIT developers can easily comply with organization-wide look-and-behavior requirements, and capitalize on core functionality that the shell provides to all applications. Developers can focus their time and effort on the specific business needs of an application instead of having to re-create code.

"ASP.NET 2.0 enabled us to easily create an application framework consumed in parallel by multiple project teams. Building master pages once and encapsulating common branding and navigation helped us to standardize the user experience while simplifying our code base." Gaylon A. Blank Application Architect Microsoft IT Microsoft Corporation

HRIT will experience additional savings because of the centralized management of the reusable assets that the Shell Assemblies application includes. For example, by including the legal disclaimer in the Shell Assemblies application, HRIT will save several thousand dollars in development costs if this disclaimer requires updating. Instead of having to update each individual Web application, HRIT must update only Shell Assemblies to have the legal disclaimer updated on every Web application that is based on Shell Assemblies. The foundation of the shell itself is the master pages available in ASP.NET 2.0.

Master Pages

ASP.NET 2.0 supports a powerful new feature, called master pages, for applying standard visual and functional capabilities throughout a Web-based application or across many such applications.

Master pages work in conjunction with ASP.NET 2.0 content pages. A master page contains standard HTML tags and ASP directives. A master page also contains one or more content placeholder tags that specify regions on the page that content pages will populate. For example, a master page may define a header and a footer, whereas a content page may define the main region of the page.

The following tag shows a content placeholder in a master page.

<asp:contentplaceholder id="ShellContentPlaceHolder" runat="server"/>

The following tag shows content in a content page; the content tag specifies the placeholder where its content should be displayed.

<asp:content id="Content1" contentplaceholderid="ShellContentPlaceHolder" runat="server">

This is the content

</asp:content>

A master page exposes properties and methods that content pages can call, so that the two sources can interact to produce the final page. For example, a content page can supply its own text for a particular label in the master page, or it can turn "bread-crumb" navigation links on or off.

A major advantage of master pages is the separation of code from data. Master pages give the HRIT architecture team easier and better separation than ASP or ASP.NET 1.x. The basic functionality that any HR application requires is created by software developers and compiled into a library. Web developers use this compiled library as part of the application they are developing. The Web developers can then focus on the unique requirements of their specific application.

Shell Assemblies includes three master pages:

The shell master page defines the layout of the entire application window. It provides a header, a footer, and a left navigation bar, while reserving the bulk of the screen for content pages. Content pages interact with this master page to create the final appearance and functionality of an application. For example, content pages define the text and targets of the items in the navigation bar, whereas the master page provides the code that renders the navigation links and carries out the actual navigation to the targets.

The dialog master page is used by content pages that are dialog boxes, such as About, Default Error, Feedback, Legal Statement, and Privacy Statement dialog boxes.

The Help master page is used for customized Help for an application.

The technique of using master pages offers immediate benefits to an application, in ease of development and ease of maintaining a standard look and behavior across all of the pages in the application. The HRIT architecture team went one step further by mandating a common look and behavior for all of its applications, and the technique of using master pages makes it very easy to comply with that mandate as well. Figure 2 shows the Shell Assemblies application.

Figure 2. Shell Assemblies application

ASP.NET 2.0 supports nesting master pages. Shell Assemblies itself does not nest any master pages, but an application can create its own master page and nest that within the shell master page. An application might do this to further separate functional code from business data.

Configuration Files

An application customizes the appearance and behavior of the Shell Assemblies components by using XML-based configuration files. In addition to the standard ASP file, named Web.config, Shell Assemblies uses a file named Shell.config.

Web.config contains application-specific information that is not likely to change over time, such as a tag indicating whether the application uses Shell Assemblies. It also contains a reference to the Shell.config file, which allows the application to locate that file.

Shell.config contains the metadata to drive the user experience of the application. Tags in this file define application-specific data that the shell master pages will use. The tags are as granular as possible so that the application can customize its use of Shell Assemblies without requiring the Shell Assemblies team to modify the shell's code. This granularity contributes to the separation of code and business data. For example, the master page provides the functionality of logging errors, but the application can define specific error messages in the Shell.config file.

All of the configuration data in Shell.config can be in Web.config. Putting that data in Shell.config separates the metadata related to Shell Assemblies from the low-level application metadata that remains in Web.config. This separation also avoids the developer downtime caused by editing the Web.config file; when that file changes, the application must be closed and then started again for the changes to take effect. On the other hand, changes to Shell.config take effect as soon as the file is accessed.

Common Services

Shell Assemblies provides solutions for a variety of typical application requirements, such as the following:

State management

E-mail service

Exception logging

Performance logging

Security through roles-based permissions

Shell Assemblies also provides application blocks from the Microsoft Enterprise Library. Shell Assemblies provides these services as compiled code libraries, which are audited for security and then strongly signed. During a security audit of an application, the Enterprise Library blocks do not need to be audited again.

The Enterprise Library is a set of application blocks that provide standard solutions to programming problems, such as a data access block or a security block. The Enterprise Library is available on the Microsoft MSDN® Web site at and has been updated for the Microsoft .NET Framework version 2.0. For more information, visit the Microsoft patterns and practices site at http://msdn.microsoft.com/practices/.

Using the Enterprise Library application blocks has the advantage of using best-practice solutions, but the disadvantage is that the Enterprise Library is distributed as source code. When a security audit is performed, an application block in multiple applications must be audited separately for each application.

Shell Assemblies itself is available to applications as a compiled, signed library, to ease auditing.

The managed-code assemblies that compose Shell Assemblies and the Enterprise Library blocks can be deployed locally for each application, or they can be added to the managed-code Global Assembly Cache. An application might deploy the assemblies locally so that the specific versions of the assemblies that the application requires will always be available to it.

CareerCompass

The first application to use Shell Assemblies is named CareerCompass. The CareerCompass development team consisted of five developers who created this application in parallel with Shell Assemblies. CareerCompass is a single Web-based solution for gathering and assessing employee talent information. It enables self-service for both employees and managers to direct career paths, learning, and personal development, as well as to provide organizational capabilities. CareerCompass aggregates talent information at the employee level, the manager level, and the organization level within HRIT. All the information entered in CareerCompass is stored in the Microsoft SAP implementation. CareerCompass provides a real-time connection to SAP when users enter or review data.

The two development teams communicated frequently. The CareerCompass team developed functionality that turned out to be useful to other applications, and that functionality was migrated to Shell Assemblies. And as the Shell Assemblies team implemented new features, they were first used and evaluated by the CareerCompass team. In the future, application development will be easier and more streamlined because of the work that the two teams accomplished.

The CareerCompass team used Shell Assemblies to create and manage the look and behavior of the application. By doing so, the developers of CareerCompass spent their time creating the business code for the application rather than spending time duplicating the work of other developers. Figure 3 shows the CareerCompass UI based on the Shell Assemblies application.

"ASP.NET 2.0 enabled us to build rich, configurable, and scalable functionality in our environment. Plugging into Shell Assemblies allowed us to inherit approved branding and functionality, while letting us focus our efforts on application-specific components." Vidyuth Muthanna Development Manager Microsoft IT Microsoft Corporation

Figure 3. CareerCompass application

CareerCompass made use of the compiled shell library and various compiled Enterprise Library blocks. Using these compiled and signed code blocks reduced the amount of code that needed to be checked during the code security audit, enabling the auditors to focus only on the business-related code.

In addition to the Web.config and Shell.config files described earlier, CareerCompass uses a configuration file named Application.config. This file contains tags that specify constants and state management. For example, if a user is filling out a multiple-page wizard and clicks Cancel before completing the wizard, should the data entered so far be saved or discarded? A tag in Application.config specifies this behavior.

Benefits

The Shell Assemblies and CareerCompass development projects gave HRIT many immediate benefits, in addition to the overall long-term benefits that standardization and code reuse provide. Some of these benefits are:

Organization-wide adoption of a UI vision. A single UI can be enforced across the whole HRIT Web application space.

Overall reduction in development costs:

HRIT expects to save 3 to 5 percent in minor application updates.

HRIT expects to save 8 to 12 percent in major application updates.

HRIT expects to save 16 to 21 percent in complete application rewrites or in the development of new applications.

Compiled and signed shell libraries and Enterprise Library blocks that are included in Shell Assemblies do not have to undergo further security audits when a new application is created.

Increased efficiency through code reuse in master pages:

Bugs found in reusable assets can be fixed once and applied to all applicable applications.

Technical adoption of new features can be tested on one code base and applied to all applicable applications.

Service packs or hotfixes can be applied to the reusable asset and applied to all applicable applications.

Microsoft IT standards can be tested on the reusable asset and applied to all applicable applications.

More flexible application development:

Other applications can use reusable assets to interact with HR applications.

Developers can modify reusable assets without having to change all the applications that use them.

Application development that is based on Shell Assemblies can focus on the testing and modification of the non-reusable asset portion of the code.

By developing the CareerCompass application in conjunction with Shell Assemblies, the development teams could concentrate on the functionalities that best suited their individual applications. The Shell Assemblies team received feedback about features that should and should not be included in Shell Assemblies, and the CareerCompass team could focus on the solution to provide a central application for entering and evaluating data related to talent management. From a developer's point of view, Shell Assemblies benefited CareerCompass by freeing the application developers from coding infrastructure details and enabling them to spend their time coding the specific requirements of the CareerCompass application.

Conclusion

ASP.NET 2.0 master pages enabled HRIT to quickly and easily create a single application to not only enforce a standard look and behavior to all subsequent Web applications in the HRIT application space, but to maximize efficiency and reduce development and training costs for those applications. And by developing the Shell Assemblies application in conjunction with the CareerCompass employee talent application, two teams of developers at HRIT were able to fine-tune the development process to separate template code from application-specific code.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information on the World Wide Web, go to:

http://www.microsoft.com/

http://www.microsoft.com/technet/itshowcase/

© 2006 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, MSDN, and Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.