Do You Validate?

After completing the physical specifications for the solution, deployment, maintenance plan, and data model, you should verify that you met Microsoft standards.

Does Your Physical Design Meet the Business Requirements for PASS MADE?

In Chapter 4, "Gathering and Analyzing Operational and Infrastructure Requirements," you learned about the eight dimensions that Microsoft points out as key to any successful solution. To make them easier to remember, the acronym PASS MADE was assigned. In the following sections, review your proposed physical design and see whether it conforms to these requirements.

Does the Physical Design Support Your Performance Requirements?

Have you done all you can to increase overall performance of the application? Users will judge performance based on responsiveness.

To increase responsiveness, you should have performed the following (where applicable):

• Implemented caching so that controls and pages that don't constantly change are stored on the server. In this way, they don't have to be re-created each time the page or control is accessed.

• Turned ViewState off for those controls that do not use it or are not capable of using it, such as the data grid.

• Considered using asynchronous calls when applicable to give the appearance of immediate responses. A good example is the Windows No-Touch Deployment model.

• Created a database-indexing schema that increases speed for the majority of your queries by indexing key columns.

• Denormalized data when necessary to introduce redundancy; the result is faster data access queries.

Does the Physical Design Support Your Availability Requirements?

Have you guaranteed availability through best-practices design? Is the application reliable enough to be in a production environment?

To guarantee a production-worthy application, you should implement the following (where applicable):

• Auditing and logging routines should be used to scan for outages and failures so that they can be repaired.

• Exceptions should be caught and logged for later review so that errors are not overlooked.

• A service layer architecture design should be adopted to ensure proper coding practices through a multitier data flow design.

• Asynchronous calls should be used for long-running transactions and other actions requiring an extensive wait to ensure that the process will not be cancelled in the middle of a transfer.

Does the Physical Design Support Your Security Requirements?

Have you secured your application against interception of transfers and user attacks? Does the application pose any security threats to your network?

To limit the risk of a security breach, the following measures should be implemented:

• Authenticate users who attempt to access the solution so that they can be identified.

• Authorize access only to users who need the specific resource and deny all others.

• Encrypt data transfer through SSL when the data is being passed over HTTP. Encrypt sensitive query strings. Obscurity is not a replacement for security, so placing items such as query strings in hard-to-find places does not guarantee that they won't be found.

• Set up firewalls between each service layer and another between the interface and the user in a Web application. The UI and Business Service Layers will be in a DMZ.

Does the Physical Design Support Your Scalability Requirements?

What happens when you triple the load? You can prove scalability by performing load tests and identifying bottlenecks in the application.

The following items address the scalability of your solution:

• Server layers should be made in such a way that if you must run multiple versions of the same application, the service layers can handle handshakes and tradeoffs smoothly.

• Web farms should be used to provide added scalability to a Web application when applicable.

• ACID transactions should be used to prevent data corruption.

• The solution should be scalable to other platforms, if necessary, by exposing a service agent in the form of an XML Web Service.

Does the Physical Design Support Your Maintainability Requirements?

Have you met all maintenance objectives to ensure that the solution can be easily maintained after deployment?

The following items address the maintenance of your solution:

• Tracing enables you to view calls and debug information after the solution is deployed by using configuration settings in the Web.config file. Tracing has no impact on performance when stagnant.

• Exceptions should be caught and examined to verify that bugs have been fixed.

• Use WMI to monitor application and system performance.

Does the Physical Design Support Your Accessibility Requirements?

Have you met your accessibility requirements for all clients? Clients can be anyone who uses your software or consumes your objects.

The following items address the accessibility of your solution:

• Accessibility aids, such as text-to-speech or vice versa, should be used where applicable.

• Client configuration should be taken into consideration when implementing such items as state management solutions.

• A platform-independent service agent, such as an XML Web Service, should be implemented when applicable to expose logic to clients who consume your software.

Does the Physical Design Support Your Deployability Requirements?

Have you devised a plan to meet your deployment requirements? Can you deploy the application to your chosen destination smoothly without performing obscure nonbuilt-in tasks?

The following items address the deployability of your solution:

• Has a deployment plan been established, using Visual Studio .NET's deployment projects or XCOPY? Visual Studio .NET deployment projects produce .msi files that enable you to deploy a solution to any Windows operating system, from Windows 95 and up.

• Have you considered using Windows No-Touch Deployment for a Windows Forms deployable solution? New assemblies are automatically found and downloaded.

• Data must be migrated when the data source is being replaced. SQL Server offers DTS to assist in data migration strategies.

Does the Physical Design Support Your Extensibility Requirements?

Have you considered how your solution will be extended in the future to support enhancements and bug fixes? Can you implement new functionality without breaking previous versions?

The following items address the extensibility of your solution:

• Use XML standards wherever possible to ensure that future objects can access prior code.

• Versioning is far simpler in .NET than in COM because .NET assemblies are not in the Registry; therefore, several versions of the same .dll can appear on one machine in different project folders. If assemblies are to be registered in the GAC, .NET offers side-by-side versioning so that these assemblies can coexist.

• Upgrade applications using the original setup project, and Windows Installer will automatically determine what needs to be upgraded.

• Data partitions can be added to increase data storage. Tables can be divided by using horizontal or vertical partitions. Disks can be added to a server and then partitioned to store extra data. SQL Server also offers the capability to partition data to new instances of SQL Server on different physical servers.

Validating Against Usage Scenarios

Does the proposed physical design fit all usage scenarios that you are required to support?

The solution was designed with target users in mind. Chapter 3, "Gathering and Analyzing User Requirements," discussed making use cases for your primary user group. Have you met the needs of everyone in your use cases? For example, if the client needs a platform-independent user interface and you provided an XML Web Service, you have failed to understand the client's needs. You must also watch out for requirements that might not seem so obvious. For example, even if only 5% of your user base does not accept cookies, you should not use cookies for your state management solution, unless the client's machine can be configured.

After the physical specifications are completed, it is customary to review the use cases and attempt to validate that all intended users have the requested functionality.

Creating a Proof-of-Concept Deliverable

Does your proof-of-concept deliverable demonstrate that your proposed physical design is within an acceptable risk range?

Do you have enough knowledge or "proof" to begin, or is there something unknown that represents a risk of project failure? Unknown items, such as integration and migration, should be attempted immediately. Developing a proof-of-concept deliverable enables you to verify that the unknown is possible before you get halfway through the project and find that your original approach wasn't feasible.

In technology, you believe that there is nothing you can't accomplish. As true as this may be, there are always things that are out of your control. If you choose to ignore your mortality, there is a big price to pay if your solution fails.