The term "business management system" (BMS) is fast becoming the latest term for automated software systems that integrate into a comprehensive financial and business planning solution for medium-sized businesses. The term has been bandied about for a number of years by academics but is now just beginning—because of the integration capabilities of newer technologies and programming languages—to gain acceptance within the larger business community.

What Is BMS?

BMS is what the System i has always been about: managing the business through information technology. It can include any number of software suites and IT initiatives, including customer relationship management (CRM), enterprise resource planning (ERP), payroll, financial accounting, supply chain, employee benefits systems, etc. The primary BMS motivator within an organization that has embraced BMS is the desire to bring the automation tools for managing the business into an environment that enables better control of the business itself. But that's only the first level of the definition. BMS must go deeper, within and without the organization, to reach management's goals.

Software Technology Integration Is Key

Almost without saying, the key to the success of any BMS suite is its ability to integrate various technology pieces into a cohesive solution suite. But what does real integration look like?

The last thirty years of business software evolution has been a story of integrating individual business software elements into larger, more comprehensive solutions.

A primary example of this can be found in the area of production management in the manufacturing sector:

• Software for inventory control was combined with production control software to create material resource planning (MRP) suites.
• MRP was further consolidated with specific accounting suites to become the second generation of MRP, called MRPII.
• Further consolidation of software suites with financial accounting (accounts receivable, accounts payable, and general ledger) rolled together with MRPII suites to create enterprise resource planning (ERP).

In each consolidation, the goal was to create forward-planning tools based upon a real picture of what was currently occurring within the organization.

Likewise, supply chain management (SCM) extended these abilities for production and distribution planning between organizations. In a global sense, supply chain organizations relate to one another by their business planning relationships. So as they increasingly share production and inventory information, they increase the overall efficiency of the supply chain.

However, usually in small and medium business (SMB) environments, it's the larger member of the supply chain that sets up the technical requirements for the smaller business entities.

For instance, a mega-organization like Wal-Mart dictates the SCM software requirements to its suppliers, regardless of the actual internal business management systems that the smaller organization uses to manufacture the product. Wal-Mart doesn't care what it takes to produce the actual product, as long as the supplier provides the information Wal-Mart needs to plan and execute its business processes.

BMS: The Heart of the SMB

For this reason, BMS software is often seen as the internal glue that generates the local, internal, or in-house business processes of medium-sized organizations. This information later becomes the information base sent to the larger global suppliers and customers.

In other words, BMS suites are the tools by which medium-sized organizations conduct their internal business processes to create and manage products. Parts of that information created by these BMS suites are then sent outward to meet the demands of the global business partners. BMS tools often include ERP, CRM, financial accounting, and very specific internal software tools that help the organization create its products and services.

So, BMS is a set of solutions—often composed of integrated packages—that controls the internal business environment of an organization. However, the greatest challenge—and the greatest potential pitfall—is often how the particular BMS suite integrates to the larger global software world of SCM.

Evolution vs. Convolution: The IT Pitfall

Technologies are changing rapidly, and business requirements—both internal and global—make implementing BMS an exceedingly difficult chore for IT: No sooner has the integration between two software elements been completed than four more need to be modified to keep their functionality current.

Moreover, very often the requirement to integrate an element is initiated by the external supply chain or a key business partner. As in the Wal-Mart example, external customers often need to see production status, inventory, etc., and they require this information to be made available on demand.

This external dynamic invariably places the IT department into a reactive mode, trying to satisfy the external requirements of a business partner. But of more significant consequence is how such an external dynamic eliminates IT's ability to prioritize the implementation software projects in-house.

For instance, IT often must dedicate a programmer to perform some painstaking task of maintenance on a legacy BMS software module in order to respond to a business partner's initiative. This task must be performed to protect the business partner relationship, even though—in the larger scheme of things—the most logical thing to do would be to replace the BMS software module entirely. Yet, because of time constraints, maintaining the legacy BMS code may be the right business decision for the company to undertake. Consequently, the integration requirements for the BMS module—requirements that are originating outside the organization—create a corrosive dynamic that makes it more and more difficult for IT to move the whole organization forward.

Unless the BMS software module is exceedingly resilient and robust, each maintenance chore twists and torques the module, making it increasingly difficult to maintain in the future. Finally, as the modules reach their ultimate convolution, IT ends up with a piece of legacy code that is so distorted—often written in obsolete languages, using arcane APIs—that IT finds itself in a crisis: No one understands the business rules, no one remembers the API, no one knows the legacy language, and no one can find a consultant who will can help the organization modernize.

Multiply this dynamic by the number of interfaces that a BMS solution might have to other systems and processes—to both internal company applications and external business partner applications—and it becomes easy to see the resulting resource challenges:

• Each BMS integration success will ultimately become an IT maintenance issue.
• Each new maintenance issue will ultimately become an IT liability.
• Each IT liability reduces the module's return on investment (ROI) and the value of the BMS software itself.

Techniques for BMS Integration

Of course, IT has historically used a number of techniques to optimize the ROI of BMS solutions, and it's interesting that most of these techniques mirror the evolution of the technology that IT has implemented. These techniques involve architecture, protocols, languages, and standards.

The Integrated BMS Platform

For instance, the hallmark of the System i (and its predecessor platforms) has always been its ability to integrate BMS solutions onto a single platform, using a single database technology (DB2), accessible by a robust high-level programming language (RPG).

