About This Book

Welcome to Analyzing Requirements and Defining Solution Architectures: MCSD Training Kit for Exam 70-100. By completing the chapters and associated case studies in this course, you will acquire the knowledge and skills necessary to prepare for the Microsoft Certified Solution Developer Exam 70-100. This self-paced course provides content that supports the skills measured by this exam. Review questions at the end of each chapter recap what you have learned and help you prepare more thoroughly.

NOTE

---

For more information on becoming a Microsoft Certified Solution Developer, see "The Microsoft Certified Professional Program" later in this section.

Intended Audience

This course is designed for students interested in developing their skills in analyzing requirements and defining solution architectures while developing applications. These skills include developing distributed applications using the the Microsoft Solutions Framework (MSF), building multi-layer and client/server solutions, and creating Microsoft Transaction Server (MTS) components and custom Component Object Model (COM) interfaces.

Prerequisites

Before beginning this self-paced course, you should be able to:

• Display a basic knowledge of a development language.
• Create and compile a simple application.
• Create a simple database application and possess a basic understanding of relational database concepts.

Getting Started

This self-paced training course is intended to help you prepare for the Analyzing Requirements and Defining Solution Architectures (70100) exam. You will not need a computer or any hardware or software to complete this course. However, to use and examine the Resource Management System (RMS) Sample Application discussed in the "Case Studies" section, your computer must meet the following hardware and software requirements.

Hardware Requirements for the RMS Sample Application

Although the specific system documentation should be consulted for the minimum requirements to run Microsoft Windows NT Server, Microsoft Internet Information Server, Microsoft Transaction Server, and Microsoft SQL Server, the following server and client minimum configurations are recommended.

The minimum recommendations to run the client and server portions of the RMS Sample Application are:

• Pentium II 266 MHz or equivalent
• 128 MB RAM
• 4 GB hard drive
• Network card and accompanying network components
• CD-ROM drive

Software Requirements for the RMS Sample Application

The RMS Sample Application on the supplemental CD-ROM requires the following server and client software.

Server Software

• Windows NT 4.0 with Service Pack 4
• Windows NT Option Pack 4 with Internet Information Server 4.0 and Microsoft Transaction Server 2.0
• Microsoft Exchange Server 5.5 with Service Pack 2
• Microsoft Collaborative Data Objects 1.21 installed with Microsoft Outlook 98 or higher (must be on machine running Microsoft Transaction Server hosting the RMS business components)
• Microsoft SQL Server 7.0
• Microsoft Data Access Components 2.1
• Microsoft Internet Explorer 4.01 or higher

Client Software

• Windows NT 4.0 Workstation with Service Pack 4, Windows 98, or Windows 95 (must have DCOM95 installed)
• Microsoft Data Access Components 2.1 Redistribution (must have ADOR 1.5) will be installed by client application installation.
• Internet Explorer 4.01 or higher
• Microsoft Outlook 98 or higher

Course Overview

This self-paced course combines text, graphics, and review questions to teach you about analyzing requirements and defining solutions architecture. The course assumes that you will work through the book from beginning to end, but you can choose a customized track and complete only the sections that interest you.

The book is divided into the following chapters:

