Chapter 2 Business Analysis

This chapter provides some guidelines on how to analyze a business problem, identify its business requirements and constraints, and articulate a business goal.

Business analysis starts with stating the business goals for the deployment project. 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 business requirements and constraints that you identify are a basis for a business requirements document that you later use to derive system requirements during the technical requirements phase.

No simple formula exists that identifies business requirements—you determine the requirements based on collaboration with your customer and on your own knowledge about the business domain. The guidelines presented here provide one way that you can begin your business analysis.

Business Requirements

A business problem statement is much like an executive summary of the project, outlining the project’s ultimate goal. Within the business problem statement you make the business case for the project (why the project is necessary or desirable to do) and define the scope of the project (what is in bounds and out of bounds for the project). You also decide which features of the project are critical to its success.

The result of business requirements analysis should be a document that defines how a deployment satisfies the business goals. The following table lists topics typically addressed during business requirements analysis.

Table 2-1 Topics for Analyzing Business Requirements
Topic	Description
Business goals	Clearly articulate the goals of the project. A clear understanding of the goals helps focus design decisions. Here are a few example goals: Enterprise collaboration, including features such as messaging, address book, instant messaging, and calendar services Enterprise portal, to allow users to aggregate and personalize content, and to provide access to e-mail, calendar, instant messaging, and other enterprise services Enterprise resource scheduler, to schedule conference rooms, offices, and other shared physical resources Enable online commerce Contrasting the goals for a planned deployment with current operations can help later determine design decisions.
Type of deployment	Identify which of the following types of deployments you envision: Business to Customer Business to Employee Business to Business Enterprise Employee to Employee Communications Some combination of these types Understanding the type of deployment brings to focus specific design issues inherent with that type.
Scope	Clearly state the scope of the project. Make sure you identify area that can be solved and avoid “open-ended” statements that make the goal either unclear or unreachable. Poorly defined scope can lead to deployment design that insufficiently addresses business needs.
Stakeholders	Identify individuals and organizations that have a vested interest in the success of the deployment. All stakeholders should actively participate in defining the business goals and requirements.
Critical qualities	Identify areas that are critical to success. This allows for analysis of the design with respect to the most important criteria.
Target users	Identify the types of users the deployment targets. For example: Current and previous employees Active customers Membership site General public Administrators
Benefits to the users	State the expected benefits to the users of the deployment. For example: Remote access to company resources Enterprise collaboration Reduced response time Reduced error rate Simplification of daily tasks Sharing of resources by remote teams Increased productivity Clearly stating the expected benefits helps drive design decisions.
Service level agreements	Define the level and extent of customer support you must provide should the deployment fail to meet specific system requirements. Typically, a service level agreement is signed during project approval, based on service level requirements defined during analysis of technical requirements.
Security issues	Goals that you previously identified might have implicit security issues that you do not need to list in the problem statement. However, it can be useful to call out specific security goals essential to the deployment. For example: Access to proprietary information to authorized users Role-based access to confidential information Secure communication between remote locations Invocation of remote applications on local systems Secure transactions with third party businesses
Priorities	State the priorities of your goals. Large and complex deployments might require phased implementation. Limited resources might require elimination or modification of some goals. By clearly stating the priorities, you can provide guidance to decisions that might need to be made for your deployment design to garner acceptance.

Business Constraints

Business constraints play a significant role in determining the nature of a deployment project. The key to a successful deployment design is finding the optimal way to meet business requirements within known business constraints.

The following table lists typical business constraints that might affect deployment design. Individual deployment projects might have business constraints particular to their own situation.

Table 2-2 Topics for Analyzing Business Constraints
Topic	Description
Time frame or schedule	The schedule for deployment can affect design decisions that you make. Aggressive schedules might result in scaling back of goals, changing priorities, or adopting an incremental solution approach. Within a schedule, there might be significant milestones that deserve consideration as well.
Budget considerations	Most deployments must adhere to a specific budget. This budget should always be considered during the design process to avoid cost overruns. When considering the budget, keep in mind not only the cost of completion of the project, but the resources required to maintain the project over a specific lifetime.
Resources	Consider all resources necessary for a successful deployment, not just the capital expenditures. This includes the following: Existing hardware and network infrastructure Reliance on existing infrastructure can affect the design of a system. Development resources needed to implement the deployment design Limited development resources, including hardware, software, and human resources, might suggest incremental deployment. You might have to reuse the same resources or development teams for each incremental phase. Maintenance, administration, and support Analyze the resources available to administer, maintain, and support users on the system. Limited resources here might impact design decisions you make.
Cost of ownership	In addition to maintenance, administration, and support, you should analyze other factors that affect the cost of ownership. For example, hardware and software upgrades that might be necessary, the footprint on the power grid, telecommunications cost, and other factors influencing out-of-pocket expenses.
Company standards and policies	Make sure to understand the standards and policies of the organization requesting the deployment. These standards and policies might affect technical aspects of the design, product selection, and methods of deployment.
Company change management	Company procedures for change management might dramatically affect the deployment methods and time table.
Return on investment	Each deployment should provide a return to the customer on their investment. Analysis of return on investment typically involves measuring the financial benefits gained from the expenditure of capital. Estimating the financial benefits of a deployment involves a careful analysis of the goals to be achieved by the deployment in comparison with alternate ways of achieving those goals, or in comparison with the cost of doing nothing at all.
Regulatory requirements	Regulatory requirements vary greatly, depending on the nature of the deployment.

Incremental Approach to Deployment

Typically, you view a deployment as a whole, comprehensive system. However, you often achieve the comprehensive system incrementally with measured steps.

When adopting an incremental approach, you typically design a road map that provides milestones that lead to the ultimate, comprehensive solution. Additionally, you might have to consider short term solutions for phases that will be implemented later in the plan.

No matter what approach you take, you should always design deployments to allow room for change and growth.

Previous Contents Next
Sun Java Enterprise System Deployment Planning White Paper