Today, the System i is still the measure by which medium-sized businesses gauge the ROI success of their BMS software. Moreover, IBM has maintained the resiliency of the architecture of the System i and its operating system primarily by enabling new versions of the platform to continue to run older applications. IBM has also rigorously extended the platform's technology since the initial AS/400 days so that it can easily integrate with other operating system platforms and communications technologies.

But the days when a company could rely upon a single, integrated computing platform to meet its BMS requirements are long gone: Windows, Linux, mainframe, and a host of sundry workstation-based applications have long since wooed management away from the nirvana of a single platform solution. Today, it's unusual to find a medium-sized organization that runs its business entirely on a System i, and as a consequence, the pitfalls of BMS integration become a significant part of IT tasks.

Operating System APIs and Protocols

A second method for integrating BMS systems occurs between modules that exist on separate platforms, using APIs and communications protocols. For instance, several modules may exist on a Windows server, while another might exist on a UNIX server, all integrated via APIs and communications protocols to a central System i database. Communications protocols enable the different operating systems to interact, while the APIs enable the applications to exchange specific information between modules.

Unfortunately, as each platform architecture evolves, the underlying interfaces must be revisited. Moreover, if the support for any API changes or the integration requirements evolve, IT must get down and dirty to re-engineer how the applications communicate between themselves.

Until recently, this was the IT nightmare that eroded the department's credibility with management. Things take too long to integrate and, once integrated, take too long to maintain. From management's perspective, things work fine for a while and then suddenly break for no apparent reason. Finding the IT resources to support the BMS integration ultimately becomes a technical problem that has nothing to do with the business itself, further isolating IT from management.

Standards-Based Languages, Interfaces, and Protocols

The current "holy grail" for IT has been arriving with the evolution of standards-based languages, interfaces, and protocols. But these kinds of initiatives are not new. Ancient languages such as COBOL, modern languages such as Java, broad industry-based interfaces such as EDI, and modern interface services like RPC, Web services, and quasi-languages like XML are all of the same ilk: They promise an easier means of integrating software modules into a cohesive suite of solutions.

However, while these technologies may solve individual BMS integration problems, the technological trends that drive them tend to evolve faster than the skill levels within IT.

Older programmers will remember the promises that IBM and others made about the efficiency of object-oriented programming (OOP) languages like Smalltalk and Java. Today, these same programmers will be the first to tell you that things have become more complex, instead of less complex.

In the meantime, the discipline of OOP has moved these same programmers further away from the business rules they are trying to integrate in their BMS solutions. Instead of automating the company's business rules, they find they are submerged in technical standards-based programming details.

Moreover, an increasing number of rapidly evolving technology standards enter the world of IT every day. This makes the choice of any particular standard increasingly difficult for IT. Which language should IT use? Which protocol offers the most power to the organization? What standard will be tomorrow's standard? These are hotly debated topics within IT, but they have nothing to do with business rules or the management requirements of a BMS solution.

Add to this the fact that often these languages, standards, and protocols are ultimately chosen by business partners within the supply chain—rather than by IT itself—and the stage is set for confusion and inefficiency.

BMS Integration Brokers

The solution to this BMS integration nightmare may be found in a new class of software called integration brokers. An integration broker is a centralized software suite that acts as a hub to orchestrate the interfaces of all the software used by the BMS solution.

Instead of writing to individual APIs between applications, the integration broker is the central repository for all underlying processes that communicate at the application layer.

For instance, an application that needs to create EDI transactions can use an integration broker to coordinate communications to the business partner who accepts a particular flavor of EDI, while the same application interface to the integration broker can redirect transactions to a different business partner who uses Web services.

Meanwhile, the integration broker centralizes and standardizes all internal BMS module interfaces. It's architected to robustly communicate between external and internal processes. Instead of requiring IT to learn a thousand different interfaces, IT needs only to know the integration broker's interface.

Real-World Integration Using Integration Brokers

Recently, MC Press Online hosted a Webcast entitled "Business as Usual: Is it Stopping Supply Chain Success?" In the Webcast, MC Press interviewed Jim F. O'Leary of Extol International. We asked O'Leary how the traditional modes of IT integration within a BMS solution can be overhauled to increase efficiency within a supply chain structure.

O'Leary provided three examples from three companies in different supply chains that are currently using integration broker technology to achieve increased IT productivity. What's most instructive about this Webcast is the description of the software architecture that enables almost any BMS suite to extend beyond the organization, out into the larger global supply chain architecture.

Moreover, O'Leary provided interesting hints on how an organization that's backlogged with maintenance problems can begin the transition to a more structured, controlled, and productive IT environment.

If you're interested in this topic, I recommend that you visit this free Webcast for an excellent view into what IT can accomplish with BMS integration and how these integration processes can be improved.

BMS at the Threshold of Business Productivity

For too long, business management systems have been the stepchildren of the IT technology revolution. Excellent applications have been created and then abandoned or ignored by companies as IT has sought the holy grail of a fully integrated business management system. Technologies have come and gone; standards have been embraced and deserted. Yet management steps up to the plate to invest again and again because implementing a robust BMS solution is so vital to the profitability of the organization.

Yet the pitfalls of BMS will be found not in this vision from IT or its management but in the overall complexity that comes from integrating the various BMS solution modules. To overcome these pitfalls, IT has to look beyond the traditional modes of software integration and examine the overall architecture that composes its suite of solutions. Once this architecture is examined, new opportunities—using new architectural concepts like integration brokers—will enable IT to finally move beyond the BMS integration nightmare.

Thomas M. Stockwell is Editor in Chief of MC Press Online, LP.