Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java Enterprise System 2005Q1 Deployment Planning Guide 

Chapter 2
Business Analysis

During the business analysis phase of the solution life cycle you define business goals by analyzing a business problem and identifying the business requirements and business constraints to meet that goal.

This chapter contains the following sections:


About Business Analysis

Business analysis starts with stating the business goals. You then analyze the business problems you must solve and identify the business requirements that must be met to achieve the business goals. Consider also any business constraints that limit your ability to achieve the goals. The analysis of business requirements and constraints results in a set of business requirements documents.

You use the resulting set of business requirements documents as a basis for deriving technical requirements in the technical requirements phase. Throughout the solution life cycle, you measure the success of your deployment planning and ultimately the success of your solution according to the analysis performed in the business analysis phase.


Defining Business Requirements

No simple formula exists that can identify all business requirements. You determine the requirements based on collaboration with the stakeholders requiring a software solution, your own knowledge about the business domain, and applied creative thinking.

This section provides some factors to consider when defining business requirements.

Setting Business Goals

Business analysis should articulate the goals of a deployment project. Clear goals help focus design decisions and prevent the project from going astray. Contrasting the business goals with current operations also helps determine design decisions.

Scope

Business requirements should state the scope of the deployment project. Make sure you identify areas that can be solved and avoid open-ended requirements that make the goal either unclear or unreachable. A poorly defined scope can lead to a deployment design that insufficiently addresses business needs or that is extravagant with resources.

Priorities

Prioritize your goals to ensure that the most important aspects of the deployment can be achieved first. Limited resources might require postponement or modification of some goals. For example, large and complex deployments generally require phased implementation of the solution. By stating the priorities, you provide guidance on decisions that might need to be made for your deployment design to be accepted by the stakeholders.

Critical Qualities

Identify areas that are critical to success to allow stakeholders and designers to concentrate on the most important criteria.

Growth Factors

As you set business goals, consider not only the current needs of the organization, but anticipate how these needs might change and grow over extended periods. You do not want a solution that is outdated prematurely.

Safety Margin

The design of your solution is based on assumptions made during this business analysis phase. These assumptions might not be accurate for various reasons, such as insufficient data, errors in judgement, or unanticipated external events. Make sure you plan for a safety margin not only in your business goals but throughout your planning so the solution that you design can handle unexpected events.

Understanding User Needs

Do the research necessary to understand the types of users that the solution targets, their needs, and the expected benefits to them. For example, the following list provides one way to categorize users:

Clearly stating the expected benefits to users helps drive design decisions. For example, here are some benefits that a solution can provide to users:

Developing Operational Requirements

Express operational requirements as a set of functional requirements with straightforward goals. Typically, you create operational specifications for areas such as:

Express operational requirements in measurable terms that all stakeholders can understand. Avoid ambiguous language, such as “adequate end-user response time.” Examples of operational requirements could be the following:

Supporting Existing Usage Patterns

Express existing usage patterns as clearly measurable goals. The following questions can help determine such goals.

Study the users who access your services. Factors such as when users access existing services and for how long are keys to identifying your goals. If your organization’s experience cannot provide these patterns, study the experience of similar organizations.

Understanding Corporate Culture

Requirements analysis should take into account various aspects of corporate culture and politics. Lack of attention to corporate culture can result in a solution that is not well received or is difficult to implement.

Stakeholders

Identify individuals and organizations that have a vested interest in the success of the proposed solution. All stakeholders should actively participate in defining the business goals and requirements. If a stakeholder does not participate or is uninformed of planned changes, the plans could have significant shortcomings. Such a stakeholder could even block the implementation of the deployment.

Standards and Policies

Make sure you understand the standards and policies of the organization requesting the solution. These standards and policies might affect technical aspects of the design, product selection, and methodology of deployment.

One example is the confidentiality of personnel data that might be owned and controlled by the human resources organization or unit managers. Another example would be company procedures for change management. Change management policies could dramatically affect acceptance of a solution and influence the implementation methodology and time table.

Regulatory Requirements

Regulatory requirements vary greatly, depending on the nature of the business. Research and understand any regulatory requirements that might affect the deployment. Many companies and government agencies require compliance with accessibility standards. When deploying global solutions, consider foreign laws and regulations. For example, many European countries have strict controls on storing personal information.

Security

Some goals that you identify might have implicit security issues that should be emphasized. Call out specific security goals essential to the solution. For example:

Site Distribution

The geographic distribution of sites and the bandwidth between the sites can affect design decisions. Additionally, some sites might require local management.

Such geographic considerations can raise the project’s training costs, complexity, and so forth. Clearly state requirements resulting from geographic distribution of sites. Highlight which sites are critical to the design’s success.

Using an Incremental Approach

Often, you view a software solution as a whole, comprehensive system. However, you often achieve deployment of the complete system incrementally by taking measured steps.

When adopting an incremental approach, you typically design a road map that provides milestones leading to the ultimate, comprehensive solution. Additionally, you might have to consider short-term plans for aspects of the comprehensive solution that are deferred for later implementation.

The incremental approach provides these advantages:

Understanding Service Level Agreements

A service level agreement (SLA) specifies minimum performance requirements and, upon failure to meet those requirements, the level and extent of customer support that must be provided. A service level agreement is based on business requirements defined during business analysis, which are later specified as service level requirements during the technical requirements phase. The SLA is signed during project approval, which occurs in the deployment design phase.

You should develop an SLA around areas such as uptime, response time, message delivery time, and disaster recovery. An SLA should account for items such as an overview of the system, the roles and responsibilities of support organizations, how to measure service levels, change requests, and so forth. Identifying your organization’s expectations around system availability is key in determining the scope of an SLA.


Defining Business Constraints

Business constraints play a significant role in determining the nature of a deployment project. One key to successful deployment design is finding the optimal way to meet business requirements within known business constraints. The business constraints can be fiscal limitations, physical limitations (for example, network capacity), time limitations (for example, completion before significant events such as the next annual meeting), or any other limitation you anticipate as a factor that affects the achievement of the business goal.

This section describes several factors to consider when defining business constraints.

Migration Issues

Typically, a deployment project replaces or supplements existing software infrastructure and data. Any new solution must be able to migrate data and procedures from the existing infrastructure to the new solution, often retaining interoperability with existing applications. An analysis of the current infrastructure is necessary to determine the extent migration issues play into the proposed solution.

Schedule Mandates

The schedule for implementation of a solution can affect design decisions. Aggressive schedules might result in scaling back of goals, changing priorities, or adopting an incremental solution approach. Within a schedule, significant milestones might exist that deserve consideration as well. Milestones can be set by internal events such as scheduled service rollouts or external events such as the opening date of a school semester.

Budget Limitations

Most deployment projects must adhere to a budget. Considering the cost of building the proposed solution and the resources required to maintain the solution over a specific lifetime including the following:

Cost of Ownership

In addition to maintenance, administration, and support, analyze other factors that affect the cost of ownership. Hardware and software upgrades might be necessary, the impact of the solution on the power grid, telecommunications cost, and other factors influence out-of-pocket expenses. Service level agreements specifying availability levels for the solution also affect the cost of ownership by requiring increased redundancy.

The implementation of a solution should provide a return on the investment into the solution. Analysis of return on investment typically involves measuring the financial benefits gained from the expenditure of capital.

Estimating the financial benefits of a solution involves a careful analysis of the goals to be achieved in comparison with alternate ways of achieving those goals and with the cost of doing nothing at all.



Previous      Contents      Index      Next     


Part No: 819-0058-10.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.