Chapter 1: Microsoft Solution Framework Overview

Chapter 1: Microsoft Solution Framework Overview.. 1

Certification Objectives. 1

What Is the Microsoft Solution Framework?. 2

From the Classroom.. 9

Key Principles and Methods for the IT Life Cycle. 12

Addressing the Growing Demand for Flexible Business Solutions. 14

Technology Infrastructure. 15

Anticipating User Needs. 16

Assessing Existing Applications. 17

Anticipating Changes in the Business Environment 18

Estimating the Expected Lifetime of the Solution. 19

Assessing Time, Cost, Budget, and Benefit Tradeoffs. 20

Certification Summary. 21

Two-Minute Drill 22

Certification Objectives

·       Identifying the Business Pressures on IT

·       Identifying Key Areas Where IT and Business Are Changing Together

·       Identifying Problems IT Must Overcome to Drive Business

·       Analyzing the Scope of a Project

Welcome to your first steps to passing the Analyzing Requirements and Defining Solution Architectures exam. If you’re experienced in analysis, design, and have dealt with solution architectures, you may be wondering if you need to read this book. There are many methodologies out there that work well in theory, but are much less useful in the real (work) world. The Microsoft Solution Framework (MSF) consists of practices that have had proven success in the real world. Not only does reading this book bring you one step closer to becoming an MCSD, but it explains tried and true methods, from the real world.

In this chapter we’ll introduce you to the principles and models that make up the Microsoft Solution Framework. We’ll discuss what MSF is, what it’s used for, and what it can do for you. While this chapter contains a substantial amount of information, it is merely a stepping stone for information that is covered throughout the book. By introducing you to the elements that make up MSF, you’ll be able to build on this information as we go along.

Identifying the Business Pressures on IT

The way business is conducted has changed more in the last 20 years than it has in the last two millennia. Technology has created the need for people to be educated throughout their entire lives. The Internet has even the smallest companies competing on a global scale. As companies merge, different technologies are combined, so that software needs to interact or run on different platforms, accessing different forms of information. Throughout this, there is new legislation that must be adhered to, buyouts to worry about, while trying to keep up with product cycles that are constantly growing shorter. Everyone, including Information Technology feels the rapid changes washing over the business world.

New risks bring new challenges. No matter what problem you face, it’s important that a company’s technical and business goals parallel one another and work together toward common goals. While this may seem like commonsense to you, people in Information Technology (IT) have traditionally been somewhat separated from the “suits” of the business world.

When computers first entered the corporate structure, the programmers and, to a lesser degree, network people, were early explorers who mapped the regions of the computer world. Often isolated from the business people in a quiet part of the building, these techies determined what could and couldn’t be done with computers. While they followed the orders of upper management, communication of project goals was usually lax. Today, people have grown up with computers like settlers of cyberspace, and the importance of Information Technology is well recognized. The role of explorer has changed to that of cowboys and cowgirls, where programmers and network specialists work together with people in the business world. In many cases, the effectiveness of these hired hands determines the success of the company itself!

Now let’s look at how Microsoft’s Solution Framework deals with many of the problems facing business and Information Technology.

What Is the Microsoft Solution Framework?

The easiest way to achieve success is to follow in the successful footsteps of others. This doesn’t mean you should wait to see what the competition is doing, and then put out a duplicate product, though that’s been known to happen way too often in the real world. What it means is to learn to play like the big boys do, by following their game plans. That, in a nutshell, sums up what the Microsoft Solution Framework is about—it takes the best practices that are out there and integrates them into models, principles, and guides that the rest of us can use.

MSF is the most successful practices available for making software projects succeed. Unlike some models that are purely theoretical, MSF is taken from the experiences of IT professionals. Only the practices that have worked are incorporated into the framework. It is the amassed knowledge of Microsoft, its solution developers, partners, IT groups, customers, and product developers. It helps to integrate the business and IT environments, build teams that work, expose critical risks, identify and lower cost drivers, make improved development tradeoffs, create flexible designs, improve deployment, and anticipate the needs of customers and users. By using the resources, guides, and practices of the Microsoft Solution Framework, you not only create a better working environment, but also dramatically lower the odds that a project will fail.

Anyone who’s worked on a software development project can tell you that the odds of a project succeeding or failing would make the most diehard gambler cringe. This is where risk management comes in. Under MSF, a risk is defined as the possibility of suffering some sort of loss, and is inherent to any project. This doesn’t necessarily make risks a bad thing. Risk offers opportunity for a project. Earlier in this section, it was mentioned that it is not entirely uncommon for some enterprises to see what the competition does, and then follow their example. The competition absorbs all of the risks, as well as the benefits of taking a chance on a project. As we’ll see in Chapter 3, Risk Management, risk management identifies, monitors, and deals with risks, so they don’t become actual problems that can threaten a project’s success.

In addition to the principles of risk management, the Microsoft Solution Framework provides models that can be used to enhance a project’s success. MSF consists of seven models, which can be used individually or combined. As we’ll discuss later in this section, you aren’t limited to an “all or nothing” approach, and you can implement the models as your needs dictate. The MSF models consist of the following:

·       Team Model

·       Process Model

·       Application Model

·       Solutions Design Model

·       Enterprise Architecture Model

·       Infrastructure Model

·       TCO Model

Each of these models is used for very different purposes on a project to address different issues that determine a project’s success.  In the paragraphs that follow, we’ll introduce you to each of these, then expand on them throughout this chapter and, of course, throughout the book.

Team Model

The most fundamental resource of any project is the team that’s working on it. Without an effective, expert team of individuals, nothing would get done. The team model recognizes this importance, and provides team members with the power to use their expertise and creativity on a project, while holding them accountable for their actions.

MSF’s team model outlines well-defined roles for members of the team. Each role has its own mission, for which members in that role are responsible. This allows members to not only have ownership over part of a project, it also allows them to focus on what they’re working toward. The six roles and missions of the team model are the following:

·       Product management Responsible for obtaining the customer’s requirements of a product, and setting the vision for the product so everyone understands what it entails. This role also creates and manages a business case (explained in the next chapter), and manages the expectations of the customer so they understand what can and will be delivered.