• Chapter 1, "Enterprise Architecture" This chapter examines the need for application and infrastructure guidance at an enterprise level. It begins by suggesting that systems be implemented with an architecture-first process. Next, the chapter introduces the Microsoft Solutions Framework (MSF). Chapter 1 also examines the MSF Enterprise Architecture Model and its Business, Application, Information, and Technology Perspectives. This chapter additionally points out that the four primary goals of an enterprise architecture are that it be integrated, iterative, actionable, and prioritized. Finally, this chapter discusses how to begin the enterprise architecture process and continue to deliver systems and applications while the architecture process is underway.
• Chapter 2, "Enterprise Applications" This chapter examines the features of modern enterprise applications, and issues that should be considered. It discusses designing large-scale, distributed, enterprise applications and the need to reduce their complexity. It also recommends managing this enterprise application complexity through abstraction, which involves grouping similar requirements together into a small number of abstract categories. Various architecture descriptions are discussed, such as the Unified Modeling Language (UML), Design Patterns, and AntiPatterns. Additionally, this chapter out-lines ten principles for delivering successful applications. Chapter 2 finally suggests that organizations use the several perspectives represented by Microsoft's Enterprise Application Model and discusses the application architecture framework provided by the separate MSF Application Model for Development.
• Chapter 3, "Project Teams" This chapter discusses who is responsible for doing what so that all the different parts of an application project are managed properly. The chapter also discusses building a project team within the context of the MSF Team Model for Application Development (MSF Development Team Model). The discussion progresses from understanding the six equally vital team roles to finding and enlisting leaders from different parts of the organization. Chapter 3 also pinpoints specific responsibilities that must be fulfilled for a project to be successful, and assigns these responsibilities to specific team members. It looks at ways to analyze project requirements from the perspectives of different team members and also explores ways to scale the project team to fit the needs and size of the project. Finally, this chapter examines team and leadership characteristics that will help make an organization's use of its project resources more effective.
• Chapter 4, "Development Process" This chapter is primarily devoted to the MSF Process Model for Application Development, otherwise known as the MSF Development Process Model. Rather than a step-by-step methodology, MSF is a structural framework that an organization can adapt to suit its particular needs. The MSF Development Process Model is the part of this framework that describes the life cycle of a successful software development project. Using a development framework has been successfully proven in the software industry to improve project control, minimize risk, improve product quality, and increase development speed. Also in this chapter, we discuss the Unified Process development framework along with its workflows, stages, and milestones.
• Chapter 5, "Project Vision" This chapter describes the dynamics of the MSF Development Process Model's Envisioning Phase. This chapter also discusses what information to gather from the project stakeholders, how to create a product vision, how the MSF Development Team Model's various roles participate in the envisioning process, and what their responsibilities are. In addition, Chapter 5 examines how the envisioning process develops over a period of time. Finally, this chapter presents a detailed discussion of risk management, based on the MSF Risk Management Model.
• Chapter 6, "Project Plan" This chapter outlines the process of mapping concepts to actions and explains team roles in the Planning Phase of the MSF Development Process Model. It takes an in-depth look at the MSF Design Process Model and the conceptual, logical, and physical architectures of an application. This chapter also discusses how the MSF Application Model's user, business, and data service layers can be incorporated into the application's physical architecture. The MSF Development Process Model's Functional Specification, Master Project Plan, and Master Project Schedule are all emphasized as key deliverables of the Planning Phase. Finally, Chapter 6 discusses principles of scheduling, as well as the ongoing task of risk management.
• Chapter 7, "User Service Layer Technologies" This chapter examines how to create effective and efficient user interface (UI) designs. It also explores legacy, current, and future technologies that affect the user service layer design of the MSF Application Model. Additionally, this chapter discusses the impact of Web technologies on current application design techniques. We complete Chapter 7 with an in-depth look at implementing a Web-based application.
• Chapter 8, "Business Service Layer Technologies" This chapter focuses on such issues as using an object context to manage state, using explicitly defined interfaces when possible, composing functionality, maintaining state across transaction boundaries, propagating errors, and programmatically controlling security. In addition, this chapter takes a detailed examination using COM and COM+ within the business service of an application's physical design. This chapter concludes with a detailed look at using COM components with Microsoft Transaction Server.
• Chapter 9, "Data Service Layer Technologies" This chapter examines design issues related to data requirements and explores characteristics of different data access technologies. This chapter also discusses best uses for each access technology, and normalization of data and data integrity. In addition, this chapter identifies how business rules can affect application data and where these rules are implemented. Furthermore, Chapter 9 examines technologies that provide data access to legacy data system stores and Enterprise Resource Planning (ERP) applications. Finally, this chapter reviews COM+ In-Memory Database (IMDB) features that can improve data access performance.
• Chapter 10, "Testing and the Production Channel" This chapter explains how to build a working environment that supports development, testing, certification, and production. Using real-life examples, this chapter describes the production channel and its goals. Chapter 10 thoroughly examines testing, and recommends several ways to execute and monitor tests. It also discusses ways to scale out an application's production environment by adding servers to the physical implementation. Finally, this chapter examines ways to classify program faults and failures, discuss the larger issue of product bugs, and describe methods of tracking, classifying, and resolving known bug problems.
• Chapter 11, "Application Security" This chapter looks at different security-related protocols and the basic security concepts of authentication. It also examines encryption, which stores and passes information from one place to another so that it can't be read by anyone who intercepts it. Additionally, this chapter discusses access control, which determines what users are allowed to accomplish, and auditing, which records what goes on inside the operating system as users request and work with the resources the system makes available to them.
• Chapter 12, "Development Deliverables" This chapter examines the creation process, including how the various team roles function during development. This chapter further explores testing, bug tracking, and the "zero-defect mindset," and also shows how the project management team makes effective trade-offs. In addition, this chapter discusses how multi-layer applications are implemented as monolithic or client/server, or distributed in physical form. Finally, Chapter 12 explores the end of the MSF Development Process Model's Developing Phase, when code-complete is reached, and all product features and original code are incorporated into the application.
• Chapter 13, "Product Stabilization" This chapter emphasizes the evolutionary cycle the team will progress through to move from the Developing Phase's Scope Complete Milestone to the Stabilizing Phase's Release Milestone. We summarize this phase's effort as four primary steps: Fix the bugs, synchronize all product deliverables, ship the release, and extensively test the release. Leading up to the Release Milestone, the chapter identifies several key interim milestones that are reached by the continual iteration of the phase's steps. This chapter also provides some guidelines for the deployment of an application after the product is released. From the preplanning phases though pilot testing, support, and troubleshooting, we explore efficient ways to deploy the application with as little negative impact as possible on the users and their systems and networks.
• Chapter 14, "Project Review" This chapter emphasizes the value of a solid project review, as it both relates to a project just completed and to the ongoing growth and improvement of the organization. The chapter examines the relationship between the project review and the Capability Maturity Model for Software, and also shows the project review's importance in creating a best practice guide for the organization's development teams. This chapter examines the practical considerations of conducting a project review: when to schedule a project review, who should attend, and the proper physical setting for a project review.

