MSF Design Process

Ultimately, the aim of the Envisioning and Planning Phases is to do what's necessary to build an effective and useful application. Part of that work is to actually "architect," or design, the application. Although it is possible to use the MSF Development Process Model with any number of design methodologies, the MSF Design Process is a thorough, effective tool that ensures that the architecture of an application reflects the needs of the users and the business. At the same time, the MSF Design Process integrates the application with the existing enterprise architecture and with other applications. The MSF Design Process is especially effective for N-tier development, and is, in fact, aimed at that type of application.

Because the task of design resides primarily in the Planning Phase, we will take some time in this chapter to examine the MSF Design Process. First we'll present an overview of the three parts of the process. Then we'll explain how this process relates to the Planning Phase and how certain deliverables of the Planning Phase are dependent on the output of the Design Process. Finally, we'll examine in detail the three parts of the process, including their own internal deliverables.

Overview of the MSF Design Process

The MSF Design Process consists of three distinct types of design work: conceptual, logical, and physical. Each of these generates a model of the same name: the Conceptual Design Model, the Logical Design Model, and the Physical Design Model.

Each part of the process approaches the design task from a different perspective and defines the solution differently, as shown in Table 6.2.

Table 6.2 Design task approaches to the three parts of the MSF Design Process

Type of design work	Perspective	Action
Conceptual	Views the problem from the perspective of the user and business	Defines the problem and solution in terms of scenarios
Logical	Views the solution from the perspective of the project team	Defines the solution as a set of cooperating services
Physical	Views the solution from the perspective of the developers	Defines the solution's services and technologies

The output of each part is used as the input for the succeeding part, as Figure 6.2 illustrates.

Figure 6.2 Outputs of the three interdependent design process models

The goals of the three parts are:

• Conceptual Design Identify business needs and understand what users do and what they require. Conceptual Design generates scenarios that reflect complete and accurate requirements, by involving the customer, users, and other stakeholders.
• Logical Design Organize the solution and the communication among its elements. Logical Design takes the business problem identified in Conceptual Design scenarios and formulates an abstract model of the solution. Following the workflow in Figure 6.2, Logical Design takes the scenarios from Conceptual Design and produces objects and services, user interface prototypes, and a logical database design.
• Physical Design Apply real-world technology constraints, including implementation and performance considerations, to the outputs of Logical Design by specifying the details of the solution. The outputs of Logical Design are used to produce components, user interface specifications, and physical database design.

The MSF Design Process moves from tangible requirements (use cases) to an abstract application design (Conceptual Design), then to a rationalized application design (Logical Design), then to a concrete application design (Physical Design), and finally, to the tangible product. Conceptual Design is the initial translation of the use cases (the language of the users) to the application design (the language of the application developers). Logical Design is the developers' perspective and serves as a translator between the high-level application concepts—the business and user requirements—and the detailed application design.

Conceptual Design does not take into account the approach or the technologies needed to build the solution. Rather, Conceptual Design corresponds to rough sketches and scenarios for building a house. These are easily understood models jointly created by the customer, the user, and the architect. It is the translation of the business and user requirements from the language of the users to the language of the developers.

Logical Design starts to get into the details of the application that the team will build to fulfill business needs and user requirements. Logical Design thus corresponds to the floor plan and elevation of a house, where elements such as spatial relationships are organized. In this part of the process, the architect's team lays out the design's relationships and communication paths.

Physical Design addresses the technology that will be used. This design adds detail to the architecture and reflects real-world implementation constraints.

Essentially, the different parts of the MSF Design Process address the needs of different "readers" while still serving as parts of a functional whole. Instead of forcing readers to digest what may be a very large and detailed document, this model allows readers to focus only on the information—the part of the whole—that is pertinent to them. The model also allows the use of formal or informal techniques as appropriate.

The design evolves as each step in the process contributes more detail to the Functional Specification. And as the design evolves, every aspect is traceable from any point back to the original business problem, for verification and testing purposes.

Although the MSF Design Process resides primarily within the Planning Phase of the MSF Development Process Model, the work of design often begins before the Planning Phase is officially started, and it continues to some extent up to the point when the code is frozen (near the end of the Developing Phase). The baselines for each of the three parts of the process are established during the Planning Phase. As shown in Figure 6.3, the three design activities occur in a staggered, parallel manner, with the early output of one activity signaling that the next activity should begin.

Figure 6.3 Overlapping, iterative, and spiral qualities of the MSF Design Process

The Conceptual Design activity begins when the team agrees upon a vision statement, which may occur before the team reaches the formal Vision Approved Milestone. The Logical Design and Physical Design activities parallel those of Conceptual Design, and all three sit squarely in, but are not limited to, the Planning Phase of the MSF Development Process Model.

It is the parallel execution of all three design activities that allows the product's conceptual, logical, and physical design to have the following three qualities:

• Overlapping The activities are parallel, with Conceptual Design typically starting first, followed by Logical Design and then Physical Design. They are not sequential, so one doesn't have to finish before the next can begin. In fact, Logical Design and Physical Design may begin even before the baseline for Conceptual Design is established.
• Iterative The activities have their own cycles of validation, design testing (as opposed to code testing), and redesign.
• Spiral Each iteration of all three activities represents progress toward the Project Plan Approved Milestone of the Planning Phase.

Obviously, a minimum degree of sequencing must occur as a practical matter. Conceptual Design must start before Logical Design, which must start before Physical Design. Similarly, the baseline for Conceptual Design must be established before the baseline for Logical Design, which must be established before the baseline for Physical Design. From a bigger perspective, the baseline output of the entire process is required to complete the Functional Specification.

Conceptual Design

The first part of the MSF Design Process, Conceptual Design, is defined as the process of acquiring, documenting, validating, and optimizing business and user perspectives of the problem and the solution. Its purpose is to capture and understand business needs and user requirements in their proper context. The output of Conceptual Design is a set of information models, use cases, and usage scenarios that document the current and future states of the system.

As we've said, Conceptual Design may be likened to the first stage of designing a house, when the client and the architect collaborate on a rough sketch and on a short list of needs and requirements. Using the Conceptual Design Model facilitates the gathering of complete and accurate requirements by involving the customer, users, and other stakeholders. Without a good conceptual design, the project team may end up with a wonderful solution…to the wrong problem.

