> Research and Reports > TEC Blog > What's Wrong With Enterprise Applications, And What Are V...

What's Wrong With Enterprise Applications, And What Are Vendors Doing About It? Part Two: A New Framework Strategy

Written By: Predrag Jakovljevic
Published On: June 23 2003


With increased competition, deregulation, globalization, and mergers & acquisition activity, enterprise software buyers realize that product architecture plays a key role in how quickly vendors can implement, maintain, expand/customize, and integrate their products. Many in the enterprise applications vendors' community recognize that these are unmet realities and are attempting to offer solutions that will deal with them. While it is not practical to look at every strategy and every vendor's nuance, this note looks at some important examples representing distinct strategic approaches.

Part One of this note summarized the recent TEC series "What's Wrong With Application Software" and analyzed the vendor strategy of Evolution to address the problems cited.

This part will cover a second strategy: a New Framework.

Part Three will discuss a third strategy and make User Recommendations.

Strategy Two A New Framework

In addition to following the composite applications trend discussed in Part One, some vendors have chosen to also rewrite their applications on a new application framework. The intent of these visionary or brave vendors is to address the four issues discussed above while maintaining or improving their functionality although some may contend that their moves have been virtue made out of necessity. Examples of vendors who have taken this road would include PeopleSoft and IFS. In both cases, products have been delivered and implemented, and, therefore, their strategy has been proven in the marketplace.

Particularly impressive would be IFS, both in terms of strong vertical functionality and a few generations mature component-based product architecture that has been amenable to accommodating many of the above four challenges, as illustrated in the fact that over 80% of its global customers are on the single code base and in its components' compatibility even if coming from different major product releases (see IFS To Be At Customers' (Web) Service).

An adaptable architecture is the least common denominator for a flexible and agile enterprise system. Although a component-based architecture is not an explicit requirement for enterprise applications' flexibility, component-based applications generally provide greater flexibility than their monolithic counterparts. Further prerequisites for flexibility will be the abstraction of technical complexity (manifested via the use of intuitive tools, aids, or wizards that guide user through a set of steps to achieve a desired end result), intelligent messaging and workflow architectures, and an intuitive, easy-to-use user interface.

Component-Based Product Architecture

Componentization refers to the act of breaking up large, monolithic enterprise systems into individual modules or components that would work together. It is the practical embodiment of object-oriented programming (OOP), which was developed to enhance software maintainability and to simplify the creation of advanced graphical user interfaces (GUIs). Object orientation means that design, linkages, etc., use objects as their basic building blocks, which is a radical departure from traditional procedural' design and coding methodologies. By maintaining processing logic with the data it works with, programmers have an easier time finding reusable pieces. Therefore, object-oriented systems can be significantly smaller and easier to maintain than classical procedural code in which procedures and data are separated.

By breaking up the large applications into components, vendors are able to more quickly fix or add functionality. A component can be something as simple as a supplier record, or a more complex business process or workflow. The accounts payable component, for example, could be enhanced without having to touch any other financial components or any of the other modules, such as planning or logistics. And once the vendor has established component architecture, it becomes easier and safer for IT departments to customize the systems.

Componentization has proven to be crucial to enable traditional back-office systems to support e-business activity since the new e-commerce capabilities are being delivered as individual components. Componentization has also helped the vendors extend the core ERP system with supply chain management (SCM), customer relationship management (CRM), and other ERP-adjacent solutions.

Interest in componentization, however, had begun long before the advent of e-commerce. The perception at the time was that ERP applications were too big and unwieldy, and that they needed to be more flexible. Componentization would not only make it easier for the ERP vendors to enhance their solutions but also make it easier for customers to upgrade the software. With componentization, a customer could incrementally upgrade only selected components without having to upgrade the entire ERP solution, which usually would entail a substantial effort. In summary, component-based architecture is beneficial for the following reasons:

  1. It allows a developer to create a composite application in which typically a Web-based user interface accesses functionality in the packaged application.
  2. It can enable message-broker-based integration of several disparate packages or legacy systems.
  3. It allows a vendor to roll out new versions of the application in a modular, incremental fashion rather than all at once.
  4. It may drastically reduce the total application code.

