What's Wrong With Enterprise Applications, And What Are Vendors Doing About It?


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, 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.

The product architecture is going to do much more than simply provide the technical functionality, the user interface (UI), 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. If one is to listen to most application vendors today, they are preaching integration, advanced functions, and technology. These are lessons what should be part of any new enterprise architecture.

In TEC's recent intriguing series of articles, named "What's Wrong With Application Software?" we discussed the realities of agile business versus the ability of contemporary application software to cope with those realities. Those realities included:

1 Economics Across the application life cycle, the high cost of development, support and enhancements in term of money, time, and quality limit the ability of installed software to meet many demands of business. While the aged product architecture is a technology problem, it is not the business problem, which considers time, money, and quality. Focusing on modifications as an example, the reason that modifications are bad is that they take too long, cost too much and often have quality issues. However, with changing economics, although custom or modified approaches will always cost more, albeit less sharply, what was impossible with traditional architecture may become practical for the business with next enterprise architecture. For more details, see What's Wrong with Application Software? It's the Economics.
2 Businesses change continually Change is a fact of life and software must change with the business. Software must be an enabler (rather than an impediment) of business change, both during initial deployment and across its life cycle. The current state of the market is "standard, configurable" applications, since the fallacy is that these applications can bring best practices to a business and be made flexible enough to accommodate the majority of businesses without significant modification. Although through the use of complex tables, parameters, and switches, the software could be pre-configured to handle a large number of pre-determined, "flexible" options, in truth, the flexibility is only to choose from a list of existing, predetermined options. Thus, while the issue of flexibility might have been solved for an initial implementation, it would not be the case for the ongoing business innovation. The next generation of enterprise architecture must allow for business change to be adopted on an on-demand basis as the business evolves. For more details, see What's Wrong With Application Software? Business Changes, Software Must Change With The Business.
3 Businesses are unique Industry to industry, company to company, all businesses have some uniqueness, and the idea that one-size-fits-all does not materialize. Application software has grown increasingly complex because it is trying to support too many conflicting features for different industries. Application software needs to evolve so that it recognizes the reality that businesses are unique, but not by adding software bloat' to existing products. Many of the added functions apply to only a few of the various industries addressed meaning that most other industries must suffer the consequences of these non-essential functions. Bloat, in the form of complex program logic is required not to execute the function, but to determine which of many paths the program must take. Thus, vendors need to build lean products that serve specific sets of customers plus allow the customer to build in their own, individual needs. For more information, see What's Wrong With Application Software? Businesses Really Are Unique - One Size Can Never Fit All.
4 Business processes, not application boundaries Business processes must be enabled across the artificial boundaries of disparate applications that must work together to support business processes. The next generation of application architecture must address the reality that business processes cross application boundaries. The architecture will need to provide business process integration, application integration, and application extension in order to allow companies to realize the full potential of their current applications. With all of these capabilities, the new architectures will initially be used to pull together diverse applications in a way that the resulting composite application is better than the sum of its parts. Eventually, the next generation of enterprise applications will also embrace these architectural capabilities in the application itself. For more information, see What's Wrong With Application Software? Business Processes Cross Application Boundaries.

Apparently, many in the enterprise applications vendors' community recognize these unmet realities and many 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, let us look at some important examples representing distinct strategic approaches.

This is Part One of a three-part trend note that will discuss three Strategies, as follows:

  • Part One: Strategy One Evolve
  • Part Two: Strategy Two A New Framework
  • Part Three: Strategy Three A New Approach

Part Three will also make User Recommendations.

Strategy One Evolve

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 such that 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 and/or steadfast vendors are tipped as winners in the long run.

As an object case, SAP's 3-tier client/server architecture introduced in 1992 provided the fundamental structure upon which client/server enterprise systems enabled information and process integration at the user, application, and data levels. The 3-tier client/server architecture remains a highly-scalable framework which provides the foundation for SAP business solutions today at more than 19,000 companies worldwide. While the 3-tier client/server architecture then abruptly replaced existing mainframe based systems, the latest SAP's technology framework named ESA (Enterprise Service Architecture) is instead devised to allow companies to gradually add important new levels of flexibility while allowing customers to maintain and build upon their existing solutions investments through Web services.

SAP's recent announcement of xApps (read "cross-applications") would also be an excellent example of an evolutionary strategy. With xApps, SAP is enabling composite applications to be built more easily since xApps uses SAP's NetWeaver infrastructure to tie other applications into SAP applications (see SAP Weaves Microsoft .NET And IBM WebSphere Into Its ESA Tapestry).

However, SAP is leading a large pack of vendors that are also all headed in the same direction. Namely, Oracle with its 9i Applications Server (9iAS) Enterprise Edition, PeopleSoft with its AppConnect, J.D. Edwards with its eXternal Process Integration (XPI)/eXternal Business Process (XBP), Baan with its OpenWorldX, IFS with its IFS Connect, and Siebel Systems with its Universal Applications Network (UAN) have all laid out pieces of their enterprise platform roadmaps. Even some Tier 2/Tier 3 vendors like Cincom Systems or Exact Software have been ringing the changes of their Business Process Management (BPM) platform roadmaps with new intelligent capabilities allowing the system to respond automatically to inputs or requests for information. The role-based BPM component acts as an information broker, dispatching requests and new inputs across the loosely coupled disparate applications and alleviating (or completely eliminating) the need for dreaded point-to-point integration programming.