In application design and development, it is critical that products be "user-centric" or attuned to users' true requirements. User-centric means having an awareness of how users view the current environment and what they would like to see in a new product. Whereas gathering requirements has traditionally meant compiling a list of desirable features, the aim in Conceptual Design is to understand and document the relationships between the users, the application, and the business. It is vital to uncover what users truly care about.

The goals for Conceptual Design are:

• A design based on real data from the customer and users These are the business needs and user requirements for the solution.
• A coherent, integrated picture of the product The project team needs to understand exactly how the proposed application affects the business and the users of the application.
• Useful levels of abstraction or classification Conceptual Design uncovers information about the business itself. Understanding users and their requirements in the context of business activities eliminates unnecessary or extraneous requirements, and increases the visibility of those that remain.
• A common set of expectations among the customer, users, and the project team Agreement is important early-on in the process, not only because of the obvious danger of divergent expectations (which can only increase with time), but also because of the importance of these three parties to the success of the product.
• Group consensus in design Consensus ensures the success of the implemented system.
• Synchronization with the enterprise architecture Conceptual Design represents one of the earliest opportunities for the customer, users, and project team to validate the application architecture, and to validate the proposed application against the business models included in the enterprise architecture.
• A basis for team communication Including the customer and users as project participants fosters open communication, in turn reducing the possibility of future design changes due to an ongoing understanding of the evolving solution.

Conceptual Design consists of three steps: research, analysis, and implementation. Each step ends in its own baseline, which contributes to the overall Conceptual Design baseline.

Research involves:

• Getting answers to key questions.
• Identifying key business processes and activities.
• Prioritizing processes and activities.
• Identifying users and creating profiles.

Analysis involves:

• Reviewing in-depth user and business research.
• Creating scenarios to depict context, workflow, task sequence, and environmental relationships.

Implementation involves:

• Improving workflow and the solution that supports it.
• Validating and testing the work redesign.

The Conceptual Design baseline includes the implementation baseline, and is the culmination of the research, analysis, and implementation steps.

Step #1: Research

Before starting the Conceptual Design process, the team must first determine the focus of its investigation. For example, the team might start by describing the core operational processes of the appropriate business area, rather than the organizational function. These descriptions might include:

• Descriptions of core business processes and their boundaries, along with the functional elements of the business.
• High-level descriptions of business transactions within those processes.
• A description of the customer and the users.

More specific details can include business process maps and their interdependencies, information structure and usage, and measurements and metrics (such as revenue per unit, expenses, operational locations, forecasts, and projections). Much of this information can be obtained from the enterprise architecture documentation, if it is available. When using UML or the Unified Process Model, these activities can be related to the use case, activity, and collaboration model.

During the research step, the project team conducts a high-level evaluation of existing business processes and activities in the context of enterprise strategy, goals, and objectives in the focus area. It should identify core corporate processes that support the business's objectives and goals. These may be product, service, or managerial processes, and in most cases, they are cross-functional in nature and move horizontally across the organization rather than vertically within the business's traditional departments or "silos."

A core process:

• Runs the business.
• Directly addresses strategic directions and competitiveness.
• Has identifiable owners and customers.
• Has a definition that makes as much sense to external customers or suppliers as it does to internal staff.
• Has discrete and minimal dependencies on other core processes.

After the team has identified and prioritized business processes and activities, it should conduct additional investigations to complete its understanding, such as tapping into the corporate culture, gathering artifacts, and so on. The point is to gain a complete, accurate picture, with the quality of information being more important than the quantity of data.

In addition to researching business processes, the team can also conduct research on users and user groups. The first step is to identify as many groups as possible, including the organization's owner, users within the organization, and users outside the organization such as suppliers and consumers. After the various constituencies have been identified, a user profile must be created for each one, detailing the group's role in the organization, as well as its department, location, and involvement in specific activities. Any background data appropriate to the scope of the project should be included. Finally, the user roles must be related to the activities and processes documented earlier.

The research step is complete when the following tasks have been performed:

• Identify inputs to Conceptual Design, including appropriate enterprise architecture information, business processes and activities, and users and user profiles.
• Gather data, including business and user requirements.

Step #2: Analysis

The first task of the analysis step is to validate the results of the research step, usually at a group debriefing. After a data-gathering activity is completed, the interviewer's findings, which might include diagrams and notes, are presented to the team. Comments from team members help the interviewer interpret the results, and the session helps the team to better understand the user requirements.

It's important to involve as many team members as possible in the debriefing sessions, especially Development, Testing, User Education, and Logistics Management. All team members have some involvement in the design of the application, and each member needs to understand and accept a common view of the users. Team members contribute different perspectives to the sessions, and walk away from these debriefings with information that is important to their role in the project.

When the research is deemed credible, the next task is to build information models to capture context, workflow processes, and task sequences. These information models are of two types: use cases and scenarios.

Use Cases

A use case is defined as a behaviorally related sequence of interactions performed by an actor in a dialogue with a system to provide some measurable value to the actor.

An actor can be a person, a group of people, another system, or even a piece of equipment. The defining characteristic of an actor is a role, or set of roles, performed in relation to the business or system. Use cases serve the following purposes:

• Identify the business process and all activities, from start to finish.
• Document the context and environmental issues.
• Trace a path between business needs and user requirements.
• Describe needs and requirements in the context of usage.
• Focus users and the project team.

Use cases have the following benefits:

• Provide the context for all business and user requirements.
• Facilitate "common" understanding of the application.
• Provide the basis for user work-flow scenarios.
• Facilitate objectivity and consistency in evaluating user suggestions.
• Provide organization for the Functional Specification.
• Enable paths to be traced between user needs and logical design.

Scenarios

A scenario is defined as a single sequence of interactions between objects and actors.

A scenario illustrates a particular instance of a use case and can show either the current state of the process or a desired future state. Four types of information are captured within a scenario:

• Context This includes cultural norms, policies, procedures, rules, regulations, and standards that constrain and support the business and the user.
• Workflow process This process depicts the flow of products and information within a business process, and among departments and customers. Note that business processes can cut across organizational boundaries.
• Task sequence This sequence documents the activities and tasks within a discrete part of a process. Included in the task sequence are the tasks that trigger the sequence; the activities, tasks, and steps involved in the task sequence; any decisions and loops within the sequence; and both typical and atypical paths.
• Physical environment This illustrates the physical, environmental, and ergonomic conditions that constrain or support the work. The physical environment could include geographic maps of sites; personnel or other resources; work area schematics or floor plans; or photographs showing equipment, computers, furniture, and lighting.

Scenarios document the sequence of tasks performed by a specific role. Because each scenario represents only one particular instance of the use case, many scenarios are needed to document all the tasks comprising the workflow process in a given use case.

Scenarios can be easily documented in narratives, pseudocode, and task sequence diagrams. They are also easily prototyped for verification with users.

There are positive and negative aspects to building current-state scenarios. On the positive side, current-state scenarios:

• Provide reference points for proposed development.
• Educate users and project team on the current environment.
• May reveal additional justification for the new system.
• May reveal intersystem dependencies.

On the negative side, though, current-state scenarios:

• Take time, resources, and money.
• May not provide added value if the solution is small or well understood, or is not critical.
• May not be relevant.

On every project, the team must evaluate the negative and the positive aspects of the project's current-state scenarios, considering the resources required to construct them. Risk assessment brings a degree of objectivity to this process, by asking the questions "What is the risk of taking the time to create scenarios versus not doing so?" and "What is the risk of misunderstanding if we don't create scenarios?"

The analysis step is complete when the following tasks have been performed:

• Synthesize business and user data, integrating the four categories of information—context, work-flow process, task sequence, and physical environment—needed for scenarios.
• Create scenarios, to whatever extent the team has deemed appropriate.

The scenarios at this point are current-state. We discuss how the scenarios can be changed to depict the desired future state in the next section.

Step #3: Rationalization

In this step, the goal is to include business processes as part of the design process, and to make improvements where possible. The scope of Conceptual Design includes not only the system under evaluation, but also the broader context of business processes, information, and goals that a new system will support.

The project team will not necessarily make all the improvements alone, but may coordinate with other efforts already underway, or with consultants brought in specifically for the work. Depending on the scope of the project and the depth of the team's understanding of the business, the team may be able to optimize one or more processes without any outside help.

What should be optimized? The goal is to eliminate as many of the following as possible:

• Inefficiencies
• Bottlenecks and unnecessary steps
• Redundant and ineffective practices and processes
• Unnecessary paperwork
• Dysfunctional policies
• Transport and delay time

The team should begin by asking questions: "How can we improve productivity?" "Where can we optimize?" "Are there places where we can integrate entire processes?" It's not enough to simply identify weaknesses. The team must also be able to imagine and describe the desired future state. Once the desired future state has been clearly visualized and described, the team can build appropriate new scenarios.

The following design basics can be used to optimize the processes involved in the project:

• Break the rules Question assumptions. Ask why there are principles and rules such as "In this company, travel requests must be approved at the unit, departmental, and divisional levels."
• Align with performance goals Ensure that goals chosen at the outset are truly aligned with projected results. Think of performance in terms of meeting customer requirements and not just short-term needs.
• Design work around products and services Design a person's job around the goals and objectives of the process, not around a single task.
• Eliminate bureaucracies and other obstacles Replace bureaucratic hierarchies with self-organized teams working in parallel.
• Improve productivity Move away from fragmentation and specialization, and move toward task compression and integration.
• Ask where technology can enable and support Consider the availability of appropriate technology that will support and enable the redesigned process. Question activities and roles that simply relay information and that can be handled more easily with technology.
• Be aware of the risk of taking on too complex a process at the outset Break the process into subprocesses that can be addressed sequentially.

After new scenarios are created, the final rationalization step is to validate the new scenarios; that is, to assure that they solve the business problem. The team accomplishes this by completing these steps:

• Build a proof-of-concept version of the system.
• Use the proof-of-concept version to represent the user interface design.
• Get usability and business feedback.
• Repeat until both the customer and users are satisfied.

Early in the design process, proof-of-concept systems should show only the main features, user interface design and overall structure of the system. With this proof-of-concept level, the team is open to quickly reworking the design, because it has not invested a lot of effort in one "solution." Proofs-of-concept at this stage can take some of the following forms:

• Applications displaying basic functionality
• Storyboards (either paper-based or screen-based)
• Paper prototypes of the overall structure and user interaction
• Microsoft PowerPoint slides that illustrate the main elements of the system and demonstrate the navigation through the system for one or more tasks

As the design process progresses, prototypes are likely to become more high fidelity, allowing the team to evaluate the visual style and some details of the design, particularly the user interface.

Validation using scenarios is preferable to producing a generic requirements document, because a scenario contains the larger context of the requirements. It's much easier to validate a scenario with a walk-through, role play, or proof-of-concept. One objective of validation is to uncover, before user sign-off, any missing pieces or incorrect interpretations of the design goals. Divergent views among the users over any aspect of the solution will also become starkly apparent and should immediately raise concerns.

It's important not to try and re-engineer the entire business process with the initial releases of the applications. Later product releases can introduce more future-state scenarios that may provide additional streamlining of the modeled business processes. Often, users will be hesitant to change how they do everything with one application release, and the phasing of future states into the application can be a compromise for the user community.

The rationalization step is complete when the following tasks have been performed:

• Build future-state scenarios that will improve the work.
• Validate desired future state scenarios with an update to the organization's enterprise architecture.

Logical Design

Logical Design is defined as the process of describing a solution in terms of the organization, structure, syntax, and interaction of its parts from the perspective of the project team.

The purpose of Logical Design is to apply the services-based organizing principles of the MSF Application Model, which we discussed in Chapter 2, and to lay out the structure of the solution and the relationship among its parts. The output of Logical Design is a set of business objects with corresponding services, attributes, and relationships; a high-level user interface design; and a logical database design.

Logical Design can be likened to the second stage of designing a house, during which the architect concentrates on creating the floor plan and elevation. Here, architectural elements like doors, windows, roofs, patios, rooms, and spatial relationships are organized into a harmonious whole.

