Microsoft Windows Architecture for Developers Training Kit

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.

Figure 13.1 The six roles of the MSF Team model

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:

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 MSF Process Model consists of four phases: envisioning, planning, developing, and stabilization. Each phase culminates in a major milestone.

Figure 13.2 The four phases of the MSF Process model

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.

Figure 13.3 Three categories of services in the MSF Application model

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:

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.

Figure 13.4 The architectures of the MSF Enterprise Model

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:

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:

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:

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:

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:

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.

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:

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.

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:

Figure 13.6 The MSF Infrastructure model 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 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.

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:

Figure 13.7 A breakdown of costs model elements in the Managing phase

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.

Категории