Do You Validate?

After you have a proposed, or straw man, logical design, you need to validate it. You should make sure it not only meets all the written requirements for the solution, but also meets the eight non-functional requirements Microsoft has outlined.

Does the Logical Design Meet the Business Requirements for "PASS MADE"?

Review your proposed logical design and see whether it conforms to the PASS MADE requirements.

Does the Logical Design Support Your Performance Requirements?

Have you done everything necessary to meet whatever performance standards the requirements outlined or, if standards were not explicitly established, have you met reasonable performance goals?

Performance relates to what a single user experiences when using your system. Scalability, the degradation of performance as the number of users increases, is covered shortly in the "Does the Logical Design Support Your Scalability Requirements?" section.

Does your solution have any obvious performance bottlenecks? You will address this question again when you validate your physical design. However, it is possible to create a poorly performing application that runs entirely on a single machine with a single user.

Reviewing performance at this stage might be the time you look at additional caching strategies. Although caching is part of almost any solution, you can use clever caching and asynchronous processing strategies to further improve your solution's performance.

Does the Logical Design Support Your Availability Requirements?

If the case study mentions the need for unusually high uptime, have you addressed that need in your logical design? Can you simultaneously achieve 100% uptime and meet your other goals? Although there is more you can do to influence availability when you get to the physical design, using both asynchronous processing and a services-style architecture helps create a more fault-tolerant solution.

Does the Logical Design Support Your Security Requirements?

Since the aforementioned "trustworthy computing" initiative at Microsoft, both the real world (in the form of numerous patches to all Microsoft products) and the exam world have changed. Microsoft, for obvious reasons, has made security a more prominent factor in all its products. Although your experiences might say there is still room for improvement, there is no discounting the past year's push to plug security holes in Microsoft-supplied software and to make it easier for developers to create more secure software.

Another question to ask at this stage is whether you've done threat modeling as laid out in Michael Howard and David LeBlanc's book Writing Secure Code (see "Need to Know More?" at the end of this chapter for more details). Threat modeling includes the three main aspects of security: authentication, authorization and encryption.

Does the Logical Design Support Your Scalability Requirements?

Have you done all you can in the design (remember, you still haven't built a thing) to make scalability possible? Just the practice of designing in logical tiers makes designing for scalability easier. It gives you the opportunity to move different components or layers onto different machines, even creating farms or gardens of machines if necessary.

Part of your design should include some way to monitor your application's performance against a user load. When you get into the testing phases, this monitoring will be helpful as you attempt to objectively measure the point at which performance breaks down.

Does the Logical Design Support Your Maintainability Requirements?

Have you created enough artifacts (for example, design documents, use cases, sequence diagrams) to make your overall architecture comprehendable to a person new to your application? Have you segmented the code (by using separate classes or separate components) in such a way that multiple people can work on it simultaneously?

Finally, have you reviewed the "Production Debugging for .NET Framework Applications" guide (MSDN Library: .NET Development > Building Distributed Applications with .NET > Lifecycle Topics > Debugging .NET Applications) to make sure you have set the stage for easy troubleshooting with good tracing and exception-handling logic?

Does the Logical Design Support Your Accessibility Requirements?

As mentioned earlier in the chapter, accessibility is your intentional effort to support users with hearing, sight, or physical impairments as they work with your user interface. This design goal is focused entirely on the User Services Layer. Of course, for a pure XML Web Services solution, because there is no GUI, accessibility does not apply.

Does the Logical Design Support Your Deployability Requirements?

Although deployment is covered in detail in Chapter 10, at this stage you need to do all you can to make deployment easier. Have you limited the number of dependencies you require for your application? Have you avoided, as much as possible, using COM components that require registration? Have you worked to see whether you can get into an XCOPY deployment situation where feasible? Using XCOPY might even mean creating an application that runs right off the CD-ROM in some cases. Wouldn't that be great?

Does the Logical Design Support Your Extensibility Requirements?

Have you created a solution design that enables you to extend the application in the future? The benefit of an iterative, versioned release strategy is that you can get value in front of the user as quickly as possible and learn more about potential oversights in your design and requirements. To facilitate multiple releases, you should design your solution to make alterations as easy as possible. In some respects, this approach might be contradictory with the eXtreme Programming (XP) methodology, but I'm sure common sense and experience are always good practices in any methodology.

Validate Against Usage Scenarios

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

If you create use cases and user personas, have you met all your requirements? Would all personas be able to effectively use what you have designed? In other words, if you design a Web solution but one of your personas requires a very rich, responsive, and highly graphical user interface, maybe you need to rethink your design. Sometimes, if you have layered the application properly, this rework is not a big deal. A well-designed Business Layer should be able to support both a Web and a Windows Forms solution equally well, without modification.

In the area of use cases, you must treat all agreed-on use cases as your contract with the business stakeholders. If you cannot achieve all the use case scenarios, again, you should reevaluate your User Services Layer.

Create a Proof-of-Concept Deliverable

Does your proof-of-concept deliverable demonstrate that your proposed logical design is within an acceptable risk range? One way to answer many of the questions posed in the previous sections is to create a proof-of-concept applet for the parts of your solution that seem risky or that might be non-compliant with one or more of the eight PASS MADE requirements.

Using part of the team, sometimes called a "run ahead" team, you try out the tricky bits, just as a boat manufacturer tests his design on a boat model in a large wave tank. You don't want to get close to the end of your development cycle only to be surprised by a showstopper issue. That's not the way to be asked back to develop the next big application.

Creating a proof-of-concept applet is one of the most useful techniques in your toolkit for mitigating risk. It's better to sink a $250 scale model of your new boat design instead of the real thing. The same applies to software.