Logical Design is the project team's view of the solution. The team paints a picture of the solution's behavior and logical organization, which is required for Physical Design. Logical Design helps the team refine the requirements specified in Conceptual Design and manage the complexity of the whole solution.

In the Logical Design stage, the team:

• Manages and reduces complexity by defining the structure of the solution, describing the parts of the system, and describing how the parts interact to solve the problem.
• Sets boundaries and describes interfaces to provide an organizational structure for interaction between multiple groups.
• Uncovers any errors and inconsistencies in Conceptual Design.
• Eliminates redundancy and identifies potential reuse.
• Provides a foundation for Physical Design.
• Improves the operation between the various parts of the system, and of the system itself.
• Articulates a common view of the solution among project team members.

Note that Logical Design is independent of physical implementation. The primary focus is on what the system needs to do, as explained by an organized set of cooperating elements. It is important to understand the solution completely before making a commitment to specific technologies.

Logical Design has two steps: analysis and rationalization. (There is no research step, because the output of Conceptual Design is the input to Logical Design.)

Analysis involves:

• Identifying business objects and services.
• Identifying attributes and relationships.

Rationalization involves:

• Verifying business objects.
• Identifying implied business objects and scenarios.

Step #1: Analysis

The goal of the analysis step is to convert the scenarios from Conceptual Design into modules for use in Logical Design. Modules are the core use cases of the system, the services or activities that occur within them, and the paths between them. A module is a logical unit used as an abstraction for the use cases and scenarios created in Conceptual Design. For each module, the team identifies its services, objects, attributes, and relationships.

To identify services, business objects, attributes, and relationships, the team refers to the work flow and task sequence information of scenarios, focusing on its appropriate aspects, as follows:

• Services focus on the actions (verbs).
• Business objects focus on the people or things (nouns).
• Attributes focus on the properties.
• Relationships focus on the properties.

The team can also derive useful information from the context and physical environment.

Services

A service is a unit of application logic that implements an operation, function, or transformation. Services can be relatively straightforward and can provide algorithmically simple functions—such as Create, Read, Update, and Delete—or algorithmically complex calculations or transformations—such as Pay, Validate, and Reserve.

The capabilities and responsibilities of a service should be stated as generally as possible, using only active verbs. A service should be identified by a clear, unambiguous name. Difficulty identifying and naming a service often indicates that its functionality or purpose isn't clear and that additional Conceptual Design investigation may be necessary.

The example in Table 6.3 shows a sample task sequence and the services within it.

Table 6.3 Sample task sequence and its services

Sample task sequence	Candidate services
Front desk clerk looks up guest reservation	View reservation
System retrieves room assigned to confirmed guest	Retrieve room Assign room
Front desk clerk issues a key	Issue key

Business Objects

A business object is an encapsulation of services and data used to organize the solution and reduce its complexity. Business objects are the people or things that are described in the scenarios. These objects then become the "anchor points" for attributes and relationships. (Note that this definition is different than that of an object from a COM perspective, which is the instance of a class definition.)

Some business objects might not be specifically stated in a scenario, even though these objects might be necessary to complete the business activities that the scenario describes, which are often noted as non-functional requirements. To identify business objects look for structures, other systems, devices, things or events remembered but not actually physically present in the scenario, roles played, operational procedures, locations or sites, and organizational units. To identify missing objects, the team must look for behaviors that have no apparent object associated with them.

The example in Table 6.4 shows the same sample task sequence as that of Table 6.3 with its business objects.

Table 6.4 Sample task sequence and its business objects

Sample task sequence	Candidate business objects
Front desk clerk looks up guest reservation	Front desk clerk Guest reservation
System retrieves room assigned to confirmed guest	System Room Guest
Front desk clerk issues a key	Key

Attributes

Attributes (called properties in COM) are the elements of an object that the business needs to know about and keep track of. Attributes are the definitions of data values that are held by an object. Each instance of an object maintains its own set of values based on the corresponding definition. For example, an attri- bute might be First Name, and the value that the attribute takes in a certain instance might be John. Attributes can also show ownership of an object by another object. The set of values for an object's attributes at any given point is known as its state.

As the team attempts to discover attributes, it must be sure to note any attributes that are derived—that is, computed—from other attributes. The derivation of this type of attribute becomes a service of the object, and the calculation or manipu-lation is maintained as part of the interface contract for that service. For example, if the Reservation Number attribute of the Room Reservation object is derived from the Reservation System object, then a Create Reservation Number service needs to be identified within the Reservation System object.

Also, the team must look at the total set of attributes for an object. If some of an object's attributes are very different from its other attributes, a new object might need to be created.

Notice that our definition points out that attributes are properties that the business needs to know about and keep track of. Conversely, some attributes might be present but be irrelevant to the task at hand. Such attributes should be noted, in case they are later deemed relevant. (Note that attributes that are relevant today may become irrelevant in the future, as business and process needs change.)

Table 6.5 shows the same sample task sequence as that of the two preceding tables with some candidate attributes. Examples of irrelevant attributes for this sample are age, height, religion, ethnicity, and Social Security number. Note that the same object can have many states.

Table 6.5 Sample task sequence and its attributes

Sample narrative	Candidate attributes	Values at one state
Guest has a name and address	First name Last name Address	Dan Shelly 100 Microsoft Way
Guest must have a type of reservation	Type	Gold Club
Depending upon type of reservation, guest can have a company	Company	Microsoft
Guest can be a smoker or nonsmoker	N/smoker	Nonsmoker

Relationships

A relationship is a logical association between objects. Recognizing relationships is required for determining effective design and assembly of the system parts.

Relationships, or associations, illustrate the way in which objects are related or linked to one another. Relationships fall into one of three types: whole/part, interaction, or generalization/specialization. As the team looks for relationships, it should consider any whole/part relationships that can be identified, any interactions that must be identified to maintain context, and any generalizations or specifications that can be made.

As the example in Figure 6.4 demonstrates, the guest object might be a specialization of the more generic person object; a guest can be part of a guest list, and a guest stays at a particular hotel.

Figure 6.4 Example of identifying relationships

To summarize, the analysis step is concerned with identifying the objects, services, attributes, and relationships comprising the scenarios. The diagram in Figure 6.5 illustrates this process. Note that in some methodologies, this process is called noun-verb analysis.

