As part of the emerging MCSD.NET certification track, the Solution Architectures exam (70-100) has been revised and goes live in February 2003. The new exam, "Analyzing Requirements and Defining Microsoft .NET Solution Architectures" (70-300), covers some of the most difficult topics related to software development, taking you beyond the code of whatever platform for which you design and into the reasons and processes for developing an application.
Prepare for the 70-300 exam with our study guide
This article is part of a downloadable study guide that will expose you to many of the topics covered by this exam. In the study guide, you’ll learn how to accomplish a variety of design tasks—including requirements gathering, technical architecture, conceptual and logical design, data modeling, user interface design, and physical design—the Microsoft .NET way.
A critical part of designing a solution will be translating your raw concepts into a logical architecture for the system. Here, I'll explain how to define a concept that you can then translate easily into a logical design. I’ll also introduce you to the skills and tools you can use to identify the important conceptual design points.
Conceptual design points
Coming up with the concept for a solution is the fun part of the process. But no matter what your great idea may be, taking that idea and turning it into a fleshed-out conceptual design isn’t as easy as it was to dream it up. So when it comes time to build that conceptual design, these tools and skills can provide a foundation for that plan.
The most relevant of tools is Unified Modeling Language (UML), which is basically the markup language of concept design documentation. However, it’s not covered widely in the study materials, and I don't remember seeing much about it on the exam. So why bring it up at all? Because, if you're used to thinking in UML or UML-like concepts, the conceptual design questions on the exam should make more sense to you. Let’s explore a few of these concepts and see how they relate to conceptual design.
Case scenarios in their various forms
Case scenarios, also known as "use case scenarios," illustrate how a user will use an application. They usually go something like this: "The user realizes she needs to do blank, so she sits down at her computer and blank. Five minutes later she gets up from the computer richer, thinner, and smarter." Your job, as the architect for the solution is to fill in the blanks.
Pay attention to the context
As you listen to the client (or yourself) wax on about the case scenarios, pay attention to the context or the circumstances in which each case is presented. This will help you later when you try to define the components of the solution and how they will relate to each other. For example, if the user will be at the beach when she uses your solution, you may want to consider waterproofing the servers, or providing the user with a waterproof PDA to access the solution.
As another, more realistic example, your solution may involve a mix of UNIX and Windows systems spread out over the countryside. In that case, you'll want to consider which components are best suited for one platform or the other.
Workflow design, also known as storyboarding, involves determining the physical and chronological process of performing the desired functions for the solution, as determined by your case scenarios. When you lay out the workflow for a solution, you simply throw the deck of component definitions on the table in front of you and begin arranging them according to their physical and chronological relationship to each other. The previous Solution Architecture exam (70-100) worked just that way: You were presented with a deck of component definitions, and you had to create links between them representing how you felt they should flow.
For a better idea of this process of establishing workflow and relationships among design components. take a look at any of the Microsoft tools for graphically designing data table relationships, such as Visio. To see what it should look like when it’s done well, take a look at the Rational line of products.
Where workflow design is an object-based, graphical process, task sequencing is more linear and text based. Also, task sequencing is an important design process because it answers many of the design questions that your application coders and data designers will have early on. If your business requirements state that only executives can modify data, you'll want to make sure that's reflected in the task sequence, or else your developers might make that function available without user validation happening first.
Determining the physical environment
The final function in the conceptual design process is to define the physical environment in which your solution will reside. This process will include determining which technologies are in use or available for your solution. You may also have to answer questions such as "Where will the servers be housed?" In such a case, determining what utilities are available—water, heating and air-conditioning, waterproofing, or even bomb proofing—might be important as well. If you don't define the physical environment, you may find that you've created an excellent application for terrestrial use, but it's also one that crashes when your users put it on a satellite and launch it into orbit.