·       Program management Responsible for making decisions that determine delivery of the right product at the right time. Ensures that the product meets the standards of the organization, as well as the interoperability goals.

·       Development Responsible for building or implementing a product or service that meets the requirements and needs of the customer.

·       Testing Responsible for making certain that a product works, and that issues such as bugs and errorsare addressed before release.

·       User Education Responsible for enhancing the user’s experience and performance with a product, by making the product easy to understand and use.

·       Logistics Responsible for a smooth rollout of the product. Ensures that the installation and migration of a product to support and operations groups goes smoothly.

Each of these roles works on their specific mission, and works toward achieving a specific goal that they are responsible for. Members know what they’re hoping to achieve from their work, and what their purpose on the project is. Because people know what they’re doing, and have ownership of their part in the project, the end result is a product of higher quality.

Exam Watch: Expect to see numerous questions dealing directly or indirectly with the team model and the roles that make up this model. This model is used in conjunction with other models, when applied to projects in the real world. As such, its importance will probably be reflected in questions dealing with it on the exam.

The team model isn’t an organizational chart to show who reports to whom, or which person on a team rules over another. Members of the team work together as peers. This isn’t to say that leadership is dismissed. Team leaders are implemented to provide guidance and direction, so members can focus on the goals of their respective roles. Who the team reports to is left to the discretion of upper management.

Process Model

The MSF process model clarifies what people are working toward, and the progress achieved from that work. Process focuses the team on issues relevant to different phases of the project, and allows members to see that they’re on the right track with a project. It does this by breaking the development cycle into four phases:

·       envisioning phase

·       planning phase

·       developing phase

·       stabilizing phase

By breaking the project into phases, large projects are less overwhelming and more organized. As we’ll see later in this section, each phase is well defined. It outlines what needs to be done for that part of the project to culminate and the next phase to begin.

At the end of each phase, a major milestone is reached in the project. A milestone is a major turning point in the project that indicates progress. At each milestone, the team determines whether the customer’s requirements are being met, and synchronizes their efforts so the project can succeed. Such milestones force the project to become results-oriented—one phase must be successful, and culminate in a milestone, before the next phase can begin.

The first phase in the process model is the envisioning phase. It is here that project requirements are defined. This phase keeps the team from spending effort on minor needs, or trying to make bad procedures or operations more efficient. For example, you don’t want to spend great effort changing the color of the user interfaces in an enterprise application, because someone wants it to have a marble appearance. Not only are the current needs of the customer evaluated, but future issues the business may face, similar issues faced in other departments, as well as what is causing the need in the first place.

Once this is done, the envisioning phase results in the vision/scope approved milestone, where an agreement is made on what direction the project will take. Vision sets the ultimate goals of the project, while scope recognizes the limitations. This takes into account that while it would be great to have 20 new features added to a product, the schedule may allow only 15, with the additional 5 appearing in the next version of the software. By reaching this milestone, a clear direction is established.

The planning phase is where the customers and team members sit down and determine what will be delivered, and how it should be built. While the project’s direction is specified in the previous step, this is where everyone agrees on a game plan: will we use Visual Basic, Visual C++, or some other program to build the software? Which features are most important, and where do we set our priorities? These are some of the issues discussed at this phase. It is also during the planning phase that risks are reassessed, and estimates for schedules and resources are made. In the end, the project plan approved milestone is reached, providing the functional specification and schedule. The functional specification created here is the combined plans of members in each role of the MSF team model, and details the requirements and commitments of the project.

The functional specification and project plan are passed forward, and used in the developing phase of the process model. Using this information as a baseline, the product or service begins to be built at this stage. The development team sets a number of interim delivery milestones, where the product goes through several cycles of testing, debugging, and fixing. This happens until, finally, all development is complete, and the scope complete/first use milestone is reached

The scope complete/first use milestone is where the product’s functionality is assessed, and it is determined that rollout and support plans are in place before the product is delivered. Documentation is made about features dropped from the current version, and whether they will appear in future versions of the product. In addition, risks and new issues about the product are evaluated at this milestone.

The stabilization phase has a primary focus on finding and fixing bugs that have appeared in the product. This phase occurs concurrently with code development, where the programming of the software product takes place. Once testing at this phase is completed, the product is delivered to operations and support groups, marking the release milestone. At this milestone, the product is shipped and put into service.

One of the outstanding features of the MSF process model is that risks are assessed early in a project. This proactive approach recognizes the risks involved in a particular project, so that they can be dealt with as the project progresses. At each milestone, the team members are able to synchronize their efforts, and address the issues and risks of the project, before critical problems arise that could jeopardize the project’s success.

Application Model

As its name suggests, the application model addresses how applications are constructed to meet the needs of customers and users. This model promotes the use of COM (Component Object Model) components. These components are reusable and can be shared by other applications your team creates. As such, rather than having to rewrite the same code in other applications, you can simply use previously created components.

The application model breaks an application into a network of consumers and suppliers of services. A consumer is a program or component that uses the services of another component. The supplier provides the requested service to this consumer. A service is defined as a unit of application logic, which is used to perform an operation, function, or some sort of transformation on an object. For example, let’s say you were creating an application that retrieves information from a database. To do this, you decide to use COM components (such as an ActiveX component) so you can reuse the code if your customer requires this feature in other applications you create. By doing this, the consumer component would request the information, which could be located on the same machine or across a network, while the supplier would respond to the request for this data service, and return the data.

This creates a multi-tier application (similar to a wedding cake, as shown in Figure 1-1). The user interacts with the application through a user interface and/or programmatic interface, which is the user services tier. The next tier controls sequencing, and enforces business rules and the transactional integrity of operations. The bottom tier is where data is stored, and where manipulations of data take place, like Create, Delete, Read, and Update services. When data is passed back up the tiers, business services transforms the data into information, so that user services can properly display or use it. Though the different tiers are separate from one another, they work together to provide services to the user.

Figure 1: Multi-tiered applications are built on user, business, and data services

In describing multi-tier application development, the application model shows how programs are built on three services that can be consumed or supplied by COM components:

·       user services

·       business services

·       data services