However, the status of almost all above composite applications is that mere announcements have been made and we are now awaiting delivery. Building composite or cross-applications has not been an easy feat as shown by only a few of, e.g., SAP xApps developed so far. Most of them are still a figment of someone's imagination and will require much custom work until becoming tried-and-true and reusable. Each individual cross-application will involve sophisticated process modeling and process-level, data-level, and UI integration, and often it will involve creating and supporting a system of record that comprises data from multiple systems. Even after all that effort beforehand, the wide variety of technologies and formats of various independent software vendors' legacy solutions one can encounter in any new application for some cross-application, will inevitably mean some tweaking anew. The mitigating factor for some vendors, though, could be their narrow focus (not necessarily the case for SAP that targets 22 industries) and the longevity and a repetitive nature of their multiple partnerships.

What Winning Products Will Demonstrate

Winning enterprise products will demonstrate deep industry functionality and tight integration with best-of-breed bolt-on' products in a particular vertical. This also means adding sector-specific, fine-grained front-office or collaborative supply chain capabilities. Verticalization can be seen as part of a larger effort by enterprise application vendors to ease the implementation of their products. Software that combines industry-specific functionality with the flexibility to accommodate each company's unique processes goes a long way toward improving the functional fit and the speed of implementation. This pragmatic approach helps companies close the gap between system performance expectations and final results achieved

Another advantage lies in the fact that industry-specific, global enterprise solutions based on open architecture and proven technology standards facilitate faster integration of companies being acquired as part of a corporate growth strategy. Namely, while using implementation templates may provide a company with the jump start', these endeavors only support common processes that are likely emulated by the competition. For differentiation purposes, however, customers must give advantage to vendors that provide strong configuration & development tools and that have sound product interoperability strategies.

Thus, the above composite applications are a step further for customers that have long embraced the more open interfaces and improved integration capabilities that the enterprise applications vendors are providing, capabilities also intended for the product componentization (granulating) effort. During the past several years, enterprise applications vendors have opened up their tightly interwoven modules and created application programming interfaces (APIs) to connect to third-party best-of-breed systems. The vendors have lately been 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, had long created over 1,000 proprietary data access engines called Business Application Programming Interfaces (BAPIs) for use in integrating third-party products with the core ERP (enterprise resource planning) system as well as its proprietary enterprise applications integration (EAI) architecture called Applications Linking Enablement (ALE) via SAP IDocs (Intermediate Documents), 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 ERP extensions.

Instead of the costly, risky move to full componentization, most application 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 four-generation language (4GL) tool that can readily transform and route data as it moves between applications).

With NetWeaver, SAP had thereby made a major shift from providing points of integration' solutions through its BAPIs running over a proprietary remote procedure call (RPC) protocol called RFC (Remote Function Call). SAP Web Application Server (WAS) should provide a strategic integration platform for its customers, allowing SAP to more elegantly offer possibly a complete collaborative solution even when some of the component applications are not natively provided by SAP (that was possible via multiple BAPIs though, but in quite a cumbersome way). Furthermore, SAP Exchange Integration (EI) superseded ALE that was mainly suited for asynchronous transaction process needs, as a triggering mechanism to set again proprietary SAP IDocs in motion as a means of data flow between SAP modules and/or to third-party modules. Consequently, at first sight, NetWeaver addresses the major infrastructure requirements of an exchange platform, including internal integration within a single company and external between companies, business process workflow across applications, identity/role management, and content management. The power users' (rather than programmers' per se) ability to dynamically write business process rules and to share them internally and externally, might give other vendors pause and force them to come up with their equivalent solutions.

Analysis of Strategy One Evolve

Nonetheless, the likes of SAP xApps/NetWeaver will mainly address the above issue No. 4 -- "Business processes, not application boundaries", but the other three burning issues will not necessarily be addressed with these announcements. In other words, hardly any composite product above makes the underlying product architecture future-proof' allowing developers to both add business functions and change underlying technology platform as justified. The next generation of enterprise architecture must allow for business change to be adopted on an on-demand basis within the existing architecture as the business evolves, and it must provide the cost, time, and quality characteristics to make change a practical choice for the business. It would be quite utopian to expect that from product instances based on outdated and/or very proprietary technologies like COBOL, RPG or ABAP.

To that end, while the evolution strategy might be safer in the short run for both the customers and the vendor, minimizing both investment and disruption, the evolutionary strategy has limits in how much can be accomplished. The existing product becomes a limit on the amount of innovation that proves practical. While the large vendors have the advantage of large resources, they also have the mixed blessing of a large customer base. Will the customer base support the move, and will it transition to the newer architecture? Can the big vendors adequately articulate the benefits of their new enterprise architecture to make the move critical/justifiable to the user base?

These vendors also have the mixed blessing of an existing product. They have to enhance and support that product while spending on a new technology. Business judgment tells them to minimize risk by evolving from the existing product to a new one, but that has proven very difficult for most in the past.

This concludes Part One of a three-part trend note that will discuss three Strategies, as follows:

  • Part One: Strategy One Evolve
  • Part Two: Strategy Two A New Framework
  • Part Three: Strategy Three A New Approach

Part Three will also 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