Figure 6.5 Identification process

The anaysis step of Logical Design is complete when the following tasks have been performed:

• Identify services and prepare a list of services.
• Identify objects and prepare a list of objects.
• Identify attributes and prepare a list of attributes.
• Identify relationships and prepare a list of relationships.

Step #2: Rationalization

The first task of the rationalization step of Logical Design is to create any needed services and objects that have not been created to this point. New services and objects are created either because their existence is implied, or because they are needed for control. The team then refines the design. Finally, the Logical Design must be verified.

Creating Implied Services and Objects

This stage consists of creating objects and services that seem to be missing from Logical Design. For example, a guest (represented by an object) has company affiliations (also represented by an object). However, the relationship might not always exist. (For example, the guest might or might not use a company credit card for discounted rates.) Creating a new type of stay object effectively handles the missing, implied object and records the relationship between a guest and his or her company if one exists.

Control

At this point, the team should concern itself with matters of control. Control means ensuring that services are conducted in the right sequence at the right time. In distributed systems, transactions can be used as a means for determining effective sequencing and the dependency relationships of objects, such as MTS packages. Otherwise, control objects might be needed to ensure the transactional integrity of a scenario, to coordinate services across multiple objects, or to manage cross-object dependencies.

For example, the hotel check-in scenario is a business transaction, or a collection of objects, that have dependency and sequencing relationships. An object or service would need to be created that ensures those relationships are honored and that takes corrective action (such as canceling the reservation) if one of the relationships is broken.

The team must always consider the need for additional business objects to handle control, sequencing, and dependency. The team can also isolate services that are likely to change from those that are stable.

Iterating and Refining Objects

After the team has identified the objects, it needs to refine the design by:

• Eliminating objects that are irrelevant or out of scope.
• Combining redundant objects.
• Refining vague or implicit objects.
• Distinguishing between attributes and objects.
• Considering transactional control.
• Distinguishing actors and roles from objects.

The first attempt at specifying objects using noun-verb analysis usually requires some refinement. Not all of the nouns will be relevant for describing the solution. The remaining candidates might consist of physical entities such as customers, employees, and pieces of equipment, as well as concepts that indicate business transactions such as room assignment, payment authorization, or promotion.

As part of the refinement process, services can also be used to discover objects. For each service that was identified in the analysis step, the team might ask, "What does this service act upon?" and "Is there an entity, individual, or organization that has the responsibility of carrying out this service?" Any objects with zero services or only one service defined might need further investigation.

Verification

Verification refers to testing the functional completeness and correctness of the design at the object level. The objects are tested in both an individual and coop-erating context. Verification of independent objects makes the task of integration much easier because the independent parts have been rigorously tested prior to assembly. Verification of cooperating objects ensures that the work specified in the scenario is accomplished as a whole.

For individual objects, the team should examine the pre-conditions feeding into the object and the post-conditions coming out of the object. The question to ask is "For a given set of pre-conditions, do the post-conditions match the scenario's requirements?"

However, this testing will not uncover assembly issues. The team also needs to look at the combination of objects that can solve the higher-level problems that were captured in the scenarios. A collection of modules that are interdependent in solving a problem can be complex. A simple way to verify multi-object scenarios is to conduct a full walk-through of the scenario as shown in Figure 6.6, ensuring that all the needs of the scenario are met by some combination of objects.

Figure 6.6 Tracing the objects back to the scenario

The team can walk through a scenario and determine which object's services are required in which sequence to move through to a successful completion. From a starting trigger to an object, the team must determine what other objects' services are needed for the scenario to be complete.

The rationalization step of Logical Design is complete when the following tasks have been performed:

• Identify implied objects and services and refine control.
• Verify objects and services and refine the object module.

Physical Design

Physical Design is defined as the process of describing the components, services, and technologies of the solution from the perspective of Development. Its purpose is to apply real-world technology constraints to Logical Design, including implementation and performance considerations. The output of Physical Design is a set of components, a user interface design for a particular platform, and a physical database design.

Physical Design can be likened to the third and final stage of designing a house. Once the basic architectural plan is complete, the contractors, like the Development team, create their wiring plans, plumbing plans, heating and ventilation plans, and so on—as "components" of the internals of the house.

In the Physical Design stage, the team:

• Breaks down the system requirements to simplify the segmenting and estimating of the work needed to create the system, and to provide developer focus and clarity.
• Provides a bridge between Logical Design and implementation, by defining the solution in terms of implementation—a bridge "by developers for developers."
• Evaluates implementation options.
• Provides a flexible design based on services.
• Seeks compatibility with the organization's enterprise architecture.
• Traces back use cases and scenarios through Logical Design.

Physical Design provides the basis for the Functional Specification, which Development, Testing, and Logical Management can use for quality assurance. Why is this important? Because Physical Design represents the last chance to validate the design before writing the code. Once the team has begun code development, design changes can still be made, but the cost to the project in time and resources becomes much higher than in the Planning Phase.

The Physical Design baseline can be established when enough information is available to start developing or deploying. Thus development and deployment can be started before the baseline is frozen. The Physical Design baseline can be frozen well into the Developing Phase to take advantage of opportunities for refinement, but it must be frozen before the solution can be stabilized.

As the Physical Design is being completed, it provides input into other tasks of the Planning Phase by:

• Creating the basis for cost, schedule, and resource estimates.
• Mapping the solution to the MSF Development Process Model for interim milestones or internal releases.
• Refining and updating the earlier risk analysis.

It is important to note that the deliverables of the Physical Design Model help to form the deliverables of the Project Plan Approved Milestone, as follows:

• Topologies and component specifications become part of the Functional Specification.
• Tasks and estimates become part of the Master Project Plan and the Master Project Schedule.
• Risk assessment items update the Master Risk Assessment Document.

When developing, reviewing, and approving the Master Project Plan and the Master Project Schedule, issues will arise that require tradeoff changes to Physical Design. For example, time and resource constraints might require changes to the application's scope or features.

The Physical Design segment of the MSF Design Process consists of four steps: research, analysis, rationalization, and implementation. (The research step is required in order to identify possible technologies to be used in the application.) Each step ends with its own baseline except for the implementation step, whose baseline is included in the overall Physical Design baseline.

