How MSF is Utilized
Microsoft Solutions Framework Models
Before you continue with the lesson, run the Chap13a.exe animation located on the CD-ROM that accompanies this book. This animation explains each model of the Microsoft Solutions Framework. 
Each model of the MSF contributes to the software development cycle. MSF highlights the clear relationship between a company's business objectives and the technology solutions that they implement. As a whole, the MSF models interrelate in some way. For example, the Team Model is used to provide accountability for project tasks , while the Process Model is used when decisions need to be made.
Each model and its purpose is listed in the following table.
| Model | Description |
| Team Model | Defines a team of peers working in interdependent and cooperating roles. |
| Process Model | Helps your team establish guidelines on planning and controlling results-oriented projects based on their scope, the resources available, and the schedule. |
| Application Model | Helps your team design distributed applications that take optimum advantage of component reuse. Together, the Team and Process models form the core of the MSF discipline as it relates to development and infrastructure projects. |
| Enterprise Architecture Model | The key to successful long- term use of new technologies. This model supports decisions relating to the information, applications, and technology needed to support a business. |
| Solutions Design Model | Shows how applications must be designed from a user and business perspective (as opposed to the ideal streamlined development proposed in the Application Model). |
| Infrastructure Model | Establishes MSF principles for managing the people, processes, and technology that support networks in a large enterprise. |
| Total Cost of Ownership Model | A process for assessing, improving, and managing information technology costs and maximizing value. |
Team Model
The Team Model communicates project status, provides for the division of labor, and delegates task responsibility. Its primary focus is on staffing, competency, management, responsibility, and quality in complex software projects. In particular, it shows how to structure teams to deliver quality solutions more cost effectively.Microsoft's Team Model defines a team of peers working in interdependent and cooperating roles. Each team member has a well-defined role on the project and is focused on a specific mission. This approach encourages ownership and ultimately results in a better product. The leaders of each team are responsible for management, guidance, and coordination, while the team members focus on carrying out their specified missions.
A critical underlying element of success is unrestricted communication between all team members.
The model is comprised of six clearly defined roles:
Program Management
Program management drives the critical decisions necessary to release the right product or service at the right time, and coordinates the decisions required to deliver it in a manner consistent with organizational standards and goals for interoperability.
Product Management
Product management articulates a vision for the product or service, acquires and quantifies customer requirements, develops and maintains the business case, and manages customer expectations.
Development
The Development role builds or implements a product or service that meets specifications and customer expectations, while delivering a system that is fully compliant with the negotiated functional specification.
Testing
The Testing role ensures that all issues are known before the product or service is released; testing must exercise the user interface and APIs, and verify that the new software can be integrated into existing systems.
Logistics
Logistics ensures a smooth rollout, installation, and migration of the product to the operations and support groups.
User Education
The User Education role maximizes the user experience through performance solutions and training systems. It also reduces support costs by making the product easier to understand and use.
All members of the team are responsible for product quality. 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. Although the Team Model has grown out of best practices for software development, these principles also have been applied successfully to infrastructure deployment projects.
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.
The MSF Process Model consists of four phases: envisioning, planning, developing, and stabilization. Each phase culminates in a major milestone.
The Envisioning Phase
Envisioning ensures that an organization develops products and solutions that meet both current and future needs; it also facilitates growth that is consistent with the organization's intended direction. It requires open thinking about business needs and the issues that cause these needs. Envisioning can prevent an organization from investing significant effort on minor needs, or from perpetuating ineffective processes. The Envisioning phase culminates in milestones for the vision, scope, and approval. Once a new product (or, in the case of infrastructure deployment, a new service) gains interest and approval, a project team is assembled to define the product. A vision statement articulates the ultimate goals for the product or service and provides clear direction. A project's scope defines the limits for a particular version of the product or service and recognizes that further development may be required in future versions.
The Planning Phase
At Microsoft, planning is when customers and team agree on what is to be delivered and how a product will be built. This is an important opportunity to reassess risk, establish priorities, and finalize estimates for schedules and resources.
The Planning phase culminates in the Project Plan Approved milestone. The project plan contains the functional specification ”the combined plans of each team member as defined in the MSF Team Model ”and a schedule. The functional specification provides the project team with enough detail to identify what resources they need and to establish commitments.
The Developing Phase
The Developing Phase culminates in the Scope Complete/First Use milestone. An approved functional specification and associated project plan provide a baseline that allows focused development to begin. The development team sets a number of interim delivery milestones, each involving a full test/debug/fix cycle.
At this milestone, customers and the team assess the product's functionality and verify that rollout and support plans are in place. All new development is complete, and deferred functionality is documented for the next release.
The Stabilization Phase
Stabilization requires a change in focus from the creativity of finding elegant development solutions to the rigid operational requirements of thorough and complete testing.
The Stabilization Phase culminates in the Release milestone. Testing is performed even as code development continues. During the stabilization phase, finding and fixing bugs is the primary focus. At this milestone, the product is formally turned over to the operations and support groups. Typically, the project team either begins work on the next release or disperses to other development projects.
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.
Three Categories of Services
To further refine the distribution characteristics of the network of services, the MSF Application Model defines three categories of service that make up an application: user services, business services, and data services. 
User services
User services are the units of application logic that provide an application with its interface. The user of an application can be a person or another application; therefore, an application's interface may be a graphical user interface or a programmatic interface.
Business services
Business services are the units of application logic that control the enforcement and sequence of business rules, and the transactional integrity of the operations performed. Business services transform data into information through the appropriate application of business rules.
Data services
Data services are units of application logic and provide the lowest visible level of abstraction for the manipulation of data. Data services maintain the availability and integrity of both persistent and nonpersistent data as a corporate asset. They provide Create, Read, Update, and Delete services so that business services (the consumers of data services) do not need to know where the data is located, how it is implemented, or how it is accessed.
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. It utilizes such MSF principles as risk-driven scheduling, a fixed release date mindset, activity-based planning, visible milestones, and small teams. In contrast to top-down methods , projects are not only driven by an enterprise model; they directly impact the evolution of the enterprise architecture.
The Business Architecture
The Business Architecture Model describes how the business works. It describes the functions and cross-functional activities an organization performs . The process of describing the business architecture highlights opportunities to use technology to increase revenue, decrease expenses, or enhance innovation. The business architecture helps establish boundaries for clear requirements and the development of a vision and scope for each project.
Key questions you might ask are:
- What industry is your business in?
- What services and resources do you need to run your business?
- What are your core strengths?
- What trends affect your business?
- Is your market expanding or contracting?
- Where will your industry be in five years ?
- What are your profit margins?
- Do your core processes meet your customers' needs?
- Will new systems have a positive effect on cash flow, revenue, or expenses?
The Application Architecture
The Application Architecture Model describes the standard interfaces, services, and application models needed by the business. These translate into development resources for the project teams (for example, component and code libraries, standards documents, and design guidelines). It describes the automated services that support the business processes depicted in the business architecture, and describes the interaction and interdependencies of the organization's applications. Also, it provides guidelines for developing new applications and moving to new application models. Key questions you might ask are:
- What integration issues exist with current systems?
- What application models do you use within your organization?
- Where are your application backlogs?
- Which applications are unique to your business?
- Which applications could be best bought from independent software vendors ?
- Do you require cutting edge functionality or stability in your applications?
- Do your core applications inhibit customer service?
The Information Architecture
The information architecture describes what the organization needs to know 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 describes how data is bound into the workflow, documents, and personal files that pervade the organization. Some of the most critical information resides not only in database servers, but also on the thousands of desktops that abound in most enterprises . Key questions you might ask are:
- What are your business information needs?
- What are the industry requirements and standards?
- What are your critical information needs?
- What are your biggest data issues?
- What are your functional data requirements?
- What are your business process data and workflow requirements?
- Are there statutory or legal constraints that affect your data and information needs?
The Technology Architecture
The technology architecture details standards and guidelines for the acquisition and deployment of: client/workstation tools, application-building blocks, infrastructure services, network connectivity components , and platforms. Acquisition entails build-or-buy decisions, and deployment entails developing technology blueprints to guide the evolution of the technology infrastructure. Key questions you might ask are:
- What level of technology risk is acceptable?
- Do you deploy approved, standard technologies or purchase ad hoc solutions?
- Do you understand how, what, and where technology is deployed in your organization?
- Does your technology infrastructure map to your business needs?
- What are the key technology trends affecting your IT operations?
- Do you know what technical skills you need today and in the future?
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.
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.
Figure 13.5 Three phases of the MSF Solutions Design model
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.
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.
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.
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
Who implements this process? The core roles defined in the Microsoft Team Model are still valid, own the same views of the project, and have the same types of interactions. But to expand the model for an infrastructure deployment project, the six team roles are expanded with wider responsibilities, and three new areas are added to the logistics role:
- System Management . Maintains accountability of the systems, technology, and continued operation of the technology.
- Help Desk
- . Provides ongoing support to the user.
- Communications
- . Maintains voice, video, and data communications capabilities.
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.
- You can reduce your TCO to zero by eliminating all computers from your organization ”along with any competitive advantage they bring. This extreme view indicates two key points ”that value must be part of the equation, and that the overall goal is not to see how far down you can drive TCO The goal is to optimize TCO against the value that is unique to each organization.
- What is a real cost?
- There are a variety of TCO models in the computer industry, with annual costs per desktop PC ranging from $3,200 to $13,000. This discrepancy exists because even the experts cannot agree on which soft and fully loaded costs are included in a good TCO analysis. Microsoft offers a comprehensive model to help organizations understand the cost over time of owning and using each IT component.
- Applying TCO to your needs.
- Some TCO models include a large percentage for fully loaded costs of undefined end-user activities. This approach makes accurate costs hard to measure, substantiate, and apply to your organization in a useful way.
- Seeing the whole picture
- . Some vendors treat TCO as primarily an acquisition cost, creating entire new classes of devices that transfer the acquisition cost to the network, development, and other cost areas.
Planning Phase
In the planning phase, the model shows how to calculate benchmarks, cost baselines, Returns on Investments (ROIs), and validation. The benchmark is a determination of total costs based on industry average costs. A baseline report is based on the actual costs of acquiring, managing, and retiring network-based technology assets.
Building Phase
In the building phase, ROI is calculated by simulating the impact of recommended improvement projects and cost savings over time, based on a particular migration or deployment strategy.
Managing Phase
The managing phase measures actual results against established objectives; this either validates or invalidates the TCO optimization strategy.
The lifecycle approach optimizes the following cost model elements:
- Hardware and software:
- Desktop hardware and software, servers, routers, bridges, and upgrades.
- Support:
- Maintenance, disaster recovery, help desk, administration, and training.
- Development:
- Code and content development.
- Management:
- Network, systems, and data management.
- End-user costs:
- Cooperative end user training, peer support, and general experimenting with the PC.
- Downtime/Other:
- Planned and unplanned downtime, applications development, and testing.
- Telecommunications fees:
- Leased lines and other communication expenses.
Most costs are not found in the acquisition of hardware and software but in the labor needed to develop, support, and maintain an information technology infrastructure. Optimizing these requires a combination of the best uses of technology, skilled IT resources, and best practices.
For instance, organizations often fail to take advantage of system policies, logon scripts, and user profiles. To overcome this requires education. Other best practices include well-defined asset management procedures, standard common operating environments, and training.
A comprehensive TCO strategy entails measurement and improvements in the people, process, and technology of the enterprise. IT infrastructure processes (network operations, network and data management, administration, and help desk) should be as efficient and effective as possible. In contrast, the end user should be as self-sufficient as possible so they do not have to call upon IT for additional support.
Lesson Summary
The Microsoft Solutions Framework (MSF) is a flexible interrelated series of models that guide an organization through the process of assembling the resources, people, and techniques needed to ensure that their technology infrastructure and solutions meet their business objectives. A summary of each model is provided in the following table:| 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 multitier applications built on user, business, and data services.. |
| Enterprise Architecture 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 infrastruture 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. |
EAN: N/A
Pages: 324
- Article 320 Armored Cable Type AC
- Article 392 Cable Trays
- Article 426: Fixed Outdoor Electric De-Icing and Snow-Melting Equipment
- Example No. D9 Feeder Ampacity Determination for Generator Field Control
- Example No. D10 Feeder Ampacity Determination for Adjustable-Speed Drive Control [See 215.2, 430.24, 620.13, 620.14, 620.61, Tables 430.22(E), and 620.14]