User services are associated with the user interface and/or programmatic interface, provided by units of application logic. The user of the application can be a person or another program. Business services are used to enforce transactional integrity, business rules, and control sequencing. This service also transforms the data acquired from data services into meaningful information that the user can use. Finally, data services provide Create, Read, Update, and Delete services, as well as such retrieval logic as order and joins. This allows business services, which is the consumer of data services, to be shielded from knowing where data is located, or how to access and implement it.

Solutions Design Model

“Give the people what they want” should be the motto of this model. The solutions design model helps the project team anticipate the needs of the user, by bringing the user into the fold. While it is wonderful to discuss requirements with the customer, on many occasions you’ll find that the customer isn’t the person actually using the product. The customer buys the product, while the user is the person who uses it—they aren’t necessarily the same people. It is important to get the users’ input if a solution is to be properly aligned with the true needs of a business.

In the solutions design model, users become involved in the design process. By having them address key issues, such as usability and requirements, the team is able to determine that an application will be used and increase productivity. For example, if the application doesn’t suit the end user’s needs, and creates more problems than it solves, or the interface is difficult to use, the user may decide to keep the old system to get work done. Involving the user prevents problems later, including having the user rely on a help desk for assistance, or not using the product at all.

Beyond involving users, the solutions design model provides a strategy for designing business-oriented solutions that need to be created to suit a specific need. It brings together the team model, application model, and process model so that resources can be focused on areas where they’ll provide the most return.

The solutions design model is comprised of different perspectives. A perspective is an outlook or viewpoint on something, which in this case is the design process of an application. It is used to provide focus to the design process. These perspectives consist of the following elements:

·       conceptual

·       logical

·       physical

The perspectives are used to identify business and technical requirements of an application. The result of using this model is a better assignment of resources in your project, which can make things considerably easier for you.

Conceptual design is where the initial concept of the solution originates. It is here that the team develops an understanding of what the user needs from a solution. Scenarios and models are used to relay this understanding so everyone involved in the project, team members, customers, and users, knows what is needed.

Logical design takes the information gathered from the conceptual design and applies it to technical know-how. While the requirements and needs of customers and users are outlined in the previous design perspective, it is here that the structure and communication of elements in the solution are established. The objects and services, the user interface, and logical databases are among the elements identified and designed in this perspective.

Physical design is where requirements from the conceptual and logical perspectives are put into a tangible form. It is here that the constraints of technology are applied to the logical design of the solution. Physical design defines how the components of your solution, such as the user interface and physical database, work together. Performance, implementation, bandwidth, scalability, reliability, and maintainability are all resolved and implemented through physical design. Because this perspective applies previous designs to a concrete form, you are able to estimate what resources, costs, or scheduling will be needed to complete the project.

In dealing with the three perspectives, it is important to realize that they are not a series of steps with clear cutoff points. You don’t have to reach a specific point in one perspective, before moving onto the next. In fact, one area of design may be used in conjunction with another, so that while one part of a solution is designed conceptually or logically, another is being coded or implemented into the final product. Since there are no stages with cutoff points or boundaries, you are able to return to the different design perspectives as many times as necessary. This allows you to refine your design, by revisiting and redesigning your solution.

Enterprise Architecture Model

Like the previous model, the enterprise architecture model is made up of four perspectives to help provide focus to key issues of a project:

·       business architecture

·       application architecture

·       information architecture

·       technology architecture

Enterprise architecture is a model that provides guidelines for planning, building, and managing technology infrastructures. It helps to integrate the business, by making sure that changes throughout the enterprise are consistent, and meet the needs of the business.

Business architecture is used to define how the business works. It determines what the business does, its strengths, and its future. By having a description of how the company works, and the functional and cross-functional activities they perform, a better understanding of requirements is achieved. You’ll remember from the mention of milestones earlier, that the first milestone in MSF’s process model results in the vision/scope of the project. The business architecture perspective aids in this, by establishing the perimeters or boundaries for requirements and development of vision/scope.

The application architecture is used to determine issues dealing with current applications and application models, and what changes may be necessary to these areas. Here it is determined what application models are currently used, integration issues unique to the current system, and where backlogs exist. It defines the interfaces, services, and application models needed by a business, which are translated into development resources that are used by project teams. Application architecture provides the guidelines necessary for developing new applications and determining whether new application models are required.

Information architecture describes how data and information are handled in a business so it can run effectively, and describes what the company needs to know to run the organization’s business processes and operations. This includes such things as determining functional data requirements, information needs, and policies dealing with data management. This perspective also describes how information is bound to workflow. It is important to remember that data stores, such as databases, documents, and spreadsheets, exist not only on servers, but on the desktop computers prevalent in most enterprises. Because of this, the information architecture deals with identifying where most of the critical information in an organization resides.

Technology architecture is a perspective that describes standards and guidelines for laying out the software and hardware supporting an organization. This perspective includes such things as operating systems, client/workstation tools, and hardware used by workstations and servers, printers, modems. This perspective provides you with a vendor-independent, logical description of your organization’s technology infrastructure.

The beauty and value of the enterprise architecture model is that it doesn’t look at the enterprise from a single, stagnant viewpoint. Though comprised of four perspectives, there is only a single architecture that is being looked at in different ways. As we’ll see later in this chapter, this model allows you to plan as you build an enterprise’s architecture, resulting in a comprehensive view of an organization’s technical infrastructure.

Infrastructure Model

While the previous model deals with the software and hardware elements necessary in computing, the infrastructure model defines all of the resources needed to support this environment. Infrastructure, under the MSF definition, is the total set of resources needed to support an enterprise computing environment. These resources consist of the following:

·       technologies and standards

·       operational processes

·       people and organizational resources

Technologies and standards deals with the software, hardware, and standards that we introduced in the enterprise architecture model. Operational processes consist of the operating procedures, policies, and services that are used in the enterprise. These are the rules and regulations that are abided by in the organization. Finally, people and organizational resources deal with the skill sets and management available in the organization. These are human resources that are available as personnel, and can add their skills or management expertise to a project.

The infrastructure model takes the knowledge of previously mentioned models, and applies it to rolling out a successful infrastructure. In doing this, you are reusing the expectations, functions, and roles of other models, rather than learn and apply new principles. The models used in the infrastructure model are the team and process models.

