| Model |
Description |
| Team
Model |
Communicates status, provides for
the division of labor, and delegates task responsibility.
The model is composed of six clearly defined roles:
program management, project management, development,
testing, logistics, and user education.. |
| Process
Model |
A milestones-based model that provides
guidelines on planning and controlling results-oriented
projects based on their scope, the resources available,
and the schedule. Major milestones are associated
with each of the four phases: envisioning, planning,
developing, and stabilization. |
| Application
Model |
Describes the development of multi-tier
applications built on user, business, and data services. |
| Enterprise
Model |
Provides a consistent set of guidelines
for planning, building, and managing a technology
infrastructure. Four architectures are address in
the model: business, application, information, and
technology. For each of the architectures, key questions
help you develop change-management strategies for
your enterprise. |
| Solutions
Design Model |
Provides a step-by-step strategy
for designing business-oriented solutions driven
by a specific business need. The model is based
on conceptual, logical, and physical phases. |
| Infrastructure
Model |
Establishes MSF principles for
managing the people, processes, and technology that
support networks in a large enterprise. The model
is based on the roles defined in the Team model;
however, the Logistics role is expanded to address
the needs of infrastructure deployment. |
| Total
Cost of Ownership Model |
Helps reduce costs and improve
the return on your computing investment. The model
shows how to contain costs for the planning, building,
and managing, enterprise stages. |
| Team
Model The Team Model
defines a team of peers working in interdependent
and cooperating roles. it communicates status,
provides for the division of labor, and delegates
task responsibility and shows how to structure
teams to deliver quality solutions more cost effectively.
Each team member has a well-defined role on the
project and is focused on a specific mission.
This helps ensure that quality-related issues
are addressed before a product or solution is
implemented. This can help reduce the burden of
rework, reduce help desk costs, and minimize support
costs during the transition.
A critical underlying element
of success is unrestricted communication between
all team members. The model is comprised of six
clearly defined roles: |
| Team role |
Responsibilities |
| Product Management |
Obtains user input and feedback
as requirements, manages customer expectations and
drives validation of the usage scenarios. |
| Program Management |
Drives the overall design process,
coordinates validation with the enterprise architecture
and assures a smooth flow into logical design. |
| Development |
Implements a product or service
that meets the specification and customer expectations,
delivers a system that is fully compliant with the
functional specification and helps to evaluate the
distance between current state and future states. |
| User Education |
Looks at usability issues and assesses
future training and user support requirements based
on the degree of change implied by usage scenarios
for the proposed system. |
| Testing |
Ensures that system is compliant
with user requirements by validating usage scenarios. |
| Logistics |
Looks at the infrastructure and
rollout issues based on where business activities
will be occurring. |
| Process
Model
The Process Model is a milestone-based model
that provides guidelines on planning and controlling
results-oriented projects based on their scope,
the resources available, and the schedule. It
is an iterative and adaptable model that:
|
 |
