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

Contents
Overview 1
The MSF Enterprise Architecture Model 2
The MSF Design Process Model 7
The MSF Application Model 10
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

Module 5: Overview of Other MSF Models iii


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.
Module 5: Overview of Other MSF Models v


• 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.


Module 5: Overview of Other MSF Models 1


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.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
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




 The MSF Enterprise Architecture Model
 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.
Module 5: Overview of Other MSF Models 3


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.

Slide Objective
To present the MSF
definition of enterprise
architecture.
Lead-in
There are many definitions
of enterprise architecture,
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
Business

Application
Application
Technology
Technology
Information
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.
Slide Objective

To present the four
perspectives of the
Enterprise Architecture
Model.
Lead-in
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.
Module 5: Overview of Other MSF Models 5


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.
Key Points
Remind students that
application-level functional
logic is no longer
necessarily contained in
discrete packages.
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


Information Perspective
IT professionals who plan EA will find all types of information useful. This
includes structured information that can be found in the organization’s database,
as well as unstructured information in less obvious formats such as
spreadsheets, archived presentation material and e-mail messages, company
Web pages, and other informal sources, such as notes.
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.
Module 5: Overview of Other MSF Models 7




 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 design-
related project activities through conceptual design, logical design, and physical
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
Three Perspectives of Design
Conceptual
Logical
Physical
Business Solution
Business Solution
User Perspective
Artist Rendering
User Perspective
Artist Rendering
Team Perspective
Blueprint
Team Perspective
Blueprint
Developer Perspective
Engineering Drawings
Materials List
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.
Slide Objective
To introduce conceptual
design, logical design, and
physical design.
Lead-in
Conceptual, logical, and

physical design provide a
continuum of project
activities in the MSF Design
Process Model.
Key Points
Discuss the concept of a
continuum. A working
definition is a coherent
whole, characterized as a
collection of elements
varying by progressive
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.
Module 5: Overview of Other MSF Models 9


Design Process Relationship to the Process Model
Project Plan

Approved
Conceptual Design
Logical Design
Physical Design
Vision
Approved
Conceptual
Design Baseline
Conceptual
Design Baseline
Logical
Design Baseline
Logical
Design Baseline
Physical
Design Baseline
Physical
Design Baseline


Conceptual Design in the Process Model
Conceptual design begins before the team reaches the vision-approved
milestone and ends before the team reaches the project plan approved
milestone. It is possible that some conceptual design can start before the vision
approved milestone.
Logical Design in the Process Model
The next phase is logical design, which following the continuum takes the
scenarios from conceptual design and results in objects and services, user
interface prototypes, and logical database design. Logical design begins before
the team baselines conceptual design and ends before the team reaches the

project plan approved milestone.
Because the design process is not strictly sequential, some logical design can
start even while conceptual design is still fine-tuning the scenarios.
Physical Design in the Process Model
The third phase is physical design, which following the continuum takes the
output of logical design and results in components, user interface specifications,
and physical database design. Physical design begins after the team reaches the
vision-approved milestone and is baselined before the team reaches the project
plan approved milestone.

The design process is not strictly sequential; some physical design can
overlap with logical design.

Slide Objective
To illustrate the relationship
between design process
activities during the planning
phase of the MSF Process
Model.
Lead-in
The MSF Process Model
incorporates the MSF
Design Process Model as
follows
Key Points
Reiterate the MSF Process
Model, where envisioning
comes before planning,
thereby comprising design.
Then state that in

conceptual design you start
with the vision statement
that comes from
envisioning, and your output
is scenarios.
Note
10 Module 5: Overview of Other MSF Models




 The MSF Application Model
 Function of the MSF Application Model
 The MSF Services-based Application Model
 Breaking the Traditional View


An application is a logical (not physical) network of cooperating services,
meaning consumers and suppliers. These services can be distributed across both
physical and functional boundaries to support the needs of the business
solution, whereas reuse implies that the business solution can constitute many
actual applications. Thus, an application is no longer one classical monolithic
implementation, but a logical network with reusable services, such that
overlapping networks simply means that applications share reusable services.

Slide Objective
To introduce the topics
presented in this section.
Lead-in
A working definition of

application is required
before discussing the MSF
Application Model.
Delivery Tip
It is very important to define
application in the context of
this section before
proceeding with the rest of
the topics.
Module 5: Overview of Other MSF Models 11


Function of the MSF Application Model
 Establishes Definitions, Rules, and Relationships
 Facilitates a Consistent Approach to Application Design
and Development
 Uses Services-based Component Design


The MSF Application Model:
 Establishes definitions, rules, and relationships. An application model
establishes the definitions, rules, and relationships that will form the
structure of the application. It serves as a basis for exchanging ideas during
the logical design of an application. The emphasis is logical, not physical.
The MSF Application Model shows how the application is structured, not
how it will be implemented.
 Facilitates a consistent approach to application design and development.
The model builds a common understanding of the application and defines a
working vocabulary for describing application designs.
 Uses services-based component design. An organization may use more than

one application model to accommodate the different types of applications
that it is developing. The MSF Application Model uses services-based
component design to build applications.