In using these models as part of infrastructure, there are some differences from the original models. In the process model, some names are altered to reflect their use in infrastructure. However, it is still milestone-based, and incorporates the principle of using tradeoffs. Priorities are made, as are decisions to sacrifice certain areas of a project so another may succeed. As is the case with process, the infrastructure model makes such tradeoffs in the areas of schedule, scope, or resources. Tradeoffs are covered in greater detail later in this chapter.

In the infrastructure model, team roles are expanded with wider responsibilities, and new roles are added to accommodate the task of such projects. The three roles added to the role of logistics are the following:

·       systems management

·       help desk

·       communications

Systems management is responsible for maintaining accountability for the systems and technology. This accountability is inclusive to the continued operation of this technology. Help desk is responsible for providing assistance and ongoing support to the end user. Finally, communications is responsible for maintaining video, voice, and data communications in the project.

TCO Model

The TCO (Total Cost of Ownership) model works on the basic premise that optimizing costs equals a better return on investment (ROI). In other words, by spending less, you have more money in your pocket. The TCO model approaches this objective by analyzing the cost areas in a business in a rational and proven method.

The first thing to realize with TCO is that cost isn't necessarily a bad thing. You could conceivably reduce the TCO of your company by selling every computer in the building. . . The MSF TCO model addresses the value of elements that have costs attached to them. Rather than attempting to minimize the total cost of ownership, the TCO model seeks to optimize it. This allows the value of such elements to be retained, while lowering costs.

The key word in all this is optimizing. In the TCO model, there are a number of factors that can be optimized in an organization. :

·       Cost model elements  Used to show relative costs that are based on the averages in the industry.

·       Components The software and hardware used in an organization.

·       Operations The elements required by the computing environment to operate properly,.  such as maintenance, help desk, disaster recovery, and training.

·       Management The administration of such things as the network, data, systems, and repair.

·       Hidden costs Includes such things as vendor management, misdiagnosis, and end-user training.

·       Downtime and other costs Includes such things as downtime, development, and testing.

When looking through these cost areas, you can see they encompass all areas of the computing environment. In addressing these areas, it is important to remember not only the cost of items, such as hardware or software, but also the labor required to develop, implement, and support them. As mentioned earlier, labor can cost considerably more than an actual hardware component, or the cost of a computer used to develop software. A majority of cost is associated with labor, and it is important to include that when estimating cost figures related to these areas.

In optimizing these cost areas, the TCO model uses an ongoing three-phase process. Although when one phase is completed you move to the next, the process continues and is constantly working to improve itself. The stages consist of the following:

·       benchmark and baseline phase

·       improvement phase

·       management phase

In the benchmark and baseline phase, you use the TCO model to calculate cost baselines, benchmarks, return on investments (ROIs), and validations. The benchmark is the total cost that’s based on averages in the industry, while your baseline is the actual cost of the acquisition, management, and retirement of technology. Information gathered at this phase is carried into the improvement phase, where ROI is calculated. Based on a strategy you create, this is calculated by simulating the impact of your recommendations on improvement and estimated cost savings. Finally, the management phase is where you measure what you actually achieved against what you hoped to achieve. The results of your work are compared to your objectives, which either validates or invalidates the strategy that was used.

On the Job: People with a background in networking are probably familiar with the importance of baselines and benchmarks. Without them you can’t measure the normal or original condition. They give you something to compare changes to, and determine if things are better or worse than after you implemented new strategies.

Mixing and Matching Models So They Work for You

Using the MSF models isn’t an all-or-nothing affair. You don’t just pick one model for a project and run with it. The MSF models are mixed and matched together to best suit the project you’re working on. For example, let’s say you’re working on a project designing an intranet. Though you may recognize immediately that you’ll need to use the infrastructure model, you’ll also have to implement the team and process models in your project. Why? Well, for one thing, you won’t get very far if you haven’t put any members into a team to work on the project. The process model is then used to focus the team.

Table 1-1 shows some combinations of MSF models that Microsoft suggests you use on certain projects. As you go through this table, you’ll notice the importance of the team and process models, as they appear in each combination. These two models are fundamental to the common projects you’ll encounter.

Exam Watch: Without diminishing the importance of the other models in the framework, it is especially important that you understand the team and process models. These are the two most used models and you can expect to see a considerable number of questions regarding them on the exam.

Table 1: Suggested Combinations for MSF Models

On the Job: In using these models it is important to realize that their success doesn’t revolve around what technologies they’re used with, but how well they’re used. It is important to understand the nuances of each of these models as you use them. Rather than speeding through a project using MSF, with this book in hand like a recipe book, move slowly. It is more important to do things correctly, than quickly with MSF models.

Identifying Key Areas Where IT and Business Are Changing Together

The Information Age is significantly more complicated than previous ages. Global competition, the Internet, and government legislation and regulations have had an enormous impact on the business world, and subsequently, on Information Technology. We live in a world where people expect things immediately. This has led to one major fact in IT and business: those who get their product to market first and fastest, usually reap the greatest rewards.

As the face of business changes, Information Technology must keep up. This means that effective and proven measures must be taken to ensure a product meets all of the required standards, while still keeping within the constraints of schedules and budget.  Throughout the Information Technology lifecycle, MSF helps address these issues to ensure the success of a project.

In this section, we’ll look at the key principles and methods of the IT life cycle, and see how the Microsoft Solution Framework applies to it. We’ll also look at how business and IT have changed together, and inspired the need for flexible business solutions.

Key Principles and Methods for the IT Life Cycle

Information Technology has a life cycle, made up of three parts:

·       planning

·       building

·       managing

The first stage in the life cycle is to plan your project. Planning involves creating strategies and evolving an enterprise architecture that will drive, or is adaptable to, changes in the business. This moves into the building stage, where your product is moved from the paperwork of schematics to a physical form. Building takes information from the planning stage, and ensures that the business-driven application is created on budget and on schedule. From here, the product is managed, allowing it to be maintained and improved. In looking at Figure 1-2, you’ll notice that the life cycle doesn’t necessarily end with management, but flows back into the planning stage. This allows for new versions of the original product, causing this cycle to repeat itself indefinitely.

Figure 2: The Information Technology life cycle