Features of This Book

The following features are designed to enhance the usefulness of this course:

• The overall structure reflects the way a development team would progress through the process of creating an application.
• Each chapter contains reference material that also serves as additional recommended reading.
• Each chapter ends with a short summary of the material presented.
• Review questions at the end of each chapter let you test what you have learned in the chapter.
• Case studies provide a different and interesting way to learn development and application design by participating in the complete development life cycle of a multi-layer, distributed application. Although the case study events are purely fictional, they provide fresh insight on how people build applications. See the "Case Studies" section for more information.

Conventions Used in This Book

Before you start reading any of the chapters, it is important that you understand the following notational conventions used in this book:

• Italic is used for emphasis when defining new terms. Italic is also used for book titles.
• Names of files and folders appear in Title Caps. Unless otherwise indicated, you can use all lowercase letters when you type a file or folder name in a dialog box or at a command prompt.
• File name extensions appear in all lowercase.
• Acronyms appear in all uppercase.
• Monospace type represents code samples, examples of screen text, or entries that you might type at a command prompt or in initialization files.
• Square brackets [ ] are used in syntax statements to enclose optional items. For example, [filename] in command syntax indicates that you can choose to type a file name with the command. Type only the information within the brackets, not the brackets themselves.
• Braces { } are used in syntax statements to enclose required items. Type only the information within the braces, not the braces themselves.

About the CD-ROM

The supplemental CD-ROM contains an electronic version of the entire text of this book, as well as the Analyzing Requirements and Defining Solution Architectures 70-100 Sample Exam. You can install this sample exam from Self-Test Software (STS) to practice taking a sample certification exam. Designed to reflect the kinds of skills tested by the actual Microsoft certification exam, this sample exam includes questions to help you assess your understanding of the materials presented in this book. Each question includes feedback and an associated course reference so that you can review the material presented. You can visit the STS Web site at www.selftestsoftware.com for a complete list of available practice exams.

Also included on the supplemental CD-ROM is the RMS Sample Application and its documentation (see the next section).

Case Studies

The concepts taught in each chapter of this book are demonstrated in a series of case studies. These case studies present fictitious scenarios of a company that is using the development process, concepts, and application design strategies outlined in the book to analyze application requirements, define a solution architecture, and create a product. These case studies are designed to help you understand the concepts and goals presented in the chapters, and to offer a clear picture of how this book's development methodology could work in real life for your own company's projects. The "Case Study Background" section below provides the information necessary to understand the structure and context of the case study's fictional organization. Read through this section thoroughly before you begin this book.

The Resource Management System (RMS) Sample Application, which is referred to in the case studies and included on the supplemental CD-ROM, is a complete multi-layer application that uses key Microsoft technologies, such as Microsoft Visual Basic 6.0, Active Server Pages, Dynamic HTML, Microsoft Outlook 98, Microsoft Transaction Server 2.0, Microsoft Exchange Server 5.5, and Microsoft SQL Server 7.0 to manage company resources. The application presents a real-world example of a multi-client, distributed application that accesses two different data stores. Along with the compiled executables and full source code, sample documentation is provided as a simple example of the documentation created by the project team throughout the case studies. The RMS Sample Application provides a basic resource management system for scheduling and tracking individuals and their proficiencies. In reality, two developers coded this application over a two-month period, which speaks to their skill levels and the benefits of the development tools, technologies, and platforms chosen for the application.

The "Getting Started" section earlier in this introduction provides important setup instructions that describe the hardware and software requirements necessary to run the RMS Sample Application.

Case Study Background

