Tài liệu Module 5: Overview of Other MSF Models docx

Instructor Notes Module 5: Overview of Other MSF Models This module provides students with an overview of other Microsoft Solutions Framework MSF models, including the MSF Enterprise Arc

Contents

Overview 1

The MSF Enterprise Architecture Model 2

Review 15

Module 5: Overview of Other MSF Models

Information in this document is subject to change without notice The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended

to represent any real individual, company, product, or event, unless otherwise noted Complying with all applicable copyright laws is the responsibility of the user No part of this document may

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 1999 Microsoft Corporation All rights reserved

Microsoft, MS-DOS, MS, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries

The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted

Other product and company names mentioned herein may be the trademarks of their respective owners

MOC Project Advisor: Janet Wilson

MOC Project Lead: Sharon Salavaria

Program Manager/MSF Project Manager: Sharon Limbocker

Program Manager/Technical Consultant: Dolph Santello

Instructional Designer: Marilyn McCune (Independent)

Product Manager: Jim Wilson

Product Manager: Jerry Dyer

Graphic Artist: Andrea Heuston (Artitudes Layout & Design)

Editing Manger: Lynette Skinner

Editors: Marilyn McCune (Independent) and Wendy Cleary (S&T Onsite)

Production Support: Ed Casper (S&T Consulting)

Manufacturing Manager: Bo Galford

Lead Product Manager: Development Services: Elaine Nuerenberg

Lead Product Manager: Mary Larson

Group Product Manager: Robert Stewart

Instructor Notes Module 5: Overview of Other MSF Models

This module provides students with an overview of other Microsoft Solutions Framework (MSF) models, including the MSF Enterprise Architecture Model,

the MSF Design Process Model, and the MSF Application Model

At the end of this module, students will be able to:

Describe the four perspectives of the MSF Enterprise Architecture Model

Describe the three phases of the MSF Design Process Model and explain how each phase relates to the planning phase of the MSF Process Model

Describe the MSF Application Model

Materials and Preparation

This section provides you with the materials and preparation needed to teach this module

Materials

To teach this module, you need the following materials:

Microsoft® PowerPoint® file 1639a_05.ppt

Module 5, “Overview of Other MSF Models”

Preparation

To prepare for this module, you should:

• Read all of the materials for this module

Presentation:

30 Minutes

Activity:

0 Minutes

iv Module 5: Overview of Other MSF Models

Module Strategy

Use the following strategy to present this module:

The MSF Enterprise Architecture Model This section introduces the MSF Enterprise Architecture Model

Topics in this section include:

• MSF Definition of Enterprise Architecture This section presents the MSF definition of Enterprise Architecture (EA), including the organization business activities and the application, information, and technologies that support those business activities

• Four Perspectives: One Architecture Tell students that in the past, information technology (IT) professionals have not been encouraged to examine enterprise areas other than technology Neither have professionals in other enterprise areas been asked to relate their activities to other groups, least of all to the IT domain When asked about activities in another department, the typical reaction is, “That is not my group.” This insularity is not very useful to the enterprise quest for self-knowledge Each perspective, whether it is business, application, information, or technology, has value, but a viable

EA arises out of the way that these perspectives interrelate

The MSF Design Process Model This section introduces the MSF Design Process continuum and describes the application of the design process to the MSF Process Model

Topics in this section include:

• The MSF Design Process Continuum This section defines conceptual design, logical design, and physical design, and describes the MSF Design Process continuum as an iterative process

• Design Process Relationship to the Process Model This section discusses the relationship between design activities during the planning phase of the Process Model

The MSF Application Model This section describes the key function of the MSF Application Model, which uses a services-based component design approach to build applications

Topics in this section include:

• Function of the MSF Application Model This section describes the definitions, rules, and relationships, and services-based component design approach used by the MSF Application Model

• The MSF Services-based Application Model The MSF Application Model uses a three-tier, logical model for designing multi-tier, distributed applications that include three broad categories of service: user, business, and data The benefit of the model

is that it establishes definitions, rules, and relationships that form the structure of an application

• Breaking the Traditional View This section compares the traditional, stove-piped services view to the three-tier, logical approach of the MSF Application Model

The module concludes with review questions that reinforce the module learning objectives

There is no activity for this module

Overview

The MSF Enterprise Architecture Model

The MSF Design Process Model

The MSF Application Model

At the end of this module, you will be able to:

Describe the four perspectives of the Microsoft Solutions Framework (MSF) Enterprise Architecture Model

Describe the three phases of the MSF Design Process Model and explain how each phase relates to the planning phase of the MSF Process Model

Describe the MSF Application Model

In this module, you will learn

about some of the other

MSF models and where

additional information is

available for the models

2 Module 5: Overview of Other MSF Models

MSF Definition of Enterprise Architecture

Four Perspectives: One Architecture

The four perspectives of the MSF Enterprise Architecture Model relate to one

another in a way that comprises one architecture for the enterprise

Slide Objective

To introduce the topics

presented in this section

Lead-in

In this section, you will learn

about the MSF Enterprise

Architecture Model,

including the architecture

and benefits of the model

MSF Definition of Enterprise Architecture

Describes the Organization’s Business Activities

Describes the Applications and Information That Support those Business Activities

Describes the Technologies That Enable the Applications and Information

Represents a Dynamic Environment at a Single Moment

in Time

The MSF version of enterprise architecture (EA):

Describes the organization’s business activities, including:

• How products or services are delivered

• How the business interacts with its customers and suppliers

• The organizational structure

