Where Is ERP Headed (Or Better, Where Should It Be Headed)? Part 2: Product Architecture and Web-Basing

Part 2: Product Architecture and Web-Basing
P.J. Jakovljevic - April 20, 2001

Executive Summary 

A typical ERP system now offers broad functional coverage nearing the best-of-breed capabilities; vertical industry extensions; a robust technical architecture; training, documentation, implementation and process design tools; product enhancements; global support and an extensive list of software, services and technology partners. While it is not a system-in-a-box yet, the gap between its desired and actual features is becoming smaller every day.

ERP vendors, on the other hand, are not doing so well, possibly because they have been busy developing, acquiring, or bundling new functionality so that their packages go beyond the traditional realms of finance, materials planning & management, and human resources.

Users' visions of ERP are evolving from tactical to strategic, and users are no longer willing to choose between integration and function. Within the next two years, ERP will be redefined as a platform for enabling e-business globally.

Therefore, users need to be aware of the trends within the ERP market so they can take into account all the necessary factors when making an ERP software selection: product functionality, product technology requirements, vendor corporate strategy, and vendor corporate viability.

This part discusses how a flexible and agile ERP system needs an adaptable architecture and how easy integration to 3rd-party applications has become a key selling point for ERP vendors. Also with an Internet-only ERP 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. To do this in an appropriate manner, ERP vendors have to completely redesign their applications for a true e-business environment, which takes serious resources and commitment.

About This Note 

This is a four part note, which each part covering two of the eight trends we have identified. Each part contains links to the preceding parts. The trends covered in each part are:

3 - Flexibility, Agility & Interoperability Enabled by Adaptable Architecture 

The rapid pace of global business nowadays places a unique set of challenges on companies looking to improve and automate their operations, and at the same time, remain poised to adapt quickly to change. With increased competition, deregulation, globalization, and mergers & acquisition activity, buyers increasingly realize that 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 functionality, the user interface, 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 increasing user requirements.

An adaptable architecture is the least common denominator for a flexible and agile ERP system. Although a component-based architecture is not an explicit requirement for ERP 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 users through a set of steps to achieve a desired end result), intelligent messaging and workflow architectures, and an intuitive, easy-to-use user interface.

Componentization refers to the act of breaking up large, monolithic ERP systems into individual modules or components that would work together. It is the practical embodiment of object-oriented programming (OOP). Object-oriented software design and programming were 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.

An object class is a combination of data and processing logic. The data for a class may correspond to a relational database table, but this is not necessarily the case. The processing logic comes in methods, which are similar to subroutines or procedures. 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.

Component Based Architecture 

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 ERP vendor has established component architecture, it becomes easier and safer for IT to customize the systems.

Componentization proves to be crucial to enable ERP systems to support e-business activity since the new e-commerce capabilities are being delivered as individual components. Componentization also helps the vendors extend the core ERP system with SCM, CRM, and other ERP-adjacent solutions.

Interest in componentization, however, began long before 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 ERP 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.

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 (in the future), or Enterprise JavaBeans (EJBs). Some vendors who had attempted this approach have experienced a harrowing, time- and-resource-consuming, make-or-break transition. We believe that less than 45% of ERP vendors will deliver a completely component-based architecture within the next four years (70% probability). We also believe that the first vendors who deliver a truly open, modular system will capture the lion's share of the remaining non-penetrated ERP market.

Open Interfaces and Improved Integration 

While ERP customers may not be fully aware of the benefits of componentization as yet, they have been embracing the more open interfaces and improved integration capabilities that the vendors are providing, capabilities also intended for the componentization effort.

During the past few years, ERP vendors have opened up their tightly interwoven modules and created application programming interfaces (APIs) to connect to 3rd-party best-of-breed systems. ERP vendors are offering a broad range of open integration schemas, including extensible markup language (XML) messaging and proprietary connectors or open APIs, since easy integration to 3rd-party applications has become a key selling point for them.

SAP, for example, has created over 1,000 business application programming interfaces (BAPIs) for use in integrating third-party products with the core ERP system as well as applications linking enablement (ALE) via interchange documents (IDOCs), standard flat file formats for common information exchanges. This requires open APIs to enable the integration of third-party data reporting and analysis tools as well as other above-mentioned ERP extension tools.

Instead of the costly, risky move to full componentization, most ERP vendors have selected a safer approach. They use component-based APIs to construct a "faade" for their existing application. When done properly, these APIs provide programmatic access to common business objects (e.g., an order, a business partner, a delivery), which are mapped to the existing application's functionality in a way that shields users from the complexity of the underlying code. However, APIs alone are not sufficient. To bridge the differing semantics and business processes enabled within each participating application in an extended ERP environment, either vendors or users must employ message broker technology (a special-purpose, preferably 4GL tool that can readily transform and route data as it moves between applications).

Implications of This Trend 

Despite the user preference for a single, 'one-stop shop' vendor, componentized software products, interoperability standards and Internet technology will lead to fewer large-scale projects and an ongoing stream of smaller ones. Easy integration to 3rd-party applications has become a key selling point for ERP vendors as thus many of them tout the provision of connectors to/from their systems and/or provision of integration development tools (e.g., Forte or Progress Software). However, users should vigorously question their potential enterprise applications providers the following:

• Which industry interoperability standards (e.g., Open Applications Group Integration Specifications (OAGIS), XML, etc.) are supported?
  
  
• Do they provide message-based flexible interface or a rigid code-based integration?
  
  
• Do they provide basic batch-run interfaces or more advanced real-time, interactive two-way connections between applications?

4 - Web-Basing of ERP Systems 

Indisputably, one of the most significant trends in the ERP market today is the advent of e-business. No industry remains unaffected by the changes created by the explosive development of the Internet, despite the recent deflated enthusiasm and negative market sentiment owing to a demise of dot-com companies, economic slowdown and crippling of tech stocks. As the reality of enabling seamless web-based collaboration between companies and their customers and suppliers becomes more of a reality each day, ERP 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 Web.

Extending ERP 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, ERP systems have proven difficult to change and extend.

Barricaded behind complex, proprietary APIs and based on complex, nearly indecipherable relational database schemas, ERP systems do 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 ERP 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 client/server systems has almost been completed by a majority of ERP vendors. This is, however, only a short-term solution, 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 ERP 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.

Implications of This Trend 

With an Internet-only ERP 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. To do this in an appropriate manner, ERP vendors have to completely redesign their applications for a true e-business environment, which takes serious resources and commitment. 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 loosing the market share.

Conclusion of Part 2 

This concludes Part 2 of a four part note on ERP applications trends. This part covered two trends: the challenge ERP vendors face in developing an adaptable architecture that is flexible, agile, enabled for interoperability, as well Web-basing ERP systems.

Part 1 covered two trends: ERP functional scope expansion and sharper vertical focus.

Part 3 covers provision for e-Business components and mid-market shakeout.

Part 4 covers the advent of application hosting services and new pricing models.