To make the case studies both more interesting and more useful, we decided to present them as a story—imaginary, but nonetheless true to life and based on the real experiences of the authors. Our goal is that as you read this story, you will get a clear picture of how the development methodology could work for your own organization and your own projects.

To better understand the issues presented in the case studies, here is some background information about the fictitious company.

The Company

Ferguson and Bardell Incorporated is a Chicago-based engineering, architecture, and project management firm. Founded in 1948 by two WWII veterans, it has grown to over 800 employees with revenues in 1998 approaching $230 million. Corporate headquarters occupy seven floors of a prominent office high-rise in downtown Chicago, with satellite offices in Detroit, Milwaukee, Cincinnati, Indianapolis, and Louisville.

Ferguson and Bardell embraced technology early and often. Unfortunately, consistency and coherence did not always accompany that early adoption. For example, the company stored project data in proprietary formats in a multitude of locations that were connected either by modems or by overnight messenger services. Additionally, until recently the company used three different word processors, including a terminal-based one.

In 1998, the board of directors and senior management came to the conclusion that the firm's IT efforts were inadequate. One board member, who was familiar with studies of effective business uses of technology, contacted the consulting firm responsible for the studies. After examining Ferguson and Bardell's IT practices and accomplishments for two months, the consultants brought a set of recommendations to the board.

The most controversial recommendation was to remove the position of IT Director, which at that time reported directly to the CFO, and to create instead a CIO position within senior management. Several board members, as well as the CFO, wanted to keep the org chart as it was, but the consultants were insistent. "As long as IT is seen only as a cost center," they argued, "you will never get the business value out of technology that you should expect. And, if you keep IT out of the boardroom, you can't possibly learn enough about technology to make informed business decisions about it. You have to include the IT function in your management team and in your management decision-making if you want to see Ferguson and Bardell crawl out of the technology abyss it's in."

The new CIO came aboard in October, highly recommended by his former employer, a regional law firm where he had risen in five years from Network Manager to CIO. The former IT Director, who had decided to leave rather than take on the redesigned position, had spent the previous year putting a new network infrastructure in place and enabling Internet connectivity across the enterprise. As a result, the new CIO had some time to get oriented before starting a major project. He spent the first three months getting to know his staff, learning the ropes of the business, and putting certain processes and procedures in place.

In January, he brought in a Microsoft trainer to introduce Microsoft Solutions Framework (MSF) to his leadership staff, whose response was mixed. Some were enthusiastic, some were skeptical, and a few hinted that they figured this was another management fad that would soon pass. Nevertheless, he pushed ahead, confident in his belief that only a consistent project framework, informed and driven by business-IT interaction, would accomplish what Ferguson and Bardell needed to accomplish.

The Teams

Ferguson and Bardell's new CIO understood that to build an enterprise architecture, he would have to bring together a team that represented several of Ferguson and Bardell's departments. To develop applications within the context of the company's enterprise architecture, he would have to create project teams. He needed people who would take initiative, who were accomplished in their respective fields, and whom he could count on to see a task through to completion. He knew that building any team could be a challenge, as each person would bring his or her own perspective, approach, and personality to the team.

To develop the company's enterprise architecture, the CIO assembled the following team:

• Dan Shelly, Chief Information Officer Dan is in his early forties and loves business, technology, and the Chicago Bulls, though not necessarily always in that order. As the new CIO, he is both liked and respected; his peers on the management team appreciate his understanding of business issues, and his staff in IT appreciate that he came up through the IT ranks. As one network engineer put it, "Dan knows what it's like to be on call at 3 in the morning!" Dan is still excited about the potential of technology to make a substantive difference to the company, but he has been around long enough to know how hard it can be to actually make that difference.
• Jenny Sax, Network Support Technician Jenny's first job out of college one year ago was with the network support staff of Ferguson and Bardell. In a short time, she has developed a reputation for documenting everything she works on. The company's first help desk guide magically appeared one Monday morning after she spent the previous Friday talking with frustrated users. Detail-oriented, she never misses a chance to learn exactly how things work.
• Kevin Kennedy, Management Specialist Kevin is part of Ferguson and Bardell long-range planning committee. In the last year, he has been working directly with the CEO to optimize the planning and budgeting process. Though often brash, he is considered to be on the fast track toward stepping into the shoes of the CEO when he retires in four years. He has worked in most management roles within the company and gathered a reputation for getting the job done, regardless of the cost.
• Jo Brown, Assistant Chief Operations Officer When no one else would step up to the plate, Jo took over the stalled Y2K project and succeeded in getting Ferguson and Bardell compliant for the millennium. After completing the Y2K project five months ahead of schedule, Jo has gone back to her normal job of keeping the company's operations running smoothly. Her most recent project was to create a procedure manual to simplify the business process for the company. As long as everyone follows the book, everything works smoothly, but she is known for sending blistering e-mails to the poor souls that try to break the rules.
• Dick Kaplan, Business Analyst Every company needs an odd bird, and Dick fills that role for Ferguson and Bardell. In a previous life, Dick was a philosophy professor, and he has a Ph.D and several books to his credit. While looking around for something a little different to do, he stumbled into the consulting business in the early 1980s. Ten years ago, he decided he wanted to work for an architectural firm and chose Ferguson and Bardell. In his current role as business analyst, he is asked to participate on most application design teams because of his easygoing nature and uncanny ability to simplify complex problems.