Componentization is thus necessary for vendors to move their back-office systems into e-business and to provide other capabilities and therefore most vendors insist they remain fully committed to it, although progress has been moderate. The reason for this lies in the fact that componentization is enormously difficult to achieve even when the commitment is solid. With some honorable exceptions, most Tier 1 vendors have mostly succeeded in creating large-grain proprietary components, which are simply large function modules. On the other hand, IFS leads the pack of more nimble mid-market ERP vendors that have either entirely or to a significant degree componentized their products.

Influence of Web Services Technology

Further, emerging Web Services technology is likely to increase the concept's awareness and speed up its still fledgling adoption. Large vendors' endorsement of Web Services technology might indeed help them make up for their late adoption of component technology several years ago. Web Services have a potential of becoming the latest evolution of application integration technology and/or a revolutionary new application design model by enabling developers to create or enhance applications by connecting granular components that are accessed via platform-independent Web protocols. While Web services leverage the aged concept of objects' reusability, they may finally offer that extra mile by adherence to standards that are taking hold (see The SOAP Opera Progresses - Helping XML to Rule the World). Further, they tend to be simpler in nature, partly owing to the collaborative Internet standards. They also tend to be higher-level abstractions, which implies more likely platform independence and the opportunity for "mixing and matching" by developers. Furthermore, the strategy will help the likes of SAP further open and/or componentize their products, as standards like XML and eXtensible Stylesheet Language (XSL) make it possible to share data and have a common look-and-feel across an application, without necessarily dreadfully digging in the source code.

Implementing a fully component-based architecture requires that vendors completely redesign their applications and then rewrite it using C++, Java, or a component-based 4GL, and run it under component object model (COM), common object request broker architecture (CORBA), .NET or Java 2 Enterprise Edition (J2EE) frameworks. Some vendors who attempted this approach during the mid 1990s have experienced a harrowing, time- and-resource-consuming, make-or-break transition (e.g., former Systems Software Associates' (now SSA GT) BPCS 6.0, and former Marcam Solutions' (now Invensys Production Solutions) Protean). Still, SAP's decision to support more open standards from popular programming languages like Java, Visual Basic for Applications (VBA) and C++/C# to its support for evolving standards such as XML, Universal Description, Discovery, and Integration (UDDI), Web Services Description Language (WSDL), and Simple Object Access Protocol (SOAP) should give some homework to many like-minded enterprise application vendors.

PeopleSoft, on its hand, could be credited with arguably pioneering the zero-client footprint (a.k.a. "100% pure-Internet") architecture with its introduction of PeopleSoft 8 product release in late 2000 (see The Hype About PeopleTools 8). The benefits of the approach have since been touted by the vendor and disparaged by its competitors and some early adopters. The advantage would be that any computer with secure access to the Internet can access the product. Simply by 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.

Challenges of Web Service Technology

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 lamented about the decreased usability and performance of the applications in pure-Internet mode. Users report serious decline of application performance due to the numerous HTML roundtrips, cumbersome hyperlinks navigation, and slowed down networks. Even after upgrading the network, bolstering server farms, and redesigning the interface to streamline navigation (via, e.g., short key combinations), many users are still yearning for rich' client/server interface metaphor. Thus, many vendors have since, within their suites, delivered richer, more dynamic and higher performance user interface (UI) with tight integration to Microsoft desktop office product for nearly always-connected, power users, and pure HTML/DHTML UI for external and casual users of the system.

The more important issue would be the enterprise applications' amenability to harnessing Internet, and PeopleSoft is hardly the first or only vendor to have Web enabled its product. It has, however, been the first one to use the Web-enablement opportunity to rewrite the product on a simpler code and thereby kill two birds with one shot. Ross Systems would be a similar example of a mid-market vendor repeating the feat. Many leading enterprise applications have also finished rolling out their "next-generation" designs: Oracle released its E-Business Suite 11i in the middle of calendar 2000, SAP began rolling out its response depicted above in November 2001, and Microsoft Business Solutions has been harnessing its parent's .NET framework since about the same time.

As enabling seamless web-based collaboration between companies and their customers and suppliers becomes more of a reality each day, enterprise applications are poised to play a pivotal role. The concept of e-commerce is not really new to ERP: electronic data interchange (EDI) and electronic funds transfer (EFT) have been a part of ERP applications in varying forms for years, and are now in the process of being redefined (and given a makeover at the same time) to embrace the Internet and the Web.

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 APIs and based on complex, nearly indecipherable relational database schemas, traditional ERP systems did not readily take to e-commerce. Nevertheless, IT managers are finding an increasing set of options for not only extending these systems to support the Web and e-commerce but for other key activities, such as decision support. Underlying the new options are ongoing initiatives to break ERP systems into separate components (componentization), open up the core databases and proprietary application interfaces, and provide tools for customization.

