First Monday
E-Business Application Development: Development The Paradigm Shift from In-House Application Development by V.V.S. Raveendra

This article discusses the fundamental differences that need to be noted in the management of an e-business application development project from a traditional in-house application development project. The essence is that the cost of an e-business project could be many times the cost of an in-house project.

Contents

Introduction
Analysis
Conclusion

++++++++++

Introduction

As enterprises get involved more in e-business projects, there are new dimensions to be addressed in software development. Many enterprises have host-centric or client-server applications that have been used in-house for decades. An e-business project is not merely a migration from a legacy application to a Web-enabled application. This article deals with the additional dimensions that have come into play in the era of e-business. These factors affect cost, schedules, dependencies, complexity, interfaces, resource requirements, infrastructure (both technical and business) among others. They have to be taken into consideration, before fully embarking into an e-business project, whether it is B2B or B2C.

++++++++++

Analysis

Business Process Reengineering:
When a "brick and mortar" company has decided to sell products on the Internet through its Web site, it has also decided to do Business Process Reengineering (BPR). Selling products the traditional way is not same as selling products on the Net. One needs to do in-depth analysis of the change in business processes and the necessary infrastructure needed to sustain those business processes. The Web site can be launched with state-of-the-art technologies and a number of new customers can be attracted, but if business processes are not in place to support them, the company could be in deep trouble. Gap analysis of all the business processes is the first step in any e-business project.

User Requirements are rarely known 100%:
Traditional in-house projects had requirements defined within the organisation and could be captured 100%, by holding workshops or interviews between the users and owners of the project. If the requirements cannot be met with the available infrastructure, users could be told to live with the available ones. For example, if GUI-based clients could not be developed, users could be told to adjust themselves with text-based green screens. In the case of launching an application or Web site over the Internet, the users are customers - and their requirements are varied. It is humanly impossible to capture all the requirements of all customers or discover all of the ways of addressing them properly. If a business cannot provide at least the most desired features to its customers over the Internet, we all know that another online shop is a click away. It is a fundamental change that user requirements are rarely known 100%. It is up to the project team to get into the shoes of the users - or customers. Similarly, user acceptance testing can rarely be 100%. The search log files, Web server log files, and feedback would provide some measure of the expectations and problems of the customers. An Internet application project might sometimes be a secret because of business competition, until it is launched on a Web site for the customers. In such cases, customer feedback would arrive only after completion of the project.

Multiplicity of User Interfaces:
Internet customers could be using any browser such as Internet Explorer or Netscape. They might be using an old version of a browser or an old 80486 PC with Windows 3.1 or a cell phone or a PDA or Web TV. They might be using a brand new computer, but with a monitor set at an unexpected resolution. To make sure that a Web site has consistent look and feel with equal performance, the user interface (UI) and application should be flexible to handle a variety of environments. For example, the interface has to deal with various monitor resolutions to make sure that alignment of the screens or appearance of graphics are not lost. Not all browsers uniformly support scripting languages like Javascript, JSP, and ASP.

Printing:
Traditionally printers in an enterprise are installed to meet an expected load; applications are tested to make sure that output is perfect. If a customer has to print any form at home, the designer never exactly knows what kind of printer is available locally. Printable forms or screens need to be designed to allow for acceptable output on a wide variety of devices. Too many graphics could make printing very slow. An old version of the browser might not support the Javascript print facility. Alignment of images with text could be lost.

Backward Compatibility:
The need to consider backward compatibility, with various operating systems, printers, and monitors, has now come to application design and development. In a B2B scenario, a partner could send purchase orders (an XML file, for example) in an older format and the application needs to deal with it appropriately. Therefore, an application has to operate well with a variety of software and hardware considerations, not just the latest version of a browser. In addition, not all browsers conform to standards which adds more difficulties.

Ease of Use:
GUI navigation for an in-house application could be complicated and users could be trained. On the other hand, screens on a Web site could be intuitive and navigable by anyone. The customer could be a 70 year old grandmother sending a birthday gift to her grandson and vice versa. Ease of use and intuitive navigation are most important and hence demand more effort in design.

Beautiful Screens:
The era of e-business has brought the notion of BUI (Beautiful User Interface). The GUI screens for in-house applications need not be beautiful. But the screens on a Web site need to be beautiful to keep the customers happy. When rest of the business processes are same, an attractive Web site could be a unique selling point. This need has led to a rise in creative and artistic interfaces, which have budgetary implications.

Legal Compliance:
Web sites need to conform to the cyberlaws of countries in which business is conducted. Government regulations could force modifications to a Web site. Addressing legal requirements early in a project cycle would avoid unpleasant surprises later on.

EAI and IAI:
If there are legacy applications on various platforms, before launching an e-business enabled Web site, managers should think of integrating all of them. In established organisations, Enterprise Application Integration (EAI) becomes the bottom line. The new Web applications have to be interfaced with the old applications synchronously or asynchronously depending on the business requirements and commitments. It means that new EAI products have to be bought and skilled professionals have to be inducted. If EAI is not handled carefully, it could become a big risk in an e-business project, and affect the budget, schedule, performance, etc. If two different companies are integrated in a B2B scenario across Internet, then IAI (Internet Application Integration) also needs to be taken into account.