Even before the company's enterprise architecture was in place, Dan had decided to use the RMS project to test the new development framework. To see this project through, the following team members would need to learn how to work together:

• Bill Pardi, Director of Development Bill has been with Ferguson and Bardell since leaving the military in 1978. He has risen through the ranks, beginning with punch-card work and moving through various "heavy iron" systems into PC-based database development using dBase III and Paradox. He was made head of Development in 1996 after leading a 35-person team in a two-year effort to write a new accounting package for Ferguson and Bardell from scratch. Even though the application was six months late and 40 percent over budget, everyone associated with the project agreed that without Bill, it would have been much worse.
• Jane Clayton, Director of Accounting Jane knows more about how Ferguson and Bardell actually works than almost anybody else. She started at the company ten years ago as a clerk in the accounting department, and rose to the position of director four years ago. She promotes high-quality work, and she focuses on shielding her staff from obstacles and other distractions, whether those obstacles are people, policies, or technology. She's no computer guru, but she has dealt with software long enough to know what works for accounting purposes and what doesn't.
• Tim O'Brien, Network Manager Tim looks ten years younger than his true age of 28. He's interested in all types of technology but has focused his career on Microsoft products by earning an MCSE certification in addition to his EE degree from Northwestern. He's fun to be around, with a ready wit and a smile to match. His tardiness to work and meetings is legendary, as is his knowledge of the Ferguson and Bardell technologies and his ability to troubleshoot problems quickly and effectively.
• Marilou Moris, Trainer A favorite of the Ferguson and Bardell staff, Marilou is an independent trainer who lives in downtown Chicago. From there she travels all across the Midwest, doing training for both companies and training centers. She has done a lot of training for Jane's staff in particular, and she and Jane have become good friends. Jane recommended her to Dan when he needed a trainer for the project team.
• Marta Wolfe-Hellene, Engineer Both the youngest member of the project team and the newest employee at Ferguson and Bardell, Marta is extremely intelligent, hard-working, and well-spoken. As a result, some people think she is soft until they try to push her. She is quiet, almost to a fault, but can show a quick and dry wit once she is comfortable with the people around her.

Using This Book to Prepare for Certification

The following tables provide a list of skills measured on the Analyzing Requirements and Defining Solution Architectures 70-100 certification exam. These tables list each skill with this book's location in which you will find material relating to that skill.

Analyzing Business Requirements

Skill being measured	Chapter	Section
Analyze the scope of a project. Considerations include: existing applications; anticipated changes in environment; expected lifetime of solution; and time, cost, budget, and benefits tradeoffs.	1	What is Architecture?
	2	Enterprise Application Architecture; Guiding Software Principles
	4	MSF Development Process Model Principles
	5	Overview of Project Envisioning; Envisioning Process
Analyze the extent of a business requirement.
Establish business requirements	5	Envisioning Process
Establish type of problem, such as messaging problem or communication problem.	5	Envisioning Process
Establish and define customer quality requirements	5	Envisioning Process
Minimize Total Cost of Ownership (TCO).	3	The MSF Development Team Model
	5	Vision Approved Milestone and Its Deliverables
	6	MSF Design Process
	13	Deployment Methods
Increase Return on Investment (RDI) of solution.	3	The MSF Development Team Model
	5	Vision Approved Milestone and Its Deliverables
	6	MSF Design Process
	13	Deployment Methods
Analyze current platform and infrastructure.	1	MSF Enterprise Architecture Model; Creating an Enterprise Architecture
Incorporate planned platform and infrastructure into solution.	6	MSF Design Process
Analyze impact of technology migration.	1	MSF Enterprise Architecture Model; Creating an Enterprise Architecture
Plan physical requirements, such as infrastructure.	6	MSF Design Process
	7	Entire chapter
	8	Entire chapter
	9	Entire chapter
	11	Entire chapter
