Business Application Implementation Research Paper Starter

Business Application Implementation

This article will review the current options for companies implementing business applications to support overall organizational objectives. Three primary options exist for business application implementation: custom-built applications, build-and-buy applications, and buy applications. The pros and cons of the buy vs. build question will be reviewed, along with the implications for IT support, cost benefit, and long-term business objectives. The business case and benefits associated with each of these application deployment options, including SOA (service-oriented architecture) and ERP (enterprise resource planning), will also be explored in the context of enterprise-wide business application adoption. The evolving role of information technology departments in supporting and shaping overall business strategy through business application deployment will be analyzed within the framework of the modern business climate, specifically in relation to mergers and acquisitions, industry consolidation, and the rise of global corporations.

Keywords Business Applications; Commoditized Applications; Core Applications; Enterprise Applications; Legacy Systems

Information Technology: Business Application Implementation


The options for third-party business applications available to organizations have never been greater. Organizations large and small have unprecedented access to cost-effective, out-of-the-box applications that can be deployed via the web with little or no development time or in-house expertise to support them. The ubiquitous acceptance by users of web applications has spawned a whole generation of ready-made business applications that are not only user friendly but also surprisingly familiar in their look and feel to many common web-based (non-business-specific tools).

In the 1990s, IT departments were integral in supporting networks, computer hardware, software installation, and business applications such as e-mail. IT departments also provided access to organizations' databases and other company data via password accounts. Because of the perception of IT as gatekeeper and protector of company data, IT departments were sometimes regarded as inhibitors of progress. Over time, IT departments naturally segmented into areas that support specific company needs, an important one being the installation and support of business application software. Outside the realm of IT, software-application developers create custom business applications that support day-to-day operations. IT support for business applications tended toward standard out-of-the-box applications that were available to users on their desktop, but in many cases, IT departments supported both third-party (vendor) applications and custom-build applications (legacy applications) in tandem.

In the early twenty-first century, IT departments began to manage and administer multi-layered, service-based architectures that require a much more global overview of business application interaction. The proliferation of web-based applications has changed the role of IT within organizations as well as the relationship between IT staff and the end users of business applications. Many web-based applications require little or no IT support for installation, maintenance, or support. At the same time, the role of IT personnel has changing to a more strategic one, as IT departments shift focus to assess the interoperability of business applications across organizations.


Evolution of Business Applications Implementation

Custom-Built Applications

Before organizations had access to cost-effective and readily available digital networks, organizations operated in more geographically specific markets and segments of a supply chain. Electronic inventory control systems and other internal business applications and databases were proprietary in nature and were built to serve the specific needs of an individual organization. The implementation of this type of application required large amounts of internal IT and developer support for deployment and problem fixing. The lifecycle of design, development, testing, and deployment was most often the sole responsibility of internal company support functions, namely IT and engineering. The quality control of applications was also the responsibility of the organization that owned the application, usually associated with the relatively high maintenance costs of development and problem fixing. The cycle of in-house development and deployment was often tedious, expensive, and frustrating for end users.

Many custom-built applications are designed around core functional areas in a business. These core areas are likely to be the most strategic and specific for a given business's operations and may not have an existing commercial application available to replace its functionality. Such was the case with MCI, which became part of Verizon in 2006, and any of the applications that touched its telecom network. MCI's custom-built system and user applications were a strategic advantage to the company and its customers. The following set of questions and answers is an example of the decision tree that MCI used when investigating whether to buy or build a system to track a third-party services inventory. These questions allowed the company to logically and deliberately analyze what the best option was when deciding whether to build or buy the new software application. The following questions represent the MCI decision tree to help decide whether or not to build applications (Traylor, 2006, p. 23):

Q: Is there competitive advantage in building?

A: No competitive advantage.

Q: Is the project covering core or generic business processes?

A: Generic.

Q: Is there business expertise in-house to build something world-class?

A: Yes, but resources are tight and this is not a priority.

Q: Is there technical expertise in-house or available on the market to build something world-class?

A: Same as previous answer.

Q: What is the total cost of ownership?

A: Low to medium.

The following questions represent the MCI decision tree to help decide whether or not to buy a particular application (Traylor, 2006, p. 23):

Q: Do capabilities exist that meet or nearly meet our needs?

A: There are two packages that meet our needs.

Q: Can our business processes fit those imposed by the package?

A: Yes.

Q: Is the vendor going to be around for a long time? Many of the best solutions come from smaller vendors, so it is necessary to review their financials.

A: Both vendors are viable.

Q: Does the vendor fit into our cornerstone technology stack? (For MCI: Microsoft .Net on the portal side, IBM Websphere on the back-office OSS side.)

A: Yes, for both vendors.

Q: Does the vendor have a vision that is compatible with our vision of future growth needs for the package?

A: Excellent vision; better than we have in this area.

Q: Does the vendor have a demonstrated ability to deliver releases on time?

A: Yes, based on reference checks.

Q: What is the TCO (total cost of ownership)? Is it less than building and maintaining this ourselves?

A: An RFP [request for proposal] was conducted and significant concessions were obtained. TCO is favorable.

The outcome of working through the decision-tree questions allowed MCI to make the determination to buy the software application that was needed. This series of logical and linear questions helped take the guesswork out of the buy vs. build decision for this particular software application.


Since the early 1990s, the business applications space has become crowded with out–of-the-box business applications that can be deployed quickly and easily across organizations. One of the most widely used and ubiquitous applications is Microsoft Office, with its spreadsheet, word processing, database, and presentation applications. Business applications for customer-relationship management (CRM), document-control systems (DCS), and inventory asset tracking entered the marketplace and helped further revolutionize the individual workspace. Desktop applications allowed for the quick rollout to individual users, and some, like Microsoft Office applications, initiated the era of application compatibility. For instance, a user creating a document in Microsoft Word could easily share Word documents with any other user who was running the same application software on his or her computer.

Even as organizations began to rely on a core of desktop applications, they continued to build custom applications to support more specific internal processes. Out of necessity, companies developed large, complex, and costly systems and applications to help automate core business processes. As a result, most organizations maintain a mix of vendor (bought) and legacy (custom built) applications. As the need to access business analytics increases, so does the necessity for organizations to build connectivity between disparate...

(The entire section is 4058 words.)