Leading enterprise applications vendors have been trying to oblige users' demand for e-commerce capabilities in their ERP solutions. The first stage in the ERP's conquest of the Web was to allow browser access through support for HTTP, HTML, and Java. This stage of adding 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 will have 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 users system interactions.

The next stage, which has begun recently, is to extend the enterprise applications themselves to the Web, where they can be accessed and run by outside partners and customers. These Web-based applications are hybrid in form, bringing together proprietary legacy elements, either host-centric or client/server, with thin client, browser-based interfaces. The catch is to bring to the Web the advanced functionality of ERP systems, but broken into components and without the need for an additional layer of architecture. Some vendors have also begun to add mobility hooks into their suites so that ERP sessions can be accessed via wireless devices. In order for traditional ERP systems to be Internet ready, they will have to be:

  1. Fully browser enabled.
  2. Redesigned to be available to all corporate users, not just the special few.
  3. Redesigned to be available to customers and suppliers.
  4. Redesigned to use standard data interchange language, most likely XML, rather than proprietary protocols.

To do this in an appropriate manner, ERP vendors have to completely redesign their applications for a true e-business environment, on a standard-based J2EE or .NET compliant application server, which takes serious resources and commitment. The resulting application will then have been designed from scratch to be accessed over the Internet by a Web browser, and to be extendable by additional components, and managed by an application server with built-in security and integration features. Some vendors recognized the need early, while the vast majority waited till the trend was more obvious and are now engaged in a frantic catch-up race. The latter vendors face the possibility of losing market share.

A number of vendors deserve to be mentioned here owing to being somewhere between both the evolutionary and revolutionary strategy they have either completely rewritten or have released the pieces of new product releases on commonly accepted frameworks like J2EE or .NET, but have been burdened with a large customer base still running on a slew of older product that support now possibly obsolete technologies. Intentia International (see Intentia: Java Evolution From AS/400), Best Software, J.D. Edwards, Epicor (see Epicor Claims The Forefront Of CRM.NET-ification), QAD, Adonix, and Frontstep (now part of MAPICS, see Frontstep Ups The .NET Ante) would be only some worth pointing out.

Analysis of a New Framework Strategy

Nevertheless, building replacement products on a new framework is a higher risk strategy. The product functionality still quite matters and, while it is important for enterprise applications providers to implement the latest computer science quantum leap', there is no guaranteed correlation between first-to-market and the ultimate success in the market (in fact, based on many experiences, one could even argue that the correlation might be inverse).

While SAP, e.g., has not been known for speed, its holistic and meticulous approach to new product delivery this time again may give customers some breathing space between adopting new software standards and solutions, while at the same time upgrading and maintaining custom legacy environments.

Oracle, J.D. Edwards and PeopleSoft, on the other hand, while gaining market shares with their respective groundbreaking technologies a few years ago, have felt the displeasure of client bases that were far from being ready to make a significant technological leap. As a result, these vendors had to backpedal and rethink their older product releases discontinuation strategies. As a result of this evolutionary approach, customers should be able to modify, enhance and adapt individual Web services without changing other services, mitigating the need for the huge technology platform shifts and upgrades of the past disruptive technology advents. This should in principle allow companies to protect existing investments and add new functionality that can be reasonably easily designed, built, deployed, accessed and combined with existing Web services and syndicated across division, company and geographic boundaries.

This concludes Part Two of a three-part trend note.

Part One of this note summarized the recent TEC series "What's Wrong With Application Software" and analyzed the vendor strategy of Evolution to address the problems cited.

Part Three will discuss a third strategy and make User Recommendations.

About the Authors

Predrag Jakovljevic is a research director with TechnologyEvaluation.com (TEC), with a focus on the enterprise applications market. He has over 15 years of manufacturing industry experience, including several years as a power user of IT/ERP, as well as being a consultant/implementer and market analyst. He holds a bachelor's degree in mechanical engineering from the University of Belgrade, Yugoslavia, and he has also been certified in production and inventory management (CPIM) and in integrated resources management (CIRM) by APICS.

Olin Thompson is a principal of Process ERP Partners. He has over 25 years experience as an executive in the software industry. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry. He can be reached at Olin@ProcessERP.com.

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.