Establish application environment, such as hardware platform, support, and operating system.	6	MSF Design Process
	7	Entire chapter
	8	Entire chapter
	9	Entire chapter
	11	Entire chapter
Identify organizational constraints, such as financial situation, company politics, technical acceptance level, and training needs.	1	What is Architecture?; MSF Enterprise Architecture Model
	3	The MSF Development Team Model
	5	Envisioning Process
Establish schedule for implementation of solution	6	MSF Design Process; Project Plan Approved Milestone and Its Deliverables
Identify audience	5	Envisioning Process
Analyze security requirements.
Identify roles of administrator, groups, guests, and clients.	11	Access Security
Identify impact on existing environment.	11	Entire chapter
Establish fault tolerance	10	Scaling the Production Environment
Plan for maintainability.	11	Authentication Security
Plan distribution of security database.	11	Authentication Security
Establish security context.	11	Authentication Security
Plan for auditing.	11	Auditing
Identify level of security needed.	5	Envisioning Process
	11	Entire chapter
Analyze existing mechanisms for security polices	11	Entire chapter
Analyze performance requirements. Considerations include: transactions per time slice; bandwidth; capacity; interoperability with existing standards; peak versus average requirements; response-time expectations; existing response-time characteristics; and barriers to performance.	2	Enterprise Application Architecture
	10	Performance Validation; Scaling the Production Environment
Analyze maintainability requirements. Considerations include: breadth of application distribution; method of distribution; maintenance expectations; location and knowledge level of maintenance staff; and impact of third-party maintenance agreements.	3	The MSF Development Team Model
	10	Managing the Development Environment
	13	Product Deployment
Analyze extensibility requirements. Solution must be able to handle the growth of functionality.	10	Performance Validation; Scaling the Production Environment
Analyze availability requirements. Considerations include: hours of operation; level of availability; geographic scope; and impact of downtime.	10	Performance Validation; Scaling the Production Environment
Analyze human factors requirements. Considerations include: target users; localization; accessibility; roaming users; Help; training requirements; physical environment constraints; and special needs.	3	The MSF Development Team Model
	7	Determining the User Interface; Basics of Interface Design; Creating the UI
Analyze the requirements for integrating a solution with existing applications. Considerations include: legacy applications; format and location of existing data; connectivity to existing applications; data conversion; and data enhancement requirements.	9	What is the Data Service Layer?; Microsoft Data Access Components (MDAC); Choosing the Right Data Access Technology; Accessing Host-Based Data; DCOM Connector for SAP
Analyze existing methodologies and limitations of a business. Considerations include: legal issues; current business practices; organization structure; process engineering; budget; implementation and training methodologies; quality control requirements; and customer s needs.	1	MSF Enterprise Architecture Model; Creating an Enterprise Architecture
	3	The MSF Development Team Model
	4	Models for Application Development; Unified Process; MSF Development Process Model
Analyze scalability requirements. Considerations include: growth of audience; growth of organization; growth of data; and cycle of use.	1	MSF Enterprise Architecture Model; Creating an Enterprise Architecture
	3	The MSF Development Team Model
	4	Models for Application Development; Unified Process; MSF Development Process Model
	5	Envisioning Process; Risk Management Process

Defining the Technical Architecture for a Solution

Skill being measured	Chapter	Section
Given a business scenario, identify which solution type is appropriate. Solution types are single-tier, two-tier, and N-tier.	1	What is Architecture?; MSF Enterprise Architecture Model
	2	Enterprise Application Model
Identify which technologies are appropriate for implementation of a given business solution. Considerations include: technology standards such as EDI, Internet, OSI, COMTI, and POSIX; proprietary technologies; technology environment of the company, both current and planned; selection of development tools; and type of solution, such as enterprise, distributed, centralized, and collaborative.	1	What is Architecture?; MSF Enterprise Architecture Model
	2	Enterprise Application Model
	7	Entire chapter
	8	Entire chapter
	9	Entire chapter
	11	Entire chapter
Choose a data storage architecture. Considerations include: volume; number of transactions per time increment; number of connections or sessions; scope of business requirements; extensibility requirements; reporting requirements; number of users; and type of database.	1	What is Architecture?; MSF Enterprise Architecture Model
	2	Enterprise Application Model
	5	Envisioning Process
	6	MSF Design Process
	9	What is the Data Service Layer?
Test the feasibility of a proposed technical architecture.	5	Vision Approved Milestone and Its Deliverables
Demonstrate that business requirements are met.	6	MSF Design Process; Project Plan Approved Milestone and Its Deliverables
Demonstrate that use case scenarios are met.
Demonstrate that existing technology constraints are met.	10	Managing the Development Environment; Testing Enterprise Applications; Performance Validation; Scaling the Production Environment
Assess impact of shortfalls in meeting requirements.
Develop appropriate deployment strategy.	3	The MSF Development Team Model
	6	MSF Design Process
	13	Product Deployment