Slide Objective
To define the MSF
Application Model.
Lead-in
The key function provided
by the MSF Application
Model is that it expresses an
approach to building
applications by using
services-based component
design.
12 Module 5: Overview of Other MSF Models


The MSF Services-based Application Model
SYSTEM
Databases
User Interface
Services
Data Layer
Business Layer
Presentation Layer


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.
Awareness of the meaning of application and services in this context is
necessary to an understanding of the model.
 Application. Refers to a logical network of cooperative, distributed, and
reusable services that support a business solution.
 Service. Refers to a unit of application logic within a component that
includes methods for implementing an operation, function, or
transformation.

User Services
User services refer to units of application logic that provide an application with
its user interface. For example, a user service may:
 Have an interface that is visual or programmatic, while the user may be a
person or another application.
 Present information to and gather data from the user.
 Hide information views from user interface structures.

Business Services
Business services refer to units of application logic that control the sequencing
and enforcing of business rules. For example, a business service may:
 Ensure transactional integrity.
 Transform data into information by applying business rules.

Slide Objective
To present the three-tier
services-based model.
Lead-in
The MSF Application Model
uses a three-tier services-

based model. The services
include
Module 5: Overview of Other MSF Models 13


Data Services
Data services refer to units of application logic that provide the lowest visible
level of detail used to manipulate data. For example, a data service may:
 Maintain persistent application data.
 Provide the ability to define, create, read, update, and delete.
 Hide the design, implementation, and location of data.

Benefits of Service-based Applications
Flexibility of Distribution
The MSF Application Model provides the ability to create a logical three-tier
application that can then be distributed over n physical tiers.
Parallelism in the Development Process
One of the advantages of a services-based approach is that because an
application is made up of different parts, many small parts can be worked on in
parallel. This leverages the different, specialized skills of the development team
members. For example, the skill set required to program by using Microsoft
®
Visual Basic
® for business logic is different from skills required in database
development.
Efficient Use of Resources and Skills
Because different services generally require different skills and tools, resources
can be used efficiently by leveraging the different skills of the many people on
the development team. For example, business service development may require
Visual Basic experience, whereas data service development may require Visual

C++
®. You can take advantage of technology specialists instead of looking for
one person who knows everything that is required for the implementation of the
solution. As another example, usability and user interface design skills are often
a scarce resource. Rather than assigning people individually to different
projects, an organization might choose to create a usability and user interface
team that shares responsibility for all business applications under development.
Reusability of Services
The services-based MSF Application Model enables applications to share
services so that there is less rework being done and a more consistent
implementation of business rules.
Maintainability
Maintainability is the ability to evolve the product. The MSF services-based
component design makes it easy to find and fix smaller units.

14 Module 5: Overview of Other MSF Models


Breaking the Traditional View
Customer
Database
Customer
Database
Customer
Database
Customer
Database
Customer
Database
Customer

Database
Orders
Database
Orders
Database
Orders
Database
Orders
Database
Product
Product
Customers
Customers
Customers
Customers
Product
Product
Orders
Orders
Customers
Customers
Product
Product
Traditional View
Traditional View
Services View
Services View
Network of Cooperating
Services
Application 1

Application 2 Application 3
Stovepiped Services
Application 1 Application 2


The traditional view of stove-piped services represents the old way of
monolithic implementations.
The services view is the new way of a logical network of cooperating services,
embodying fully the principles of the MSF Application Model. In this view of
applications, services can be shared between applications.

The three-tier concept is a logical model. If taken too literally, the
concept of tiers can lead to monolithic implementations of application logic,
even if it were split into two or three pieces. If this happens, much of the
sought-after flexibility, scalability, and maintainability of a multi-tiered design
would be preempted.

Slide Objective
To present how services
can be shared between
applications.
Lead-in
The three-tier concept of
cooperating services is a
logical model.
Note
Module 5: Overview of Other MSF Models 15


Review

 The MSF Enterprise Architecture Model
 The MSF Design Process Model
 The MSF Application Model


1. What are the four EA perspectives?
The four EA perspectives are business perspective, application
perspective, information perspective, and technology perspective.


2. What are the three phases of the Design Process Model?
The three phases of the Design Process Model are conceptual design,
logical design, and physical design.


3. Whose perspective does each phase of the process model try to address?
The conceptual design phase addresses the perspective of the user, what
the user does, and what the user needs in order to do it.
The logical design phase addresses the perspective of the user as it
applies to building the product and meeting the business needs.
The conceptual design phase addresses the perspective of the
technology that the user will employ.


4. What are the three type of services described by the MSF Application
Model?
The three types of services described by the MSF Application Model
are user services, business services, and data services.

Slide Objective
To reinforce module
objectives by reviewing key
points.
Lead-in
The review questions cover
some of the key concepts
taught in the module.
16 Module 5: Overview of Other MSF Models


5. What does the phrase “three-tier logical over n tier physical” mean?
The phrase refers to the network of three-tier cooperating services
provided by the MSF Application Model.


6. What is one benefit of the MSF Application Model?
Benefits of the MSF Application Model include flexibility of
distribution, parallelism in the development process, efficient use of
resources and skills, and reusability of services.