The first part of any mission is planning. If you haven’t done this, but decided instead to take the “fly-by-the-seat-of-you’re your-pants” approach, you’re in for some serious problems. Any medium to large project you work on can seem very much like a large-scale military attack. You need to decide what troops you’ll need, figure a plan of attack, and plan a method of deployment. While this can seem relatively simple in a small organization, the complexities of projects tend to grow with the company.

In the planning stage, you determine current and future requirements of an organization. Where are you now, and where do you need to go to have future competitive advantages?  Strategies are created at this point so you can reach the objectives you set for the teams you create. In doing so, you also use the enterprise architecture model, to drive and adapt to changes in your organization.

Once you’ve finished creating the necessary strategies and gathered the information you need, you move into the building stage of the IT life cycle. However, don’t think that the bulk of your work now consists of coding. A weighty percentage of large IT projects fail at this point for a number of reasons. Information gathered to this point is insubstantial, such as poor or incomplete specifications, goals are unclear, the requirements are steadily changing, quality of coding is inferior, or there may be a lack of scope. It is here that you face some of the biggest risks your project will face.

Risk management is used at this point to identify and deal with areas of the project that can jeopardize success. In dealing with risks, you could simply put projects on hold until technologies, industry standards, and systems become commonplace. In doing so, you avoid many of the risks that present themselves in a project. However, you are also avoiding many of the opportunities that they present. Remember that the first ones to get their product to market usually reap the greatest rewards. When you avoid risks, you are avoiding opportunity as well.

This leads to two ways of dealing with risks in a project: proactive or reactive. Reactive means to wait until a risk turns into an actual problem and deal with it then. Proactive risk management means to monitor and deal with risks before they become a problem. As we’ll see in Chapter 3, Risk Management, MSF’s risk management process uses a proactive approach, so you get the most rewards, with the fewest problems.

During this stage in the IT life cycle, the team model is used to implement small, focused teams on projects. In placing people in team roles, you should try to keep members in the same roles on different projects. This gives members a comprehensive understanding of their particular role, across an expanse of different projects.

At this time, the process and solutions design models also come into play. During the building stage, you also need to consider and balance the budget, schedule, and resource constraints, which are the parameters of the process model. Using this model, you can perform tradeoffs, so that one aspect of a project doesn’t threaten the project as a whole. Later in this chapter, we will discuss tradeoffs in greater depth. The solutions design model is used during the building stage to acquire input from users, determine and fulfill their current and future needs, and provide focus in creating the product. Using these models you can build software products that meet and possibly exceed a user’s expectations, while staying on schedule and budget.

Now that you’ve built and made changes to the enterprise by creating or updating new and/or improved software, or deployed a new infrastructure, it must be managed. Like risks, the MSF approach to managing change is proactive. Organizational change, or changes in the computing environment must be dealt with accordingly, if people are to accept and use those changes.

In the management stage, the project is not looked at as completed, but viewed with an eye toward the future. Changes are evaluated, costs are analyzed, and areas of improvement are noted. Using the TCO model, the strategies used are evaluated for their effectiveness. Any areas of a solution that require intensive administration or maintenance or support are considered candidates for an integrated redesign using the enterprise architecture model. Information gathered at this stage can then be reapplied to future versions of a product.

Addressing the Growing Demand for Flexible Business Solutions

At the dawn of the 1990s, jobs began to be cutback and downsized. While downsizing was nothing new, corporations seemed to take this approach with an unparalleled voracity. According to U.S. government statistics, approximately 1.7 million manufacturing jobs disappeared between 1988 and 1993. While assembly line jobs are normally associated with manufacturing, it is important to note that a sizable portion of this number were back-office jobs. Despite the fact that they’re a minority of the workforce, the human face of laid-off workers in the 90s belonged to that of white-collar professionals. Between 1988 and 1995, 18.6 percent of all middle management jobs disappeared. Those still remaining in white-collar positions had to take up the slack. This meant taking on more duties than may have originally been in their job description.

These statistics illustrate the need for flexible business solutions in the enterprise. Flexible business solutions are applications that are adaptable, easily modified, and have the feature of a consistent interface. Such applications allow users to perform more activities and perform more complex duties, without having to learn new applications. Creating such applications requires the use of a good model, and that is where MSF’s application model comes into the picture.

The application model allows you to design applications for flexibility, by outlining the development of multi-tier applications. These applications are built on user, business, and data services. By separating the application into a network of services, this model allows the features in an application to be reused across physical and functional boundaries. This is done through the model’s promotion of the component object model, which is also referred to as COM.

ActiveX Controls and OLE (Object Linking and Embedding) are built on the component object model. It is through this model that objects in an application are able to expose their functionality to other COM components or applications. COM isn’t an actual programming language; it is a standard that defines how objects can expose themselves, the life cycle of an object, and how object exposure works across networks and processes. The beauty of COM components is that they are reusable, so rather than having to write the same code over and over, you can invoke existing COM components from existing applications. Since the interfaces for these components would be the same, regardless of the application using them, the user doesn’t need additional training to perform a task.

Since COM is a platform-independent, distributed, object-oriented standard, it allows business applications and systems to be integrated with Internet technologies. This means you can use the application model and COM to create applications that can access, or be accessed from the Internet. Cross-platform support allows a user to access a COM component from Unix, Windows, or other operating systems, and still use its functionality.

The application model sets out the rules, relationships, and definitions that form the application’s structure. This allows consistency across all of the applications a user may use on the network or local computer. Users are able to easily move from one application to another on their desktop.

Identifying Problems IT Must Overcome to Drive Business

There are two ways IT can drive business: forward or into the ground. Unfortunately, it’s much easier to do the latter than the former. When you think of an enterprise like a human body, IT is the brain that runs the nervous system and which keeps an organization running. If you don’t believe me, take a look at how many people suddenly stop working when a network or computer system goes down. When you see how important your role is, you see how vital it is to address problems properly, so the business can keep functioning.

There are two sources of problems you’ll encounter in IT: technological and human. While each brings their own benefits to an organization and the design process, they also bring their own difficulties. There is no way of avoiding these two sources so MSF provides ways to deal with them.

