Linux in an ERP World

by Uche Ogbuji

Enterprise Resource Planning (ERP) is the latest hot computer topic for businesses. In the boardroom, it is often an even hotter topic than the Internet. ERP describes a class of computer systems that attempts to manage all aspects of an enterprise's operations. The basic structure of a typical ERP system is shown in Figure 1. Note that this diagram is highly generalized; actual ERP implementations differ wildly from vendor to vendor, and even from installation to installation. As you can see from the diagram, ERP systems cover an enormous scope, so they are very large software systems. They also tend to be relatively monolithic, which is their main selling point. This is also the feature that worries IS workers the most, and the feature that might make a Linux user scratch her head.

Figure 1. Typical ERP System

Frankly, ERP systems are typically sold with a pair of rose-colored glasses as an accessory. A gentleman I spoke to, who works at an enormous international beverage company, told me how the firm was sold an ERP system. The salesmen for a leading ERP vendor took the CEO to a demo room, with projection monitors showing simulated real-time charts of all of the company's operations and finances. The salesmen told the executives that with this product, they could have their fingertips on all of their company's data. The sale was closed at that point. Now, years later and a scandalous sum over budget, the company has little choice but to complete the installation. The IS staff is completely disillusioned, but apparently not the executives, who are still waiting for the magic cockpit to go on-line. This story is all too typical. ERP systems are sold mostly at the executive level, and skeptical IS staff have little to say other than the narrowest, technical implementation details. Furthermore, the process of putting together an ERP system is such an enormous undertaking and commitment that once the project is begun, there is no backing out without disastrous financial and operational results.

Where does Linux fit into this rather alien world? Many Linux professionals will find themselves caught up in an ERP installation at some point in their career, since ERP systems are selling very well these days. But Linux makes the hapless IS professional think of a more fundamental issue: what brought about the whole ERP trend?

If you look at the history of computer software systems, you will notice that the industry has not treated business very well. Competition among traditional software vendors often involves wars to promote one data format or process over another, with the reasoning that the success of proprietary data formats accelerates the market share of proprietary applications. Many departments bought computer systems to serve their particular operational needs. The accounting department got machines and software that run the most effective accounting software. The technical support department got systems that manage incoming calls and problem resolution. The marketing department often got Macintoshes for the graphics and layout software.

These individual packages served each department well enough, but it's a small leap of business sense to deduce that the real gains in productivity would come if the various departments could exchange data. Suppose quality assurance could recognize a defect trend from the technical-support data and tighten testing, or that the accounting department could verify purchase orders for raw materials directly from manufacturing resource-planning systems which would determine how much of a product to manufacture from marketing's sales projections. However, when CEOs tried to implement such interactions, they quickly ran into barriers of differing data formats, conflicting business rules and physically disconnected systems. When they went to the vendors of departmental systems for help, they typically didn't get far. Not only would it be prohibitively expensive for each vendor to integrate with every other system out there, but vendors imagined a competitive advantage to not doing so.

The furor over software standards is a recent phenomenon. Historically, software standards have been very slow to emerge, motivated more by temporary alliances for market share than by any real desire for interoperability. The typical solution for interoperability was to buy entirely from one vendor. Manufacturing companies have very specialized needs for data exchange, so about a decade ago, a few smart companies started offering manufacturers a suite of software that handled all aspects of their operations with the assurance that information would be compatible between departments. This was the birth of ERP. Since then, pioneers such as SAP and Baan have grown prodigiously. From roots in manufacturing, they now sell to almost every major industry. Other companies, sensing profit, have joined the ranks of ERP vendors: PeopleSoft from the human resource world, Oracle from the RDBMS world and JD Edwards from the financial systems and business services world.

Now, most Linux users might see all of this as a huge over-correction: organizations can't get departmental computers to collaborate, so they scrap them all in favor of supersystems from single vendors that claim to do all of the organization's data processing. Linux users are accustomed to standards and a culture of software collaboration, but these trends are only now slowly beginning to permeate the rest of the software industry.