Research involves:

• Determining physical constraints of the infrastructure.
• Determining physical requirements of the solution.
• Managing risks from this conflict between physical constraints and requirements.

Analysis involves:

• Selecting candidate implementation technologies.
• Drafting a preliminary deployment model composed of network, data, and component topologies.

Rationalization involves:

• Determining a packaging and distribution strategy.
• Decomposing objects into services-based components.
• Distributing components across topologies.
• Refining packaging and distribution.

Implementation involves:

• Determining the programming model.
• Specifying the component interface.
• Specifying the components in the development language.
• Understanding component structure considerations.

The Physical Design baseline includes the specification baseline and constitutes the culmination of the research, analysis, rationalization, and implementation steps.

Step #1: Research

The goals during the research step of Physical Design are twofold:

• Determine the physical constraints of the infrastructure and the physical requirements of the application.
• Manage the risks from conflict between the physical constraints of the infrastructure and the physical requirements of the application.

By this point, the physical requirements of the application should be well known in a general sense—the application must serve so many people, it must carry out this many transactions per day, and so on. Fairly specific research may be necessary to determine detailed physical requirements, including building proof-of-concept trial applications and testing them.

The physical constraints of the infrastructure, on the other hand, are rooted in the organization's enterprise architecture. As we pointed out in Chapter 1, the organization's enterprise architecture may not be formally documented. If it isn't, this is an opportunity to establish its baseline.

As the team endeavors to list both the requirements of the application and its matching constraints, beginning with the application will yield one list, while beginning with the infrastructure will yield a somewhat different list. Building the list from both viewpoints ensures that nothing is missed. Examples of the constraints and requirements the list might include are:

• Performance
• Cost versus benefit
• Deployment
• Supportability
• Technology choices
• Reliability
• Availability
• Security

One means of examining the current physical infrastructure is through topologies, which are maps showing some aspect of the infrastructure. For purposes of planning an application at the physical level, it is helpful to produce network, data, and component topologies. Examples of these are included in the following section on analysis. Infrastructure topologies produced during the research step of Physical Design are of the current state of the infrastructure.

Once the physical constraints and requirements are listed, the next task is to manage the risks presented by any conflicts or gaps that have been identified between the three topologies. This is a five-step process:

1. Identify where infrastructure constraints conflict with application requirements When the physical requirements of the application are compared with the physical constraints of the infrastructure, some will be in conflict, some will not be in conflict, and some will be immaterial. For example, the infrastructure might require use of TCP/IP across the enterprise. The application might require some other protocol (conflict or gap), might require TCP/IP (no conflict or gap), or not care which protocol it uses (immaterial).
2. Perform a preliminary assessment to highlight the gaps or conflicts Is it a gap (a deficiency which could possibly be overcome) or a conflict (implying some sort of choice or crossroads)? How big is the gap or conflict?
3. Prioritize the tradeoffs to determine which aspects are more important Which requirements are absolutely necessary? Which constraints are the result of enterprise architecture decisions? When prioritizing, the team must be sure to examine the business case, if any, for either the requirement or the constraint.
4. Brainstorm initial solutions with the team Fundamentally, only two things can be done with a gap or conflict:

• Accept it without doing anything (move ahead and see what happens later).
• Change one side or the other (requirement or constraint).

5. Identify associated risks branching from the original list It is important not to make the mistake of dealing with a risk, only to have the chosen solution cause new and unforeseen issues.

The result of this process is a preliminary risk assessment and mitigation plan for the Physical Design of the application, which will become part of the project's Master Risk Assessment Document.

The research step of Physical Design is complete when the following tasks have been performed:

• Determine constraints and requirements.
• Identify the current network, data, and component topologies and physical application requirements.
• Manage risks resulting from conflicts or gaps between constraints and requirements.
• Produce a risk assessment and mitigation plan.

Step #2: Analysis

The focus in the analysis step of Physical Design is on selecting candidate technologies for the implementation, based on an understanding of the application requirements. Note that these are candidate technologies. The final choice will be made later. Once the potential technologies have been chosen, the team can draft a preliminary deployment model, taking into consideration these technologies.

In evaluating candidate technologies, the team should address business considerations first, then take into account enterprise architecture considerations, and only then address technology considerations. The technologies should not be evaluated on their technological merits until the first two steps have been completed.

Business considerations include the following:

• Ability Establish whether the technology will actually meet the business needs.
• Product cost Understand the complete product cost. Consider developer, server, and reseller licenses, and upgrade costs.
• Experience Understand that experience (or lack thereof) can have a large impact. What experience is available in terms of training (costs or time), consultation (costs or availability), and comfort level?
• Maturity or innovation Understand that maturity is a fine line and decisions must be made based on risks. A mature product is accepted in the market, is well understood, is a revision of something done before, is stable, and has knowledgeable resources available. An innovative product is the "latest and greatest" or is "ahead of the curve." Ideally, the product should cycle quickly to stay as current as possible with new technologies.
• Supportability Understand that this technology must be supported just as the solution built with it must be supported. What are the implications of that support for the project and the enterprise? A supportable product has support options such as vendor, outsourcing, and help desk, and also accumulates support costs such as incidental costs and maintenance.

Other points to consider include deployment, competitive advantage, time to market, and industry perception.

Enterprise architecture considerations include the following:

• Alignment with enterprise architecture goals The application can fit within the goals and principles outlined by the enterprise architecture. These goals will be based on the four perspectives and models of enterprise architecture: Business, Application, Information, and Technology.
• Adherence to the enterprise architecture The enterprise architecture will identify the current-state and future-state plans. Specifically, the application should fit within the detail architectures of the application, information, and technology models of the enterprise architecture.
• Opportunity for growth Scalability of the application can be considered within the business growth plans for the organization, as well as the addition of people and markets through acquisition.
• Interoperability The application must work with the other systems within an organization. Not only can the application not interfere with other systems, but a communication interface can be defined so that other applications can easily interact with the new application.

Technology considerations include the following:

• Languages When selecting a language for component development, different languages should be considered for different tasks within a project. When choosing a development language, it is important to evaluate whether it supports the design and implementation of loosely coupled components that can be replaced and upgraded as necessary.
• Component interaction standards Platforms and interaction standards are related. When selecting a component interaction standard (how components connect and communicate with each other), cross-platform integration must be weighed against power and performance. More than one technology should be considered for the "plumbing."
• Data access methods When selecting a data access method (how components interact with data stores), performance, standardization, and future direction should be considered, as well as the diversity of supported data stores and data access management. When selecting a data store, more than one type should be considered, and the decision should be based on structure and location of information.
• System services When selecting system services ("plumbing" for distributed solutions), the types of services required by the solution must be identified, as well as which of those services can be provided natively by system software.
• Operating systems When selecting the operating system, the services that are provided by the operating system can significantly reduce the coding requirements of the application. Additionally, security and scalability needs can be met by the operating system; however, different operating systems provide different methods of access to their services.

With the candidate technologies in mind, the team can now draft a preliminary deployment model consisting of network, data, and component topologies. At this stage in Physical Design, these topologies are proposed but are not yet the selected topologies.

The network topology is an infrastructure map that indicates hardware locations and interconnections. A current-state version of the infrastructure map was developed in the research step. At this point, it might require changes to support the new Physical Design. A sample network topology diagram is shown in Figure 6.7.

Figure 6.7 Sample network topology

The data topology is a data distribution map that indicates data store locations in relation to the network topology. Again, a current-state version was constructed in the research step, but a new data distribution strategy or new data technologies might need to be considered to support the new Physical Design. Figure 6.8 shows a sample data topology.

Figure 6.8 Sample data topology

The component topology is a component distribution map that indicates the locations of components and their services in relation to the network topology. The current-state version should already exist from work in the research step. Any new components and services required by the new application should now be added, and any updating required to reflect changes in the other topologies should also be carried out. Figure 6.9 shows a diagram of a sample component topology.

Figure 6.9 Sample component topology

The analysis step of Physical Design is complete when the following tasks have been performed:

• Select and list candidate implementation technologies.
• Draft a preliminary deployment model to include the proposed network topology, the proposed data topology, and the proposed component topology.

Step #3: Rationalization

The team has done its research and has analyzed that research. At this point, it is time to begin solidifying the design. Determining a packaging and distribution strategy is part of this process.

The team might be thinking, "We can't plan for packaging and distribution when we haven't solidified the component model," and the team would be right. By the same token, the team cannot complete the component model without a firm packaging and distribution plan. The tasks involved in the rationalization step are both interactive and iterative. In some cases, it may make more sense to begin with the component model, while in others the packaging considerations will take precedence. One possible guideline is to begin with the task that seems the most complex or the most critical.

When determining the packaging and distribution strategy, the team should follow three basic steps. The first is to consider various packaging rationales, or reasons to choose a particular strategy. These could include any of the following:

• Service category
• Scalability
• Performance
• Manageability
• Reuse
• Business context
• Granularity

The second step is to align the strategy with the programming model. Because the programming model is not firm at this point, this step is inherently interactive in nature.

The third step is to determine the design tradeoffs that impact the strategy, based on the rationales used in the first step. For example, the team might have based its strategy primarily on the performance needs of the application. In doing so, any necessary scalability might have been compromised, and if it has, the team needs to decide what it will do about this tradeoff.

The team is now ready to begin defining components. Although there are many ways to do this, we recommend that the first cut at the component model be based on the MSF Application Model's three logical service layers: user, business, and data. As shown in Figure 6.10, the services are distributed throughout the topology. The team can then package candidate components from the same logical service located in the same place in the topology.

Figure 6.10 Sample component model

When the component model is complete, the team is ready to finalize the distribution of those components. Again, the first cut at distribution should be based on the three logical service layers: user, business, and data. Note, though, that the use of three logical services does not in any way imply a distribution of three physical locations. It is entirely possible to build an N-tier application that runs on a single computer. By the same token, a distribution strategy for a multi-site, complex application may involve 10, 20, or more physical locations.

Throughout the rationalization step, the team should be validating the proposed components and their packaging and distribution. Questions to ask include "Do the components fit the packaging strategy?" "Are we meeting the design goals and application requirements we outlined earlier?" "Do the components we have derived actually match up with the logical design?" and "Are we fitting into the enterprise architecture?"

One way to validate the design is to build prototypes and proof-of-concept test applications. As the team defines more and more components, they should be included in these trial applications and the results should be observed.

Although the development team has been doing validation work throughout the rationalization step, it should carry out formal component refinement and validation at the conclusion of this step. This validation task should be done by the Development and Testing roles. In some cases, it may be worthwhile to schedule a formal Quality Assurance review of the component design, carried out by an outside expert with component design expertise.

What would such an expert be looking for? Here are some attributes of a good component plan:

• The identified components contain all the services identified in the Logical Design Model.
• All component/service dependencies have been taken into account.
• The distribution of the components across the topologies matches the rationales on which it is supposedly based.
• Services are grouped into components based on a good balance of physical location, packaging rationale, and technology constraints.
• The component plan demonstrates high cohesion and loose coupling.
• The component plan addresses both upward and downward scalability. (Both are important!)

Cohesion and Coupling

One of the design goals noted above is high cohesion and loose coupling. Cohesion is the relationship among different internal elements of a component, whereas coupling is the relationship of a component to other components.

A component whose internal elements—primarily its services—are closely related is said to have high cohesion. Cohesion can be both beneficial and non-beneficial, depending on the cause of the cohesion.

Beneficial types of cohesion include the following:

• Functional A component does one and only one thing. This is the strongest type of cohesion.
• Sequential A component contains operations that must be performed in a specific order and must share the same data.
• Communicational Operations in a component use the same data but aren't related in any other way. This type of cohesion minimizes communication overhead in the system.
• Temporal Operations are combined because they are all done at the same time.

Non-beneficial types of cohesion include the following:

• Procedural Operations are grouped together because they are executed in a specific order. Unlike sequential cohesion, the operations do not share any of the same data.
• Logical Several operations are grouped into a single unit that requires some control flag, such as a large or highly nested IF or CASE statements, to be passed to select the appropriate operation. The operations are related only by artificial selection logic.
• Coincidental Operations are grouped without any discernible relationship to one another.

Metrics that can be used to determine the amount of coupling include the following:

• Size Minimize the number of connections and the complexity of interfaces.
• Intimacy Use the most direct connection.
• Visibility Define all connections explicitly.
• Flexibility Use arm's-length interfaces.

Ultimately the arm's-length flexibility goal should be to have high cohesion and loose coupling. The high cohesion provides a better definition of the component's function and behavior. An example would be organizing services by business function so that each component has only the services that pertain to its function. The loose coupling provides more flexibility and independence, and leads to better-defined and simpler interfaces. An example would be organizing relationships among components by business function so that each component interfaces with the minimum number of other components for access to data.

Even though the team carries out a formal refinement process at the end of the rationalization step, it can expect refinement to continue during development and stabilization. Packaging and distribution will change as the team tests for the results of the determining criteria, such as performance. Thus, if the system fails to meet performance objectives during testing, the team may have to revisit the packaging and distribution plan that was supposed to provide the expected performance levels.

The rationalization step of Physical Design is complete when the following tasks have been performed:

• Determine a packaging and distribution system.
• Transform objects into services-based components to create a services-based component model.
• Distribute components across topologies to produce a final deployment model that includes the future network, data, and component topologies.
• Use strategies and prototypes to refine packaging and distribution, resulting in a baseline deployment model.

Step #4: Implementation

The last step of Physical Design is implementation. During this step, the team specifies the programming model that Development will use, the interfaces for each component, and the internal structure of each component.

The programming model, which could also be called the programming specifications or standards, does the following:

• Prescribes how to use the selected technologies.
• Sets design guidelines for component specifications, which helps to ensure consistency across the project.
• Uses different considerations to address different aspects of the solution, such as stating that all business services will be stateless while client-side services will be stateful.

Several aspects need to be considered when building a programming model, some of which are highlighted in Table 6.6 and discussed at length in subsequent chapters.

Table 6.6 Programming model aspects

Aspect	Considerations
Implementation technologies	Programming language; API; servers and server technologies; and other technologies affecting implementation. Implementation technologies are a consideration because some technologies require a specific programming model to take full advantage of them. For example, Microsoft Transaction Server requires single-entrant, single-threaded, in-process components.
Stateful vs. stateless objects	A stateful object holds private state accumulated from the execution of one or more client calls. A stateless object does not hold private state. Typical questions to be addressed include where state will be kept and tradeoffs such as scalability, complexity, and performance.
In-process vs. out-of-process function calls	In-process is fast and direct. Out-of-process on the same machine is fast and offers secure interprocess communications. Out-of-process across machines is secure, reliable, and offers a flexible protocol based on Distributed Computing Environment, Remote Procedure Calls (DCE-RPC).
Connected vs. connectionless modes	In connected application/component environments, the various components participating in the service of a task must have real-time, live connections to each other to be able to function. If the connection is severed because of problems at run time, the components involved in the interaction fail. Real-time applications typically must be run in connected mode. Applica- tions/components that are written to run in a connectionless environment are able to reestablish a connection as and when needed.
Synchronous vs. asynchronous programming models	A synchronous programming model blocks the calling component from proceeding with other work until the called interface completes the requested service and returns control to the calling component. An asynchronous programming model allows components to send messages to other components and continue to function without waiting for a reply. A component designed to use an asynchronous programming model is harder to program, but it lends itself to more scalability. Each component isn't blocked and doesn't have to wait for a spawned process to complete before proceeding.
Threading model	Choosing the threading model for a component is not a simple matter because it depends on the function of the component. A component that does extensive I/O might support free-threading to provide maximum response to clients by allowing interface calls during I/O latency. On the other hand, an object that interacts with the user might support apartment threading to synchronize incoming COM calls with its window operations.
Error handling	Certain programming and deployment model decisions will constrain the number of error handling options available.
Security	A given component or service has four security options: component-based, at either the method level, the interface level, or the component level; database-based; user-context based, in either an interacive method using system security, or a fixed security within the application; or role-based, such as a night clerk or general manager.
Distribution	Having three logical tiers does not necessarily translate into three physical tiers. The logical tiers will be spread among the physical tiers. For example, some business services reside on the client.

NOTE

---

There typically is not just one programming model for all components. There may be many programming models for an application, depending on the different requirements of the different components.

Although not a part of the programming model itself, an important consideration is the skill set and experience of the technical people who will implement the programming model.

When the programming model has been outlined, the team is ready to specify the external structures of the components. These are outlined in the component interface, which:

• Is a contract that represents the supplier-consumer relationship between components.
• Is a means to access the underlying services.
• Represents one or more services.
• Includes underlying object attributes.

The specification of the component interface must include all the different ways the component can be accessed and, if possible, include examples of how the component can be used for each way it is accessed. A sample is shown in Figure 6.11. Note that the interface must be documented and understandable to the developers who will be using the components.

Figure 6.11 Sample component interface specification

There are three implications to consider when creating component interfaces:

• A published interface is an interface contract and should be considered permanent.
• A modification of an existing interface should be published either as a new component or an entirely new interface.
• The data types of published attributes must be supportable by the service interface consumer.

The interface contract defines the parameters, the data types, any interaction standards, and a description of the interface. The degree of specificity depends on user needs—ultimately, the degree of reuse.

Finally, the team is ready to specify the internal structure of the components. (Note that internal structure is important only when building the component itself. When assembling components, the interface is the important factor.) Many factors come into play when defining the internal structure of a component. The most significant factor is the language or tool used to implement the component. The other factors are used as criteria to determine the component's internal structure. For example, when writing the first N-tier application for a large organization that plans to develop other applications that will use many of the same services, the internal structures of the components should be designed so as to enhance their reusability.

When the internal structures have been specified, the baseline for the implementation step is established. This baseline is merged into the overall Physical Design baseline. The implementation step of Physical Design is complete when the following tasks have been performed:

• Determine a programming model.
• Specify the external structures of components, including interfaces, attributes, and services.
• Specify the internal structures of components.

The design process is now complete, having moved from the reality of user requirements, through Conceptual Design, through the abstraction of Logical Design, and back to the reality of Physical Design and the completed application design. The output of the process will become the basis for the Functional Specification, which feeds the Master Project Plan, the Master Project Schedule, and a revision of the Master Risk Assessment Document.