For technology, you must deal with the systems, utilities, and infrastructures that keep the organization up to speed. As the number of people in your organization grows, these areas must be improved to accommodate the population growths of users and enhancements in technology. For technology infrastructure, the enterprise architecture model provides guidelines to plan for future needs, while building to meet and manage current technological needs.

For the human source of problems, a big difficulty in IT is anticipating the needs of users. . It is important to get users’ input during the design process. While this brings forth difficulties of its own, as we’ll see later, the benefits of user input far outweigh the problems.

Technology Infrastructure

Legacy systems and changing technologies can make you think you’re fighting a losing battle. To support growth and drive business, the technology infrastructure of an enterprise needs to be constantly kept up to date. Operating systems, desktop and server hardware, network services, security, and APIs are all part of the technology infrastructure that needs to be planned, built, and managed.

Unfortunately, you can experience all sorts of problems when dealing with this issue. You may find it difficult to make any sort of change to the infrastructure, because you’re having a hard enough time managing the current systems. If you’re supporting legacy systems, you may find it difficult to define new technical guidelines. If you do manage to set such guidelines, you may find technologies have changed once standards are in place. If this isn’t the case, you may find that departments in your organization prefer old systems and rebel against changes. The list of problems you may encounter with technology infrastructure can seem endless. Fortunately, MSF provides some hope.

The enterprise architecture model deals with technology infrastructure by providing a set of guidelines for planning, building, and management. With this model, planning takes place constantly as the business and its needs evolve and flourish. This “planning while building” doctrine helps keep you on top of the current system, while allowing you to plan ahead.

Without a means to dealing with technology infrastructure properly, there can be obstacles that go beyond the technology itself. Schedules may be set with an overly optimistic view of deployment, without taking into consideration that the application works as it should. You may find that projects are put on the back burner until certain technology issues are dealt with. If there is a need to decide on new technologies coming out, you may find your organization has no criteria for making such an evaluation. Such incidents not only deal with technology, but the practices and people in your organization.

While enterprise architecture focuses on technology infrastructure, the infrastructure model aids you with the total resources necessary to support the computing environment of the enterprise. This not only deals with the technology infrastructure dealt with in enterprise architecture, but the technologies, standards, operational processes, people, and organizational resources needed in the computing environment. This model takes the roles and principles of the team and process model, and applies it to an infrastructure that works.

Anticipating User Needs

“Always leave the people wanting more” may be a great philosophy in entertainment, but it doesn’t work in an application. It’s vital that a program meet the needs of the user. Unfortunately, managing user involvement can be difficult at best. In fact, there are many development organizations that don’t even bother involving users in project. The philosophy here is that “designing applications would be great, if it weren’t for the users who used them.”

When Windows 3.1 was the operating system of the day, users were screaming for a newer, better interface. When Windows 95 came out, many people disliked the new user interface, and decided they liked the old one better. People resist change in general, so it’s not surprising that this resistance to changes in technology carries over to users. . Users will have different preferences to layout or the color or look of interfaces. Worst of all, when new features or functionality are delivered, users may want something different from what they originally asked for. The solution design model is used to help anticipate user needs and overcome many of the obstacles in a project. This model has users brought into the project during the design process, so that they can address issues of usage before they become problems that support staff must deal with. By involving users early in the project, the benefits drastically outweigh any headaches such involvement might cause.

End users are the people who use the product on a day-to-day basis, and can tell you what specific needs the solution must address. These people work in the trenches with the product, and will work the software harder and considerably longer than team members in testing ever will. They will also be able to tell you what they require to properly use and keep using the product. By getting users involved, you not only find out the business and technical requirements of a user, but also get input on issues that will affect the product’s success.

Analyzing the Scope of a Project

When the vision for a project is being set, it’s like writing a Christmas list. This isn’t to say that nice customers get what they want, while the naughty ones get a product that has all the features of a lump of coal. The vision is the features and functionality you’d like to see in a product, and is much like a wish list. And like that wish list you make at Christmas, somewhere between the comic book and the pony, something’s got to give! That’s where scope comes into play. Scope is the opposite of vision, and reigns in the features included in the vision, until it becomes something reasonable that the team can deliver.

There are many reasons for analyzing the scope of a project. One important reason is that projects can get so big that they may take too long to complete. Too many features can extend the development of a project to the point where it loses its value. If a project takes more than a year to complete, it may lose significant value to how fast technology evolves. If the project needs to be released by a certain point—such as income tax programs that need to be released before April—the product becomes completely worthless after a specific date. Besides time constraints, it is important to realize that the longer it takes to create a product, the more costs are involved. It’s not difficult to suck the value out of a project by allowing the cost or labor and other resources to get out of hand.

Another reason for analyzing the scope of a project is morale. It is easy for team members and stakeholders to become disillusioned with a project. This can result when a project takes too long to complete, the amount of features and work involved being overwhelming, or because there appears to be no end in sight as the schedule keeps getting pushed up or new features keep being added. As team members become disillusioned, their productivity will drop. This can be avoided by determining and setting the scope of a project, and by using the models and principles of the Microsoft Solution Framework.

Exam Watch: While morale is mentioned in several areas of this book, don’t expect to see questions regarding this on the exam. It is an incredibly important issue in the real world and can greatly affect a project. . However, while the models and principles of MSF can have the effect of improving morale, questions directly dealing with the emotional well-being of your team members and stakeholders aren’t an objective of the exam.

Assessing Existing Applications

Before you create the specifications for a new application, and set developers to work on coding a product, it’s important to assess existing applications. There may be applications available that already suit the needs of the customer on the market. Buying software off the shelf may be cheaper than creating a new application that performs the same tasks. If you decide a new application does need to be created, applications that already exist on the system may provide services that your new program can use. Rather than rewriting the same code over and over, there may be existing components that can be incorporated into your software product. The reason to assess existing applications is simple: it can save you a considerable amount of needless work.

