Second Task: Analysis of Develop vs. Purchase Recommendation Factors

This report provides a comprehensive analysis of the factors influencing the decision to develop or purchase software. It emphasizes the importance of technology validation, ensuring that the chosen technology aligns with genuine business needs rather than being driven by product demonstrations or analyst evaluations. The report stresses the need to identify core business requirements, focusing on what the software must achieve rather than on technology or design specifications. Architectural requirements, such as information security, existing infrastructure, and corporate standards, are also critical considerations. Furthermore, the report suggests examining existing solutions within the organization to avoid redundant implementations. By carefully evaluating these factors, businesses can make informed decisions about whether to develop custom software or purchase a commercial off-the-shelf (COTS) solution, ultimately optimizing cost, efficiency, and alignment with business objectives. The provided references support the information and guidelines presented in the report.

Second Task
Recommendations
For
Develop vs Purchase

Recommendation for develop vs purchase is affected by several factors which are given as
follows in details.
1. Validate the need for technology
The technology is a major effecting part for the software growth and development.
Many organizations often choose an enabling technology before identifying any
legitimate business need. Sometimes the project is not able to develop successfully
because of lack of technical knowledge and required technology knowledge. Decision
makers are very often awed by product suite success stories, dynamite product
demonstrations, and industry analysts' evaluation of technology—even when they
haven’t formally identified a need for the technology. Thus the proper validation for the
technology required is necessary to develop any software.
2. Identify core Business Requirement
The proper detailed knowledge is necessary about the project business requirement
because the software growth and the business requirement both are inter-related
terms. It is extremely important to focus on identifying business requirements—not
technology or design requirements. If a requirement can be only partially met or not
addressed by a solution, it is not a core requirement. It takes effort to identify these
requirements, and involving the right businesspeople determines the success of the
process.
3. Identify architectural requirements
To reduce the cost of operation and maintenance of this technology, these
organizations have established standards to which all solutions must adhere. It is
extremely important to identify any architectural requirements or standards that a
solution must support before determining if a COTS or custom solution is the best
choice. Some factors that may restrict the solution choice are as follows:
 Information security strategy.
 Existing or planned technology infrastructure.
 Existing systems with which the solution will be interfacing.
 Preferred architecture framework, such as J2EE or .NET
 Existing corporate standards, such as Web servers or browsers.
 Operating systems in use by the organization and its business partners.
4. Examine existing solutions
At this point, a business need has been pointed, ROI has been estimated, and both core
business and architectural restrictions have been identified. Leaders should now take a
good look at existing systems. Businesses will often implement solutions only to
discover that another system within the organization could have supported the solution
with little to no modification. It is not uncommon that different parts of an organization

are not aware of what systems exist in other organizational components. Thus, before
deciding on a solutions approach, you should determine if any existing system within
the organization can be easily scaled or extended to meet your business need.
5. Examine Required solutions
Examining for required solutions is also necessary for making decision about the
developer vs purchase. Leaders should now take a good look at required systems to
fulfill the all requirements in the development. Businesses will often implement
solutions only to discover that another system within the organization could have
supported the solution with little to no modification.
References
Bonow, R., Carabello, B., de Leon, A., Edmunds, L. H., Fedderly, B., Freed, M., ... & O’Rourke, R. (1998).
ACC/AHA guidelines for the management of patients with valvular heart disease: A report of the American
College of Cardiology/American Heart Association Task Force on practice guidelines (Committee on
management of patients with valvular heart disease) 11When citing this document, the American College
of Cardiology and the American Heart Association recommend that the following format be used: Bonow
RO, Carabello B, de Leon AC Jr, Edmunds LH Jr, Fedderly BJ, Freed MD, Gaasch WH, McKay CR,
Nishimura RA .... Journal of the American College of Cardiology, 32(5), 1486-1582.
Eagle, K. A., Guyton, R. A., Davidoff, R., Ewy, G. A., Fonger, J., Gardner, T. J., ... & O’Connor, G. T.
(1999). ACC/AHA guidelines for coronary artery bypass graft surgery: A report of the American College of
Cardiology/American Heart Association task force on Practice Guidelines (Committee to revise the 1991
Guidelines for Coronary Artery Bypass Graft Surgery) 11When citing this document, the American
College of Cardiology and the American Heart Association request that the following citation format be
used: Eagle KA, Guyton RA, Davidoff R, Ewy GA, Fonger J, Gardner TJ, Gott JP, Herrmann HC, Marlow
RA, Nugent WC .... Journal of the American College of Cardiology, 34(4), 1262-1347.
Cheong, H. J., & Morrison, M. A. (2008). Consumers’ reliance on product information and
recommendations found in UGC. Journal of Interactive Advertising, 8(2), 38-49.