Feasibility Discovery, Design, and Architecture

---

Feasibility

Feasibility is the measure of how beneficial or practical the development of an information system will be to an organization. Feasibility analysis is the process by which feasibility is measured.The scope and complexity of an apparently feasible project can change after the initial problems and opportunities are fully analyzed or after the system has been designed. Thus, a project that is feasible at one point may become infeasible later.

Figure below shows feasibility checkpoints during the systems analysis phases of our life cycle. The checkpoints are represented by red diamonds. The diamonds indicate that a feasibility reassessment and management review should be conducted at the end of the prior phase. A project may be cancelled or revised at any checkpoint, despite whatever resources have been spent.

The first feasibility analysis is conducted during the scope definition phase. At this early stage of the project, feasibility is rarely more than a measure of the urgency of the problem and the first-cut estimate of development costs. It answers the question, Do the problems (or opportunities) warrant the cost of a detailed study and analysis of the current system? Realistically, feasibility can't be accurately measured until the problems (and opportunities) and requirements are better understood.After estimating the benefits of solving the problems and opportunities, analysts estimate the costs of developing the expected system. Experienced analysts routinely increase these costs by 50 to 100 percent (or more) because experience tells them the problems are rarely well defined and user requirements are typically understated.
The next checkpoint occurs after a more detailed study and problem analysis of the current system. Because the problems are better understood, the analysts can make better estimates of development costs and of the benefits to be obtained from a new system. The minimum value of solving a problem is equal to the cost of that problem.
The next checkpoint of the current system is decision analysis.The decision analysis phase represents a major feasibility analysis activity since it charts one of many possible implementations as the target for systems design. Problems and requirements should be known by now. During the decision analysis phase, alternative solutions are defined in terms of their input/output methods, data storage methods, computer hardware and software requirements, processing methods, and people implications.

Six Tests for Feasibility

• Operational feasibility is a measure of how well a solution meets the identified system requirements to solve the problems and take advantage of the opportunities envisioned for the system.
• Cultural (or political) feasibility is a measure of how people feel about a solution and how well it will be accepted in a given organizational climate.
• Technical feasibility is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise to implement and maintain it.
• Schedule feasibility is a measure of how reasonable the project timetable is.
• Economic feasibility is a measure of the cost-effectiveness of a project or solution.
• Legal feasibility is a measure of how well a solution can be implemented within existing legal and contractual obligations.

---

System Design

Once the analysis is complete and the requirements are captured, the question becomes one of how to best provide a solution. This leads to the build or buy question, which can be very complex. Some questions to ask when making this analysis should include the following:

• Will the software (whether built or bought) meet the needs as defined in previous activities?
• Can the software be fully integrated with existing systems?
• Will the cost of the complete system (including hardware and software) be manageable from a budgeting perspective?
• Will the software be able to provide specialized functions that may be strategic in nature?
• Does the system meet existing system directives and strategies?
• Will additional labor be needed for customization?
• Are existing platforms workable with the new software?
• Is the architecture stable?
• Does the architecture risk immediate antiquation?
• Are support resources available for the anticipated demand?

By answering these questions, system architects are more likely to uncover system incompatibilities before they occur, in addition to helping make the build or buy decision.

---

Architecture

A system architecture specifies the technologies to be used to implement one or more information systems. It serves as an outline for detailed design, construction, and implementation. The highest level plan for solving systems problems is the system architecture.The system architecture is composed of all the systems and subsystems that make up the entire information system of the organization. This includes databases, application logic, and decision support systems.
To develop this high-level plan, several steps are required.

• Distinguish between operational and decision-support applications
• Decompose large systems into layers and partitions. This simply means to look for subsystems and separate them from the overall system logically
• Separate application logic from user interfaces
• Treat abstractions as real: This design principle means to move logic into data (to make the abstract real)
• Maintain a balance between the roles of the database management system and programming languages
• Consider the major interfaces to users and other systems