The entire ERP trend does pose some tough questions for Linux advocates. First of all, Linux's infiltration into enterprise has often come at the departmental level, usually on departmental web servers. As more companies adopt ERP systems and insist that internal and public web content feed into the same enormous data stream, Linux may be harder to push in the workplace. Also, for Linux to move from the web server to the application server environment, it will often need to go head-to-head with an ERP module—a battle for which Linux is politically ill-equipped.

Linux is just an operating system, and being UNIX-compatible should theoretically not be far from running ERP systems, which usually have commercial UNIX ports. Many hints and whispers have been reported on Slashdot.org and elsewhere that various ERP vendors have development versions of their server modules running on Linux. This is to be expected and follows from the interest of so many DBMS vendors in Linux, but again, it doesn't address an issue that is of as much importance to the Linux community as the running platform. The culture of Linux, promoting distributed systems, narrow scope for applications and standards-driven collaboration between applications is under stealthy attack by the ERP approach. This is a very important issue for Linux and open-systems advocates to address, because ERP vendors are almost as wealthy and resourceful as Microsoft and just as anxious to press their proprietary systems. It is in the interest of ERP vendors to continue making it attractive for customers to buy all of their major information systems from them. On the other hand, Linux users typically insist on buying or downloading various software packages for various purposes and expecting them to work well together. This conflict is most apparent in small-to-medium businesses, which are the latest target of ERP vendors, but probably the most likely to gain from the open and distributed systems approach. This so-called “mid-market” is comprised of companies with $250 million to $500 million (US) in annual revenues.

ERP vendors are pushing the myth that an enterprise needs a massive system running on a tight cluster of machines for effective computing. The Internet is but one recent development that proves distributed computing can be just as productive as highly centralized computing. Departmental systems are increasingly feasible in the age of Intranets, driven by such interoperability standards as XML, CORBA and LDAP. Databases are now almost all reliably SQL, a more recent phenomenon than one might imagine, and many domain areas are developing forms and process standards for Electronic Data Interchange (EDI) and other initiatives.

Make no mistake about it; Linux does have some definite short-comings for enterprise computing. Some are only in perception, such as the 2GB file-size limit. This, of course, applies only to 32-bit systems, such as Intel x86 platforms. Major database vendors already know how to work around this limitation, but Linux on Intel gets most of the press and many people in a decision making capacity read pundit columns that complain of the supposed limitation. Even if one sets miseducation aside, there also need to be more fundamental processes, standards and drivers at the system and server-device level for mirroring, redundancy and fail-over because an enterprise system must be bullet proof, even by Linux's high standards. Intel's recent attention to Linux provides a much-needed boost towards addressing such high-availability issues.

DBMS vendors are also an important part of this process. Enterprise computing, whether using single-source ERP or distributed information systems, is all about data management. DBMS vendors can take leadership in tweaking Linux into an “enterprise-class” operating system. Their researchers can provide kernel patches, and they have the means and need to test enormous transaction loads. As a true open-source advocate, I take a moment to mention PostgreSQL, which is an open-source database. It still doesn't support some features typical in enterprise-class systems, but its feature set is tremendously robust, and a good argument against detractors who like to consider open-source efforts as good only for hobbyists.

It is not the specific applications that Linux is lacking. We don't need a group to get together and write an open-source resource planning application. What Linux needs is the basic underpinnings: the infrastructure for such applications. Its current momentum will surely envelop many vendors of vertical applications, and such applications better served by the open-source model will naturally tend in that direction. For instance, Linux needs attention from developers of middleware and transaction-processing systems. These systems have been standardized enough that they could reasonably support open-source projects, and they are an integral part of the ERP equation. Another area of importance is business rules.