Developing the Conceptual and Logical Design for an Application

Skill being measured	Chapter	Section
Construct a conceptual design that is based on a variety of scenarios and that includes context, workflow process, task sequence, and physical environment models. Types of applications include: SDI, MDI, console, and dialog desktop applications; two-tier, client/server, and Web applications; N-tier applications; and collaborative applications.	5	Vision Approved Milestone and Its Deliverables
	6	MSF Design Process
Given a conceptual design, apply the principles of modular design to derive the components and services of the logical design.	5	Vision Approved Milestone and Its Deliverables
	6	MSF Design Process
Incorporate business rules into object design.	5	Vision Approved Milestone and Its Deliverables
	6	MSF Design Process
Assess the potential impact of the logical design on performance, maintainability, extensibility, scalability, availability, and security.	10	Entire chapter
	11	Entire chapter

Developing Data Models

Skill being measured	Chapter	Section
Group data into entities by applying normalization rules.	9	Data Modeling
Specify the relationships between entities.	9	Data Modeling
Choose the foreign key that will enforce a relationship between entities and will ensure referential integrity.	9	Data Modeling
Identify the business rules that relate to data integrity.	8	Designing MTS Packages
Incorporate business rules and constraints into the data model.	9	Data Modeling
Identify appropriate level of denormalization.	9	Data Modeling
Develop a database that uses general database development standards and guidelines.	9	Data Modeling

Designing a User Interface and User Services

Skill being measured	Chapter	Section
Given a solution, identify the navigation for the user interface.	6	MSF Design Process
	7	Determining the User Interface; Basics of Interface Design; Creating the UI
Identify input validation procedures that should be integrated into the user interface.	9	Data Modeling
Evaluate methods of providing online user assistance, such as status bars, ToolTips, and Help files.	7	Determining the User Interface; Basics of Interface Design; Creating the UI
Construct a prototype user interface that is based on business requirements, user interface guidelines, and the organization s standards.	4	The Four MSF Phases and their Major Milestones
	5	Vision Approved Milestone and Its Deliverables
Establish appropriate and consistent use of menu-based controls. Establish appropriate shortcut keys (accelerated keys).	7	Determining the User Interface; Basics of Interface Design; Creating the UI
Establish appropriate type of output.	7	Determining the User Interface; Basics of Interface Design; Creating the UI

Deriving the Physical Design

Skill being measured	Chapter	Section
Assess the potential impact of the physical design on performance, maintainability, extensibility, scalability, availability, and security.	6	MSF Design Process
	9	Microsoft Data Access Components (MDAC)
	10	Entire chapter
	11	Entire chapter
	12	Development Process
Evaluate whether access to a database should be encapsulated in an object.	8	Designing MTS Packages
	9	What is the Data Service Layer; Microsoft Data Access Components (MDAC); Choosing the Right Data Access Technology
Design the properties, methods, and events of components.	6	MSF Design Process
	8	Designing MTS Packages

The Microsoft Certified Professional Program

The Microsoft Certified Professional (MCP) program provides the best method to prove your command of current Microsoft products and technologies. Microsoft, an industry leader in certification, is on the forefront of testing methodology. Its exams and corresponding certifications are developed to validate your mastery of critical competencies as you design and develop, or implement and support, solutions with Microsoft products and technologies. Computer professionals who become Microsoft certified are recognized as experts and are sought after industry-wide.

The MCP program offers five certifications, based on specific areas of technical expertise:

• Microsoft Certified Professional Demonstrates in-depth knowledge of at least one Microsoft operating system. Candidates may pass additional Microsoft certification exams to further quality their skills with Microsoft BackOffice integrated family of server software products, development tools, or desktop programs.
• Microsoft Certified Professional - Specialist: Internet MCPs with a specialty in the Internet, who are qualified to plan security, install and configure server products, manage server resources, extend servers to run CGI scripts or ISAPI scripts, monitor and analyze performance, and troubleshoot problems.
• Microsoft Certified Systems Engineer (MCSE) Qualified to effectively plan, implement, maintain, and support information systems in a wide range of computing environments with Windows 98, Windows NT, and the BackOffice.
• Microsoft Certified Solution Developer (MCSD) Qualified to design and develop custom business solutions with Microsoft development tools, technologies, and platforms, including Office and BackOffice.
• Microsoft Certified Trainer (MCT) Instructionally and technically qualified to deliver Microsoft Official Curriculum through a Microsoft Authorized Technical Education Center (ATEC).

