Home
 > Research and Reports > TEC Blog > Rewrite or Wrap-Around Old Software? Part One: Event Summ...

Rewrite or Wrap-Around Old Software? Part One: Event Summary

Written By: Predrag Jakovljevic
Published On: June 7 2004

Event Summary

There is a small group of vendors with brave and fresh ideas, which are by no means the prerogative of the biggest and the richest. This group has chosen to rewrite their applications on a new, possibly future-proof application framework. The intent of these visionary vendors is to address the ever increasing market awareness of the following facts:

  1. That almost every business changes and that software must change with the business (see What's Wrong with Application Software? Business Changes, Software Must Change with the Business.);

  2. Even small businesses are really unique one size can never fit all, thus, custom software is a requirement for many enterprises, even for the smaller ones (see What's Wrong with Application Software? Businesses Really are Unique - One Size can Never Fit All);

  3. The high cost of development, support, and enhancements in terms of money, time, and quality limit the ability of installed legacy software to meet many business demands (see What's Wrong with Application Software? It's the Economics).

At the same time, these vendors have been maintaining or improving their functionality, although some observers may contend that their bold' moves have been virtue made out of necessity.

The persevering tough economic climate extends the time of opportunity for the nimblest companies. It appears that a large number of manufacturing enterprises within the lower-end of the market have yet to deploy an enterprise package, particularly in emerging markets. Some of them have cited being intimidated by the complexity of enterprise resource planning (ERP) and associated enterprise applications as deterrence of implementing one so far. Still, like their bigger counterparts, smaller enterprises also have to efficiently run and expand their operations while maintaining strict control over costs/expenses, cash flow, and inventory turns/levels.

As an example, Intuitive Manufacturing Systems (www.intuitivemfg.com) is one of the incumbent mid-market vendors that have long attempted to mitigate the actual and perceived barriers to ERP acceptance by smaller enterprises. Moreover, in a time when many peer vendors had to backpedal product development and expansion because of market conditions (i.e., the post Y2K slump combined with the ongoing recession), Intuitive continues to pragmatically expand its product depth and breadth and geographic coverage, and to render itself as a more apparent ERP solution for the small and medium discrete manufacturers.

The rapid pace of global business nowadays places a unique set of challenges on all enterprises looking to improve and automate their operations, and at the same time, remain poised to adapt quickly to change. With increased competition, globalization, and mergers and acquisition activity, enterprise software buyers increasingly realize that product architecture plays a key role in how quickly vendors can implement, maintain, expand/customize, and integrate their products. The product architecture is going to do much more than simply provide the technical functionality, the user interface (UI)/presentation, and the platform support. It is going to determine whether a product is going to endure, whether it will scale to a large number of users, and whether it will be able to incorporate emerging technologies, all in order to accommodate increasingly evolving user requirements.

However, it takes excruciatingly painstaking efforts, industry domain knowledge, and resources (often estimated in hundreds of "man-years") to devise and build an enterprise system from scratch. In deciding how to write it, every software vendor makes a big, expensive commitment to the technological underpinning (e.g., programming language, operating system platform, and data access technology) it has to select at the beginning of the project. Often, the selected language and the data access technology are tightly integrated and not easily separated later.

This is Part One of a two-part note.

Part Two will continue the tutorial.

First Response is to Evolve

Once the body of software code that comprises the core of the enterprise system has been written, which encompasses the business logic the vast collection of rules that define required business transactions and the rules and conventions for ensuring data accuracy, integrity/completeness, and appropriateness the vendor is naturally reluctant to rewrite that core (which was difficult to write and maintain in the first place) in a new language or make the major structural changes necessary to employ a newer, more powerful database or operating system (OS) platform technology. Therefore, when that compelling new technology does appear, it is quite common in the industry for an enterprise application provider to surround its old ERP/accounting core software in a "wrapper" of newer technology, whose goal is to effectively obfuscate the old technology, giving it the latest graphical "look," or providing an easier means to access the core business logic and data from other more modern systems or devices, or from the Internet.

Many ERP and accounting back-office systems in the market today were originally created in — and still contain — cores written in non-mainstream, or even antiquated technologies. Strategies employed to wrap older products include putting contemporary Windows graphical user interfaces (GUI), often referred to as "screen scrapers" or web browser-based UIs on them, or, lately, providing new Web Services to rejuvenate their aged products by accessing the old business logic components and databases.

Hence, most vendors have naturally chosen to evolve their existing application framework to meet these market needs. Evolving means a slower process where incremental changes are made to the existing architecture until it eventually meets these demands. However, if history helps us predict the future, it is very difficult to execute this strategy effectively, and only the most resourceful or steadfast vendors are tipped as winners in the long run. Thus, one should be aware of how technology might develop in the future, while conducting the alignment of business and IT. Across the application life cycle, the high cost of development, support, and enhancements in terms of money, time, and quality limit the ability of installed legacy software to meet many business demands.

Once other proprietary technologies are introduced into the research and development equation, vendors have to deal with translation, interface, and performance issues, not to mention the pain of migrating existing customers and maintaining multiple product versions. On the other hand, using technologies that are intrinsically compatible should result in faster and less costly development. As a result, the Intuitive ERP suite, which, for example, has been completely rewritten in the Microsoft .NET managed code framework, should not have to contend with technology conflicts, trade-offs, or inefficiencies resulting from mixing or wrapping technologies. In contrast, a smaller vendor that covers multiple platforms often spends more than a half of its research and development budget on porting issues; thus a cross-platform solution remains largely the prerogative (and a consequent burden) of only bigger vendors.

The Internet as a Solution

On the other hand, the unfortunate circumstance for many vendors has been their possibly hasty jumping onto the web browser, "thin-client" bandwagon of the late 1990s. The benefits of the approach have since been touted by these vendors and disparaged by competitors and some early adopters. The advantage would be that any computer with secure access to the Internet can access the product, since by simply typing in a URL address one would have access to the system. There are potential savings in terms of deployment, maintenance, support, and upgrades, since the changes on the server side are instantly available to all users. With an Internet-only enterprise system in place, client-side software upgrades become unnecessary, browser-based applications significantly simplify the training, and tying together far-flung locations of an enterprise becomes simpler too.

Still, while this approach might have value from an IT perspective, it has not necessarily improved the user experience of the application. In fact, many end users have even complained about the decreased usability and performance of the applications in pure-Internet mode. Users report serious decline of application performance due to the numerous HyperText Markup Language (HTML) roundtrips, cumbersome hyperlink navigation, and slowed down networks. Even after upgrading the network, bolstering server farms (as larger server hardware and web server software are required), and redesigning the interface to streamline navigation (via, e.g., short key combinations), many users are still yearning for a rich' client/server interface metaphor. Thin client architectures also do little to leverage the hand-held wireless devices, mobile phones, and other forthcoming smart technologies. Thus, many vendors have since, within their suites, delivered richer, more dynamic, and higher performance UIs with tight integration to Microsoft desktop office products for nearly always-connected, power users, and pure HTML/Dynamic HTML (DHTML) UI for external and casual users of the system.

Extending back-office applications to the Internet stems from the intent of many IT organizations not to reinvent the wheel in their scramble to create e-commerce applications. By extending the existing ERP system to support e-commerce, organizations not only leverage their investment in the ERP solution, but can also speed the development of their e-commerce capabilities. However, as mentioned earlier, traditional enterprise systems have proven difficult to change and extend. Barricaded behind complex, proprietary application programming interfaces (API) and based on complex, nearly indecipherable relational database schemas, traditional ERP systems did not readily take to e-commerce. Thus, transport and communication technologies like Web Services, message brokers and queues, electronic data interchange (EDI), and eXtensible Markup Language (XML) get all the attention, but the inherent problem of old core code and business logic duplication are often hushed up, or not discussed openly (for more information, see Integrating All Information Assets).

Leading enterprise application vendors have been trying to oblige users' demand for e-commerce capabilities in their ERP solutions. The first stage in ERP's conquest of the Web was to allow browser access through support for HyperText Transfer Protocol (HTTP), HTML, and Java. This stage of adding a Web access layer onto existing old client/server systems has almost been completed by a majority of ERP vendors. This is, however, only a short-term solution, since only the client piece has been rewritten to be accessed over the Web, and because both the nature of interaction and the kind of casually visiting e-users are different compared to traditional in-house power user system interactions.

This concludes Part One of a two-part tutorial.

Part Two will discuss Extending to the Web and Challenges.

 
comments powered by Disqus

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.