One reason ERP installations are so precarious is they usually involve business-process reengineering. ERP systems are complex enough as they are. If they had to encompass all the company rules, policies and customs of every business out there, their complexity would be practically infinite. Instead, each ERP vendor has picked its own set of “best practices”, business rules which it believes to be most effective and has enshrined these in its systems. If a company wants to adopt an ERP system, it must reform its own business processes to those of the ERP system. This usually involves a major effort in paper shuffling, training and testing. Many CEOs, who feel their companies have chaotic or non-existent business logic, seek to implement ERP just for the reengineering process. In fact, this is often painful and resource-intensive.

Figure 2. Linux ERP System

If a company has good operational practices, it does not need to go through the pain of remodeling itself in some other's image. Very often, a company's unique approach to business is part of its competitive edge. This is a strong argument for decentralized computing. If Linux is to use this argument, it will have to provide a powerful system for managing business rules and incorporating them into enterprise systems, as described in Figure 2. Note that once broken down to the departmental level, Linux has the capability and competitiveness to host all of the functions displayed. What is needed is the applications to fill in the blanks. The enterprise-class databases are coming, but the data-exchange management and executive information systems are a tougher proposition. For vendors to prepare such systems for Linux, a solid framework for business rules would probably have to be in place. This may sound easy enough to implement, but in its purest form, it is one of the holy grails of computer science. Research efforts ranging from graph theory to artificial intelligence have sought good ways to enshrine arbitrary business rules (or even just common-sense rules) into a computing framework. A system that could handle enterprise-class computing would need the ability to analyze business objects and apply various operations and constraints on them, as well as check pre-conditions, post-conditions and invariants. This is an area where the great problem-solving ability displayed by distributed developers such as Linux's can make strides.

There is no doubt, however, that those of us in the Linux community face tremendous financial interests in an entrenched industry if we decide to compete. ERP is a very profitable business, in contrast to the plummeting margins in shrink-wrap software. ERP systems are pushed by the companies that write the software, consulting companies (including the consulting arms of the big six accounting firms) and hardware/systems interests such as Hewlett-Packard and IBM (see “An Unlikely Ally”). These same companies provide reengineering and customization services. The frenzied marketplace ensures that consultants can often command $200 to $300 US per hour. The total cost for ERP installations ranges from $100,000 for the smallest organizations with the least reengineering effort required (often called “accelerated” implementation) to as high as $500 million for large multinational firms. Note that I mention customization with regard to the implementation effort. ERP installations often demand as much effort in customization as is required to write the information systems from scratch using off-the shelf DBMS, middleware and design tools. ERP vendors encourage customers to customize as little as possible, so as not to break everything when the APIs change, but the reality is that every business has its quirks which necessitate customization.

Much of the recent effort in the Linux world has gone toward making Linux a feasible desktop replacement. To observers of modern enterprise-wide computing, this seems almost like misplaced energy. Intranets and other such developments are slowly turning front ends into commodities, and the real power is shifting from the client back to the server, although the server does not have to be as monolithic as a mainframe. It is important for Linux developers to turn their attention to the infrastructure which is increasingly being demanded by enterprise-class computing and the executives who demand it.

Many will argue it is not important for Linux to prove itself in this market, but if you believe in the superiority of collaborative computing, you should recognize that this ideal has the potential to be snuffed out by sheer misguided politics and economics. If we want that server in the corner of the data center to ever run anything besides Apache and Samba, we might want to channel some of the boundless Linux energy to the enterprise.

Linux users face an interesting dilemma. A sector of the market that has traditionally neither interested nor challenged us is beginning to shape trends that could affect the future of computing, as much from a cultural as from a technological view. To ensure the encouraging growth of Linux and the associated improvements in business attitudes toward information technology, developers would best address some of the needs of enterprise computing. Commercial developers will certainly fill in the gaps. Then perhaps the promise offered by the client/server movement, more flexible and decentralized computing, will stand in a little less danger from huge, single-source ERP systems.

An Unlikely Ally

Linux in an ERP World
Uche Ogbuji is co-founder of FourThought LLC (http://www.fourthought.com/), a consulting firm specializing in custom software development for enterprise applications, particularly Web-based integration platforms for small or medium-sized businesses. He can be reached via e-mail at uche@fourthought.com.
Load Disqus comments