• Business processes

Describes the applications and information that support those business activities

Describes the technologies that enable the applications and information

Represents a dynamic environment at a single moment in time

but few cover the scope of

what it really means

4 Module 5: Overview of Other MSF Models

Four Perspectives: One Architecture

There Is One Architecture for the Enterprise

The Value of the EA Is Not in an Individual Perspective, But in the Relationships Between the Perspectives

Enterprise Architecture

Business

Application

Technology Information

There is one, singular architecture for the enterprise Each perspective has value; however, the value of the EA resides in how those perspectives relate to one another

The acronym BAIT is an easy way to remember the four-in-one concept of EA

Business is at the top because it drives the enterprise Applications and information are the means to achieve the business goals and objectives of the

enterprise Technology is at the base because it is the foundation

The key to successful EA is the ability to see business activities through all four perspectives Mature enterprise organizations that still experience problems can usually trace difficulties to a lack of understanding of business aspects that lie outside of one’s activity domain

The MSF model is significantly different from other models in that MSF deals with applications before information

Planners analyze applications first so that information technology (IT) can

be analyzed after the application perspective is tied to business goals and objectives

Another important characteristic is that business is the driver of the EA, and technology is the base

There are four perspectives to EA: the business perspective, the application perspective, the information perspective, and the technology perspective

This slide shows the four

perspectives through which

to view an enterprise

organization, each different,

but all related

Key Points

Tell students that B-A-I-T is

an easy way to remember

the four perspectives

Referring to the illustration,

the pyramid symbolizes the

four-in-one concept of the

MSF version of EA

Business Perspective

The business side of the enterprise typically addresses some issues that the IT team rarely discusses For example, from the business perspective, the following considerations are primary:

Goals and objectives What is the business of the organization?

Organization Who is responsible?

Business process How does the organization do business?

Customer Who is the ultimate customer?

Suppliers/vendors With whom does the organization need to work?

The EA team should broaden its business horizons by striving to answer these questions for itself

Application Perspective

IT professionals planning EA must know the automated services that support business processes even when the functionality is not contained in discrete packages Try to identify redundancy between departments, and try to discover new uses for underused resources

Nevertheless, you still are

required to know the

function of automated

services and how they work

together

6 Module 5: Overview of Other MSF Models

The information perspective describes what the organization needs to know in order to run its business processes and operations It includes standard data models, data management policies, and descriptions of the patterns of information consumption and production in the organization

It is important to know how data, information, and knowledge are defined in the business environment

Data Raw facts without context For example, names and telephone

numbers are facts that have no meaning in and of themselves

Information Organized data For example, the telephone numbers of all

male customers over the age of 50

Knowledge Data and information organized to present a point of view It is

subjective, and its value is in its context

Technology Perspective

Technology perspective includes all of the hardware, software, technical support, and standards and guidelines needed to achieve the business mission The technology perspective defines the technology services needed to execute the business mission (such as topologies, development environments,

application programming interfaces, security, network services, database management systems, technical specifications, hardware tiers, and operating systems) The technology perspective establishes standards and guidelines for the acquisition and deployment of workstation and server tools and base applications, infrastructure services, network connectivity components, and platforms

Technology perspective also determines the standard interfaces, services, and application models used as development resources for project teams (for example, component code libraries, standards documents, and design guidelines)

Key Points

Information is one area

where the interrelatedness

of the four perspectives of

EA is critical Information

from one activity easily can

influence other activities

Key Points

Reaffirm that there are four

perspectives to EA:

business, application,

information or data, and

technology (BAIT) But there

is one architecture for the

enterprise

The MSF Design Process Model

The MSF Design Process Continuum

Design Process Relationship to the Process Model

The MSF Design Process Model structure provides for a continuum of related project activities through conceptual design, logical design, and physical design

design-Slide Objective

To introduce the topics

presented in this section

Lead-in

In this section, you will learn

about the MSF Design

Process Model

8 Module 5: Overview of Other MSF Models

The MSF Design Process Continuum

Three Perspectives of Design Conceptual

Developer Perspective

Engineering Drawings Materials List

The use of the term continuum in this context refers to each design activity, conceptual, logical, and physical, flowing into the next activity, and a process

that is constantly flowing between activities For example, the output of conceptual design feeds into logical design, but holes in the logical design may make further conceptual design necessary Also, the implementation of a physical design should be traceable back to conceptual design

Conceptual Design

The goal in conceptual design is to identify business needs and to understand what users do and what they require It is not the approach that you take or the technologies that you use to build a solution Conceptual design is analogous to the rough sketches and scenarios created when designing a house These are easily understood models jointly created by the customer and the architect

Logical Design

Logical design organizes the details of the application that you build to fulfill business needs and user requirements Logical design is created by the architect’s team and lays out the structure of the solution and the communication paths among elements Logical design corresponds to a floor plan and elevation, where elements such as spatial relationships are organized

Physical Design

Physical design addresses the technology that will be used by the end user The goal is to apply real-world technology constraints to the logical design, such as implementation and performance considerations Physical design corresponds

to a contractor’s blueprints for the physical elements of a structure—wiring, plumbing, heating, and ventilation The contractor’s plans add detail to the architect’s plans and reflect real-world construction constraints

Conceptual, logical, and

physical design provide a

degrees Be careful not to

leave the impression that

the design process is strictly

sequential

Because the design process

is iterative, the conceptual,

logical, and physical design

activities are in a continuum;

these three are not discrete,

but iterative and

traceableone leading to

the otherwith the upward

view available any time