Availability:
Applications meant for in-house use traditionally are not needed 24 hours a day and 7 days a week. A Web based application requires a 24X7 model, since another online store is a click away. Availability is addressed at a low level by hardware itself, employing back up processors and communication channels. Operating systems, built on top of hardware, address availability in their own way. Products like RDBMS or Web Application Server offer features to address availability by clustering and warm backup. Now, even applications have to be built for better availability on top of such products (see Figure 1).

Security:
In-house applications might not implement more than user and role based security with Access Control Lists (ACLs). On the other hand an e-business application has to address many more. The application should be able to do encryption and decryption, which might need new products to be bought or upgrades of existing ones. Since encryption and decryption need processing power, depending on the volumes, bigger servers have to be installed, or there could be performance problems. Digital certificates and certification authorities also have to be considered depending on requirements. These influence the infrastructure that needs to be in place.

If in-house users have to be given access to applications through the Internet, it may be necessary to implement a virtual private network (VPN) or a secure tunnel. It should be developed so that security attacks are not possible (such as a man-in-the-middle attack).

If programs written in a scripting language hare buggy, it would be obvious to users and occasionally could crash browsers. If the user has an older version of a browser, it might not support SSL and HTTPS. Once the public gets to know a bug in an application, the message spreads fast and it might even attract the attention of the media. Depending on the criticality of the application on the Internet, security testing is required. One might also employ an external service provider to do performance and security testing.

Exponential Growth:
Once a Web site is launched to sell products, there can be many factors beyond immediate control! In a traditional business, the geographical location, marketing strategies, and the physical size of a store limit its reach to the customers. On the Internet, there is no limit to the number of customers a site can attract. Similarly the number of orders and the amount of feedback can become quite large. Enterprises need to address a priori, not only the scalability in terms of IS, but also of business processes.

In a normal in-house project, capacity planning can be done and data centre infrastructure can be ramped up to meet voluminous demands. Once an application is launched on a Web site, the number of hits and business transactions received could potentially be unlimited. Volumes can suddenly vary because of special promotional offers, tax benefits at the end of financial year, or holiday shopping. Unlike in a superstore, no one at a Web site has to queue up! The differences in the growth models of "brick and mortar" and dotcom companies are depicted in Figure 2. For comparison, the demand on a site like www.olympics.com (which is event-based) is also shown in Figure 2. Organisations have to invest in infrastructure to meet these demands and it adds to the cost of a project. Although growth is good news, inability to meet the demand could be disastrous for a business.

Data Web housing:
On the Internet each and every click of a visitor can be tracked. This is known as data Web housing (or click stream analysis or business intelligence) and is the analogue of data warehousing of in-house back end data. Beyond nominal tracking, this activity could become a different project altogether.

Testing:
Testing an Internet application has many more factors to address than in an in-house project. Tests need to be done for:

A test facility also has to be set up to work with various resolutions of monitors, printers, and browsers. Although the testing cannot be exhaustive, it should be done to a reasonable extent. Testing has to be much more than in a normal project to ensure that security and scalability problems do not arise. Testing activity alone could consume much more time and effort than in a normal in-house project.

++++++++++

Conclusion

There are numerous factors to be addressed in Internet-based application development, compared to normal in-house ones. These issues could arise from user interfaces, application integration, security, ease of use, scalability, and availability. Early planning to tackle these issues could bring a lot of peace to the e-business project managers.End of article

 

About the Author

V.V.S.Raveendra received his Ph.D. from the Indian Institute of Technology, Madras in 1998. From January 1997 onwards he has been working for Tata Consultancy Services, at Madras. His current interests are Java, Internet security, and e-business. At present, he is in the U.K. on deputation, with AXA SunLife in Bristol. He has published in refereed journals such as Advances in Engineering Software and the International Journal for Numerical Methods in Engineering.
E-mail: Varanasi.Raveendra@axa-sunlife.co.uk
E-mail: varanasi_vsr@yahoo.com

Bibliography

  1. E-commerce intelligence: measuring, analysing, and reporting on merchandising effectiveness of online stores, Stephen Gomory et. al., at http://www.ibm.com/iac/papers/eabs3.pdf
  2. Managing e-commerce reliability, eBay style, Anne C. Lear, http://computer.org/itpro/get_to_know/profile_Wilson1.htm
  3. Reflect.com: Building a dynamic and distributed architecture, http://dcb.sun.com/practices/casestudies/reflect_part1.jsp
  4. Using production grammars for software testing, http://www.cs.washington.edu/homes/egs/kimera-dsl99/

Editorial history

Paper received 6 December 2000; accepted 31 December 2000.

Contents Index

Copyright ©2001, First Monday

E-Business Application Development: The Paradigm Shift from In-House Application Development by V.V.S. Raveendra
First Monday, volume 6, number 1 (January 2001),
URL: http://firstmonday.org/issues/issue6_1/raveendra/index.html