Microsoft Certification Benefits

Microsoft certification, one of the most comprehensive certification programs available for assessing and maintaining software-related skills, is a valuable measure of an individual's knowledge and expertise. Microsoft certification is awarded to individuals who have successfully demonstrated their ability to perform specific tasks and implement solutions with Microsoft products. Not only does certification provide an objective measure for employers to consider, but it also provides guidance for what an individual should know to be proficient. And as with any skills assessment and benchmarking measure, certification brings a variety of benefits: to the individual, and to employers and organizations.

Technical Support

Every effort has been made to ensure the accuracy of this book and the con- tents of the supplemental CD-ROM. If you have comments, questions, or ideas regarding this book or the supplemental CD-ROM, please send them to Microsoft Press using either of the following methods:

E-mail:

[e-mail]

Postal Mail:

Microsoft Press
Attn: Analyzing Requirements and Defining Solution
Architectures Editor
One Microsoft Way
Redmond, WA 98052-6399

Microsoft Press provides corrections for books through the World Wide Web at the following address:

http://mspress.microsoft.com/support/

Please note that product support is not offered through these mail addresses. For further information regarding Microsoft software support options, please connect to www.microsoft.com/support/ or call Microsoft Support Network Sales at [phone].

About the Authors

Tim Landgrave

Tim Landgrave founded KiZAN Corporation in 1991 as a software development company specializing in client/server development using Microsoft technology. Since then Tim has architected, developed, and deployed systems using key Microsoft technologies. In addition to his role as CEO of KiZAN, Tim has also been active as a Microsoft Regional Director, hosting events such as Developer Days and evangelizing the Microsoft development platform message to companies looking to build robust, multi-layer applications on Microsoft platforms. Before starting KiZAN, Tim was Director of Technology for The Cobb Group, where he started their developer journal group, and served as editor-in-chief of major technical newsletters, including Inside Visual Basic, Inside Visual C++, and the Microsoft Networking Journal.

Bruce Maples

Bruce Maples' involvement with computers began in 1984 when he got his first Apple II, on which he quickly learned how to write code and hack the operating system. Since that time, he has written applications in languages from dBase to Visual Basic, has taught a wide range of computer classes, and has been active as a consultant and writer. He currently writes for a number of publications and conducts training across the country. He lives in Louisville, Kentucky with his wife, Nina, and his sons, Griffin and Benjamin, where, in addition to his computer work, he is active in church life and community affairs.

Scott F. Wilson

Scott Wilson helped build KiZAN Corporation into a successful systems architecture company specializing in multi-layer development and network services using Microsoft technology. Since then, Scott has designed enterprise architectures, network systems infrastructures, and enterprise applications for KiZAN's clients. For the last three years, he has helped large organizations architect and deploy Web-based applications using Microsoft's MCIS and Site Server Commerce products. In addition to his role as CTO of KiZAN, Scott has been active as a Microsoft Certified Trainer and Microsoft Certified Systems Engineer since 1995. He can be reached at [e-mail].

KiZAN Corporation

This course was developed for Microsoft Press by KiZAN Corporation. KiZAN was the first Microsoft Solution Provider Partner of the Year in 1995. As a Microsoft Solution Provider Partner and Microsoft Certified Technical Education Center (CTEC), KiZAN works closely with customers to provide the most comprehensive solutions on the market today. KiZAN offers all the Microsoft products and services from desktop applications and packaged applications to advanced enterprise solutions using Microsoft's BackOffice products. These products and solutions are complemented by a full array of services, including system engineering consulting, multi-layer and client/server architectural design, multi-layer application development, project planning, implementation services, and technical and desktop training in public or private classes.

KiZAN has created a number of developer training courses for Microsoft. These include traditional instructor-led courses, self-paced kits, and computer-based (CDROM) multimedia titles. In association with their partner company, CustomCourseware.com, KiZAN offers complete conversion and customization services for existing courseware for use in an online or instructor-led training environment.

Contact KiZAN Corporation at:

• E-mail: [e-mail]
• Web site: www.kizan.com

KiZAN staff members who developed this course include:

Project Editor:	Scott F. Wilson
Authors:	Tim Landgrave Bruce Maples Scott F. Wilson
Application Development:	Kevin Benton Chris Marrow
Technical Contributions:	Damien Kalvar Whitney Roberts John Ross Mark Solomon Steve Staten Craig Stein
Editing Contributions:	Allan McGuffey

Editing, production, and graphic support services were provided by Online Training Solutions, Inc. (OTSI).