The application model promotes the use of COM components, which are reusable and can be shared by other applications, by breaking the application into a network of consumers and suppliers of services. By using COM, components from one application are able to use the services of other applications. Because you are able to use components that were originally created in other applications, you don’t have to rewrite the same code for a new application. A consumer component can be reused to access the services that were written in a previously created server component. While COM allows you to access the services of existing applications, you should determine whether a new application that uses COM should even be built. There are numerous off-the-shelf programs available and you should determine whether to use them or spend time developing an application.. In addition to buying or obtaining existing applications, you may need to work only with programs that already reside on user desktops. For example, let’s say it is proposed that a database application should be created, because users are having problems understanding the complexities of Microsoft Access. You could spend considerable time creating such a program, or you could simply create forms in Microsoft Access that make the user’s experience easier. By assessing existing applications, you can determine if it’s cheaper to purchase or obtain programs that are already on the market rather than develop them. You can also determine if there is really a need for a new program, or if existing applications merely need to be reconfigured for users.

On the Job: In dealing with customers, it is important to remember that the reason they’re talking to you is because they aren’t as knowledgeable as you. While you may know that they’re asking you to build a product that already exists – and can be put on their company’s desktops at a fraction of the price of what they’re paying you – they may not know it exists. Once I had a company ask me to create a browser for their intranet. As I talked to them, they basically said they wanted the features of Microsoft Internet Explorer, but wanted their company logo, name, and a few other items. I suggested that rather than having me create a new program, I use the Internet Explorer Administration Kit to set up many of these features on their existing Internet Explorers. After this, I simply configured the Explorers they way they wanted them. Doing so saved them loads of money, and saved me a workload that wasn’t even necessary.

Anticipating Changes in the Business Environment

It seems that a week doesn’t go by without some company merging with another. If the organization you’re working for experiences such a merger, you can expect changes to networks, standards, policies, and other areas that will influence Information Technology. If one company in a merger is dominant over another, then you can expect the dominant company’s procedures and systems to become the norm. This is great if you’re working for the dominant business in the merger, as you won’t experience much in the way of change. If your luck is as good as mine however, you’ll be on the receiving end of having to learn new policies and procedures, implement new systems, and the list goes on.

It is important to keep abreast of changes in the business environment. If you’re working in the IT department of a company, this means looking at the situations affecting your workplace. This means reading the information that comes across your desk (for example, memos), and having open discussions with customers and users.

The Microsoft Solution Framework recognizes the value of customer and user input. Customers are the people who purchase the product, and can provide higher-level information about changes expected in the business. They can provide information that the end user may not even be aware of. For example, they can tell you whether the organization will be connecting to the Internet, and whether users of the product will be getting access to the Net. Users are the people who actually use the product you’re hired to create, and the solution design model acknowledges the value of their opinions. Users work in the trenches with products, and may be aware of business changes that people higher in the company are not even be aware of!  Remember that these users are hired for their special skills, and have knowledge that people commissioning the product’s creation may not understand or know about. If you were creating an application for the accounting department, the accountants and bookkeepers would know about changes such as payroll policies and accounting procedures that people above them in the company don’t know about or understand.

Another way to anticipate changes in the business is to stay current with changes in technology, industry standards, and other areas that revolve around the computing environment. It is important to know that things are changing, so you can anticipate changes that will be reflected in their products. For example, when Windows 95 first came out, it had a dramatic change in the features and functionality of applications. If you weren’t aware that Windows 95 could use 32-bit applications, you would continue creating 16-bit applications as if they were for previous versions. Changes in operating systems and networks are inevitable at one point in the business. However, it is important to determine whether these changes will affect the business. Perhaps the company likes using Novell NetWare 3.12, and has no intention of changing anytime soon. It is essential to discuss changes with customers, users, network administrators, and people who will determine how and when such technological changes will affect the business.

Estimating the Expected Lifetime of the Solution

Everything in Information Technology has a lifetime associated with it. Nothing lasts forever, and there comes a time when your application will either need to be put out to pasture, or revised and recoded into a newer version. It is important that the expected lifetime of a solution be considered before you write your first line of code.

As you might expect, the difficulty of estimating a solution’s expected lifetime ranges from child’s play to what seems like brain surgery. For some applications, as mentioned in the cases of income tax programs, the lifetime is straightforward—after April a new version needs to be created, or the project is put to sleep. Most applications, however, aren’t so simple, and you’ll need to develop some researching skills to determine the lifetime. Having open discussions with customers and users can answer many questions for you. It’s a simple principle: talk with the people who work with the application, and have the greatest knowledge of what the solution is for, to determine how long it will be used. Users of accounting programs can tell you when new legislation is released, while other users can tell you when new policies, procedures, or standards will make the current version of a product obsolete. Sources of technical information—such as TechNet and Microsoft’s web sites—can help you determine when certain changes in computing will make a current version of a software product obsolete. Similar sources dealing with the business problems your solution addresses can also help you determine this.

Beyond going to the source, there is one rule of thumb to keep in mind when dealing with computing environments: technology changes quickly, and upgrades need to be performed at least once every three years. This means that hardware will need to be upgraded every two years to keep up-to-date with the latest standards. Since everyone else is releasing new solutions at least once every two or three years to meet with these standards and system requirements, you can estimate that your solution could have a maximum lifetime of three years. When creating mainstream solutions that are to be used by vast numbers of users in the general public, you can use this for estimating.

If you are creating solutions exclusively for the IT department, you can expect that the three-year maximum lifetime won’t apply in many cases. For example, one large corporation I did some consulting for has only recently upgraded the computers to Pentiums. Before this, Information Technology was forced to create 16-bit and watered down 32-bit applications, as this was all that the older computers could handle. Solutions created far later than three years ago were still in operation. In such cases, it’s important to discuss with upper management when such changes will come into play. It is pointless to estimate an application’s life at two years, if technological advances won’t be implemented in the computer environment for another seven years.

In many cases, due to the swiftness of such changes in technology, you can also estimate that if your application takes longer than one year to create, most of its value has been lost. It is important that your applications make it to market as fast as possible so that you don’t lose the value it offers on lost time. As mentioned earlier in this chapter—and expanded on throughout the book—the models and principles can help you get your product out, so that most of its lifetime isn’t wasted on design and development.