Defines critical
manageable milestones for development. |
|
Creates explicit team accountability.
|
|
Addresses the risks of a
project early in the planning stages. |
|
Defines the variables and
priorities that affect scheduling, features,
and trade-off decisions. |
|
These guidelines
facilitate better decisions, reduce rework, improve
morale, and can result in a better product. And,
by addressing support and performance issues as
part of the development process, the Process Model
can lower the risks associated with rolling out
new solutions; it can also lower the cost of ownership.
The Process Model consists of
four phases: envisioning, planning, developing,
and stabilization. Each phase culminates in a
major milestone. |
| Application
Model
The Application Model describes the development
of multitier applications built on user, business,
and data services. It establishes definitions,
rules, and relationships that form the structure
of an application. It also offers guidelines on
splitting an application into a network of services
so that features and functionality can be packaged
for reuse across functional boundaries.
A service is a unit of application logic that
implements an operation, function, or transformation
that is applied to an object. Services can enforce
business rules, perform calculations or manipulations
on data, or expose features for entering, retrieving,
viewing, or modifying information.
To further refine the distribution characteristics
of the network of services, the Application Model
defines three categories of service that make
up an
application: user services, business services,
and data services. These have their own attributes,
as the following table shows.
|
| Service type |
Service attributes |
| User services |
Presentation of information and
functionality, navigation, protection of user interface
consistency and integrity |
| Business services |
Shared business policies, generation
of business information from data, protection of
business integrity |
| Data services |
Definition of data, storage and
retrieval of persistent data, protection of data
integrity |
These services are used in the development of multitier
applications are particularly applicable when business
systems are integrated with Internet technologies.
In particular, you can: |
|
Provide an application
with cross-platform support for a heterogeneous
workstation environment. |
|
Promote a consistent user
interface style and navigation model for all
business applications. |
|
Establish and maintain a
presence on the World Wide Web. |
|
Simplify deployment of applications
through centralized maintenance of application
logic on Internet servers. |
|
| Enterprise
Model
The Enterprise Architecture Model provides a
consistent set of guidelines for planning, building,
and managing a technology infrastructure. It encompasses
four perspectives: business, application, information,
and technology. Visualizing each perspective enables
you to develop better change-management strategies
for your enterprise.
Enterprise architecture planning should take
place continuously as business needs evolve. This
is often referred to as planning while building.
In contrast to top-down methods, projects are
not only driven by an enterprise model; they directly
impact the evolution of the enterprise architecture.
|
| Solutions
Design Model
The Solutions Design Model provides a step-by-step
strategy for designing business-oriented solutions
driven by a specific business need. This model
ties together the Application, Team, and Process
Models, and makes it possible for the information
system staff to focus resources where they can
produce the most value.
This model relates solutions development to the
business in two key ways:
|
|
Solutions are
driven from the context of the business, which
is an essential consideration when developing
workflow applications. |
|
End users are brought in
to address usability before incurring help
desk incidents. Also, information systems
professionals are brought in to help end users
solve their concerns without changing the
infrastructure. |
|
The Application,
Team, and Process Models help planners identify
all business and technical requirements of an
application up front, so that resources can be
assigned more effectively. Together, these models
help organizations to recognize the similarities
between the process of designing software with
the similarly complex process of designing a building.
This is why Microsoft gives the title Architect
to experts in software design.
Think of these three perspectives
on design-the Application, Team, and Process Models-as
convenient points along a continuum that help
you apply a particular set of techniques and tools
and address the needs of a particular audience.
These perspectives describe the design process
in a more focused way. At any given point, portions
of your design can be revisited. Design is a continuing
process of incremental refinement. |
Conceptual
Design
The design of a building starts
with the architect's sketches. These provide a
view of the building for the client. These sketches
might include a site plan, elevations, floor plans,
cut-away drawings, and other pictures or drawings.
These views correspond to the conceptual design
for the project. Conceptual design starts with
an understanding of what users really need, and
is followed by an easily communicated set of models
that capture this understanding. |
|
Three Phases
of Component-Based Design |
|
The Conceptual Design Process
|
|
Team Roles and Responsibilities
|
|
Design Deliverables |
|
Design Tasks |
|
| To understand the design
of component-based solutions, we look at the process
from three distinct perspectives: |
|
Conceptual design
|
|
Logical design |
|
Physical design |
|
Logical
Design
The architect's sketches are followed
by architectural plans that show the building
as seen by the architect and contributing staff.
This second phase in the architectural process
combines the client's view with the architect's
view and knowledge. Detailed drawings in each
of many categories help the different contractors
and other parties involved in the project communicate
with each other. This corresponds to the MSF view
of logical design, where the structure and communication
among the individual elements of a system is established.
|
|
Team Roles in
Logical Design |
|
The Process of Logical Design
|
|
Baselining the Logical Design |
|
Physical
Design
Finally, contractors' plans are
drawn up for the builder, who adds detail to the
architect's plans, makes adjustments for the physical
environment of the site and the technology and
materials that are available. This view directs
all the construction activities and may add greater
detail, such as shop plans for individual subcontractors.
This view corresponds to the physical design,
where the real-world constraints of technology,
including implementation and performance considerations,
are applied to the logical model. At this point,
real resources, costs, and schedules are estimated.
These perspectives should not
be thought of as stages. They do not imply a clear
cutoff point or rigid boundary. You do not have
to complete all of the work involved in one perspective
before beginning the next. Elements of the process
can overlap. Indeed, some parts of a system may
be coded while other aspects are still being determined.
If information is available before it normally
would be uncovered or targeted in a particular
design perspective, it should be used. There is
no advantage in waiting to apply information until
a predetermined appropriate point is reached.
One of the advantages of a well-designed
component model (loosely coupled, strong cohesion)
is that if the distribution needs for a particular
component change, those changes can be incorporated
into the component (or replaced by a new component)
with minimal effect on the other components in
the system. |
Infrastructure
Model
In Infrastructure Management,
the MSF process, Team Models, and other principles
are brought together to implement the information
technology infrastructure. In particular, Infrastructure
Management establishes MSF principles for managing
the people, processes, and technology that support
networks in a large enterprise.
The MSF process creates a structure
for the following activities: |
|
Envisioning |
|
Planning |
|
Developing |
|
Stabilization |
|
A project that takes
more than one year to complete may lose its value
because technology is evolving very rapidly. On
large projects, for example, the deployment of
any single version of technology may never be
complete. As soon as one wave of deployment is
nearing completion, another wave will be in the
planning stages. To achieve this, the customer
and project team must prioritize and make trade-off
decisions on the three project management parameters:
schedule, scope, and resources.
The result of the Infrastructure
Model is a more flexible approach to technology
deployment that secures new technology while delivering
added value in less time. If your team is already
familiar with the Team and Process Models, reusing
this knowledge is a highly effective way to benefit
the organization. |
Total
Cost of Ownership Model
The Total Cost of Ownership (TCO)
model helps reduce costs and improve the return
on your computing investment. TCO issues can include:
|
|
The role of value. |
|
What is a real cost? |
|
Applying TCO to your needs. |
|
Seeing the whole picture. |
|
The TCO Model is
a continual process of ongoing improvement with
three key stages: planning, building, and managing.
This approach can be useful in developing business
cases and priorities for infrastructure projects.
For comprehensive and latest information
about Microsoft Solutions Framework, visit Microsoft
website at www.microsoft.com/msf/. |