By estimating the expected lifetime of a solution, you can determine when the next version of a product should start to be designed. It also helps you decide if you should start on a current project, or put it on hold until new policies, legislation, procedures, or technology come into effect. If your solution has an estimated lifetime of a year and it will take six months before its released, this means the current version will have a lifetime of six months from release. You will also experience instances where the expected lifetime will be in the negative numbers. For example, if you have a product with a lifetime of six months, and it will take eight months to create, that version has exceeded its lifetime before it’s even been released!  In such cases, it is far better to wait or start work on plans for the next version.

Assessing Time, Cost, Budget, and Benefit Tradeoffs

In any project, there are elements that can help move a project forward or act as obstacles to success. Three areas that regularly go either way in this regard are the following:

·       schedules

·       budget and cost

·       features

When it looks like there isn’t enough time to complete the project, there are too many features to implement, or the costs of a project exceed the current budget, tradeoffs may become necessary. A tradeoff is where one element of a project is sacrificed so that another may fulfill the current needs. For example, costs may be cut or the schedule may be shortened so the project doesn’t go over budget. The process model helps you make better development tradeoffs, by defining variables and priorities that affect the issues of time, cost, budget, and benefits.

At one point or another, you’ve probably had someone tell you “we need it yesterday.” Whether you’ve said it or thought it, the answer to this request may have been “fat chance!” There will be times when not enough time is given to complete a project. Perhaps your past performance was so impressive, that it was assumed you could do the same on a more complex, or time-consuming project. Whatever the reason, time becomes an obstacle to the project’s success.

The time allotted to projects is constantly shrinking. While pioneers in software development had considerable time to design, develop, and deploy applications, your teams will have time measured in weeks to complete a project.  While you’ll often find that the time scheduled for a project is enough to complete it, every once in a while you’ll need to sacrifice time for another area. For instance, more people may need to be put on a project to meet the schedule.

Time can be a critical issue with software development. This is apparent when considering programs that deal with the Year 2000 (Y2K) problem, or income tax applications that are useless after April of each year. You’ll remember that at the beginning of the process model, the team schedules are submitted and put together into a large schedule. During the creation of such schedules, it is important that time-critical issues be scrutinized. Even if the project is on time and on budget, if it goes over a certain date, the program may no longer be needed.

On the flip side of this, projects can take too long to develop, and get too expensive. One fact that every book seems to skip over is that software development projects are supposed to make money!  Revenue is an essential factor in any software being developed, and there isn’t a product available that doesn’t expect some productivity to increase, and money to be saved or made. Every project has a budget associated with it, and costs for producing the software incorporated into it. If the costs involved in a project cause it to go too far over budget, then a project may break even or run at a loss, thereby killing any reasons for starting the project in the first place.

Trading off the budget to keep schedules and features on track is often the easy way out when you’re working in a large company, but it can come back to bite you. When you’re working in the trenches, it’s easy to forget that the company has only so much money to keep your mission going. The process model helps to prioritize areas of a project, so that you don’t kill your budget when making tradeoffs. The simple question, “What is most important” is asked, allowing team members and stakeholders to determine what needs are most important to a project, and where cut-off points exist. By making certain features a priority, you are able to determine what can be dropped from the current project, and keep your budget from becoming victimized.

Versioned releases resolve many of the problems we’ve discussed. If there isn’t enough time or money to include certain benefits in the current release, the features you planned to include can be passed forward. You’ve probably noticed versioned releases in using various operating systems like Windows, NT Server or Workstation or applications like those in Microsoft Office. Such programs have version numbers associated with them. For example, the last 16-bit full release of Windows was version 3.1. However, when they implemented the upgraded kernel for this operating system, it became Windows 3.11 (not to be confused with the Windows 3.11 associated with NT). This decimal number was used to indicate a minor update to the existing program. When Windows 95 was released, it contained major changes to the previous system, and was labeled as version 4. By using versioned releases of an application or system, you are able to improve or incorporate planned features in your application, without destroying your budget or schedule.

Versioned releases also deal with another issue, common to project team members: ego. In a good team, members are proud of the features they’ve personally worked on or invented. Each member thereby feels that the feature they’ve worked on is essential to the product, and absolutely must be included. One problem with this is that there are so many features that they can’t all be included by the release date. Another is that every time the product is almost ready to be released, someone decides to add more features. By versioning releases, such features can still be incorporated into the product, but will appear in the next version.

Certification Summary

The Microsoft Solution Framework consists of principles and methodologies that have been proven in the real world. MSF is comprised of the team, process, application, solutions design, enterprise architecture, infrastructure, and TCO models. Each of these models help to ensure the success of a project, and can be used together to enhance and improve a project.

In using MSF, its models and principles are applied to individual projects. In doing so, certain assessments and evaluations need to be made. The lifetime of the solution, changes in the business environment, tradeoffs that need to be made, and whether certain features should be included in current or future versions are addressed. MSF aids in these evaluations and assessments.

Two-Minute Drill

·       MSF consists of seven models, which can be used individually or combined: Team Model, Process Model, Application Model, Solutions Design Model, Enterprise Architecture Model, Infrastructure Model, and the TCO Model.

·       MSF’s team model outlines well-defined roles for members of the team. Each role has its own mission, for which members in that role are responsible.

·       The MSF process model clarifies what people are working toward, and the progress achieved from that work.

·       As its name suggests, the application model addresses how applications are constructed to meet the needs of customers and users. This model promotes the use of COM (Component Object Model) components.

·       User services are associated with the user interface and/or programmatic interface, provided by units of application logic.

·       Business services are used to enforce transactional integrity, business rules, and control sequencing.

·       Data services provide Create, Read, Update, and Delete services, as well as such retrieval logic as order and joins.

·       The solutions design model helps the project team anticipate the needs of the user, by bringing the user into the fold.

·       Conceptual design is where the initial concept of the solution originates. It is here that the team develops an understanding of what the user needs from a solution.

·       Logical design takes the information gathered from the conceptual design and applies it to technical know-how.

·       Physical design is where requirements from the conceptual and logical perspectives are put into a tangible form.

·       Enterprise architecture is a model that provides guidelines for planning, building, and managing technology infrastructures.

·       Infrastructure is the total set of resources needed to support an enterprise computing environment: technologies and standards, operational processes, and people and organizational resources.

·       The TCO (Total Cost of Ownership) model works on the basic premise that optimizing costs equals a better return on investment (ROI).