What Approach Do You Take?
The temptation, when dealing with multiple disparate legacy systems, will be to rip out these existing systems and replace them with a single, standard, comprehensive state of the art application. This would effectively circumvent the problem by eliminating the need for expensive integration efforts. In the case where the need for integration is the result of acquisitions, this in fact may be the best route.
This
seemed to be the general direction many larger, multi-divisional, multi-company
enterprises were headed towards at the end of the last millennium. The feeling
was, "once we get past Y2K, we'll see about replacing all our old systems."
This included many companies who had made an investment in SAP
at a corporate level and were interested in recouping some of the spent cost
by leveraging that investment across multiple divisions and operating units
that previously had made autonomous decisions concerning the implementation
of systems. Oracle competed in this environment by advertising
"You will never become an e-business by piecing together software you already
have." The alternative, they implied, was to implement their extended ERP solution
throughout your enterprise.
So, yes, this is one approach to dealing with the growing challenge of integrating a proliferating set of disparate business applications. It also happens to be the one that tends to be the most expensive and the most disruptive to your business.
Many companies, like Myers Industries, once past Y2K, began serious investigation of this approach and got instead a serious dose of reality. Anyone who has experienced, first-hand, an ERP implementation knows that the software cost, even when it is coupled with the cost of external implementation consultants, is but a fraction of the true cost in terms of the blood, sweat, and tears expended during the course of the project. And that doesn't even include the cost of any necessary tailoring or outright customizations to the software.
This
is Part Four of four-part excerpt from the book ERP Optimization (Subtitle:
Using Your Existing System to Support Profitable E-Business Initiatives). It
is available through www.crcpress.com.
Parts
One and Two presented the reasons integration is an issue.
Part
Three covered what constitutes integration.
Part
Four discusses what approach you should take.
The Heritage System Approach
This dose of reality also caused them to look more critically and carefully at what may have been aging legacy systems. Hence the term "heritage" system was introduced. "Heritage" systems can be defined as a legacy system you are proud of. And if you are proud of that system then chances are it is doing the job that it was intended to do for you. Many companies realized that an enterprise-wide effort to rip out all existing legacy systems, in order to replace them with newer ones, would cost them hundreds of thousands, if not millions of dollars. Ignoring for the moment all the blood, sweat, and tears, the net result of this expenditure would have been simply to get back to exactly where they are today.
So let's assume you decide instead that the existing legacy systems will stay put. This decision of course makes the assumption that they are in fact meeting a quorum of your business needs, which is a critical factor in the equation. Let's assume for the moment that these systems meet a large portion of your basic business needs, but as you continue to transform your business into an e-business, as is inevitable for all organizations today, your needs will grow and change. So not only are you still faced with the requirement to integrate business applications, this need will escalate over time as you seek to supplement the functionality of your existing systems. Now what do you do? What alternative approach could you take to the mass replacement of your applications?
The most obvious answer might seem to be to write custom interfaces between your existing systems, and in fact, this was indeed the most common approach of the 1980's and 1990's. Unfortunately, this too is an expensive proposition, since this type of integration is not a one shot deal. All but the oldest homegrown legacy systems continue to grow and change over time, particularly commercially developed ERP systems. ERP vendors must continuously expand their solution footprint in order to remain viable, and changing business conditions continue to present new problems to solve and functionality to be provided. As your underlying systems grow and mature, the interface requirements are subject to these factors, causing you to either delay in implementing the newest features your maintenance dollars are buying you, or spend additional time and money to analyze, design, code, and test the interfaces.
Technology Enabling
The third, and least disruptive alternative is to consider "technology enabling" your existing applications and using this process to achieve integration. Sounds pretty good, but what does that really mean? In order to answer that question we have to go back to the different levels of integration—data, application logic, and presentation or visualization.
Using this alternative, how do you assure that the information is consistent between complementary applications? The ultimate goal should be to have a single copy of any particular piece of data. How achievable this goal is will be dependent on a variety of factors. Let's say you are a single company with an integrated ERP system installed, but you have recently implemented a new web-based order entry system in order to enable distributor and possibly customer self-service. Chances are this order entry solution came with its own customer master file. But of course you have a customer master file maintained within your ERP system. The first consideration should be to choose this new eCommerce application carefully. It was never meant to be a stand-alone application operating in a vacuum. How easily does it inter-operate with back-office applications?
For
example, Oracle's sell-side e-commerce application has been designed to inter-operate
seamlessly with its own Oracle ERP application. interBiz, formerly
the e-business applications division of Computer Associates
and today fully integrated into SSA Global, took a different
approach. interBiz Store, its web-enabled e-commerce application,
defined the data elements it needed in a common object model. interBiz
then used "wrapper technology" to expose those data elements from their multiple
ERP applications to that object model. By referencing the data through the common
object model, they are not replicating data, but simply redirecting interBiz
Store to access it directly from the back-office application, eliminating the
need for redundant data and synchronization. They used interBiz Store as a means
to technology enable their back office ERP applications and in doing so they
reduced the need for specific interfaces. Companies with applications other
than SSA ERP systems would simply need to develop their own wrappers in order
to expose this same data to interBiz Store.
interBiz Store, and other e-commerce applications like it, can also be viewed as a presentation or visualization layer to existing legacy systems. Once installed and implemented, the underlying applications can be re-engineered or replaced more transparently to the users.
A similar approach can be used in integrating disparate business applications, all of which may be legacy systems that may have proliferated at any particular company. An apparent solution to providing a single copy of any piece of data would be to have all data physically reside in a common repository, but this can have significant impact on any or all of the disparate applications. Data must be migrated, duplications resolved, and applications must be modified to redirect access and recognize new formats and structures. By using the approach of a common object model and wrapper tools, this effort does not disappear. However it is not only significantly reduced, it paves the way for future changes by not locking any business function into any specific application, and by not locking any application into any specific data format or structure.
Dealing with Embedded Logic
This may seem fairly straightforward when it comes to the data and presentation levels of integration, but how can you "technology enable" applications to address integration issues where application logic is required? The answer is actually simpler than you might imagine. You remove the logic from the application. This is a very important concept in the context of the layer labeled as interaction services.
Traditionally business applications have embedded business rules and decision making within the logic of the application. By removing these rules from the applications themselves and managing them in a separate rules engine, this paves the way for greater flexibility and creates a more agile environment. When the rules change, the policy criteria, such as thresholds and limits can be changed without having to touch the application itself. Clearly it is much more difficult to retrofit this type of functionality into existing applications, as it means gutting the application itself. It means replacing internal program code with external calls that allow for a much more flexible range of results.
However, most businesses today have not implemented their last application. Particularly with the demands for outward facing applications required to inter-operate within and throughout the full supply chain, there is plenty of opportunity for companies to take advantage of this type of technology. And, let's not forget what brought us to this discussion in the first place—integration. In defining how two or more applications inter-operate, there is a great deal of potential for utilizing a combination of technologies which are essentially external to the applications. And they may only need to be directly connected to the applications at select, critical points, or perhaps not at all.
Workflow engines have provided excellent vehicles to begin to address this goal of removing logic from the application. The entry of a new customer can alert the credit manager to initiate the credit approval process, thereby expediting the processing of a quotation and the generation of a booked order. The receipt of the order can automatically release purchase and production orders. The receipt of a service call can notify the assigned engineer. The transmittal of a loan application can alert a loan officer. The consumption of stock can initiate a replenishment order. An account balance running over budget can alert the responsible department manager.
As you can see, on the surface, some of these examples may have nothing to do with integration. If you manage customer credit using the order management and the accounts receivable modules of your ERP system, these should already be integrated. If your ERP system is supported by workflow technology, then the process of taking an order, and other activities, should trigger the credit check. What happens, though, when, as in the data level example above, you determine it is time to launch a B2B e-commerce initiative and you decide to implement a sell-side eCommerce application to accept orders over the Internet? Now you not only need to feed orders from your web-based order entry application to your back-office order management system, you also need to trigger that credit check which combines data from all three modules. How can you trigger that check to occur without writing a specific interface between the two applications?
The answer to this question lies in the ability to perform some level of "event management." While potentially a very sophisticated and powerful technology, I will present it in conceptually correct, yet grossly simplified terms. The first aspect of event management that is required in this example is that of "event listening". In this case, an event listener, which is not necessarily a function of either the new web-based order entry application or your back-office ERP system, simply waits for an event to occur. In this case the event is the creation of a new order. Once this event is detected, another event must be triggered. This other event may be as simple as the creation of a task in a credit manager's "to-do" list, in which case its job is done. The order will be taken, but essentially held until credit is approved at some later time. In other cases, the event that is triggered is to automatically initiate an on-line credit card approval process performed by a third party software provider such as Paylinx or CyberSource, credit card service providers who actually obtain credit card authorization from the bank or other source of credit.
As you can see, by using workflow technology to combine technology that applies business rules and business policies together with an underlying transaction based application you can start to orchestrate business processes that may span multiple applications.
Let's consider another example. You are a manufacturer, who has grown by acquisition, with three different manufacturing facilities. The three facilities for the most part produce different product lines, but there are some common products between the three. There is some overlap between the customer bases of these three, because each of the plants addresses somewhat overlapping product lines. There are three different ERP implementations with three different customer master files. In order to reduce cost and streamline operations, you have consolidated the sales force and you are implementing a single web-based order entry system. You enter a new order from that system, referencing the customer using the customer number one of the back-office systems knows that customer by. Using a common object model that has been defined and a wrapper that exposes data in the ERP system, you check product availability and find that you do not have inventory enough in stock to ship.
Behind the scenes, rules are defined that do some mapping and translating of customer numbers across the three different ERP systems. In this way you determine if in fact this is a customer known to either of the other two systems and it uses workflow to initiate a check on inventory availability in both locations. It finds it has sufficient inventory in either of the locations, but that customer only exists in one of them. So pre-defined business rules determine the selection of the warehouse from which to ship. The order is accepted. Workflow technology then is used to create an order in the back office sales order entry module of that ERP system and the transactional flows associated with that system take over.
By complementing existing business applications with advanced technology such as rules engines and workflow, you again make it easier to reengineer or replace the underlying applications selectively as necessary in order to continue to meet the challenges of the ever-changing business world.
Summary
Integration of information assets becomes a crucial and central issue in the ongoing challenge to remain competitive today. Virtually no company runs a single business application, and as enterprises grow through mergers and acquisition, the complexity of the situation expands. Add in the necessity of inter-operating across the virtual enterprise of the supply chain and this complexity grows exponentially.
In this article we have found that there are several different levels of integration that must be considered, the most fundamental of which is at the data level. You will be required to provide shared access of data across multiple applications or a unified view of data necessary for strategic and operational decision making. Secondly there is the integration that goes beyond the data level and must involve application logic, and finally there are issues associated with providing a consistent and meaningful presentation of the applications and the information contained therein.
But the most crucial element of integration lies in the approach you take to achieve it. While the alternative that was most widely discussed in the late 1990's was replacement of multiple disparate business applications with a single, integrated system constructed with the latest technology, the 21st century brought an awakening to the sheer foolishness of this approach. Not only is this approach too disruptive to your business and too expensive, but it is simply not necessary. Obviously designing and developing custom interfaces to existing systems is an alternative many have considered and even undertaken, but the ongoing effort and costs of maintaining these interfaces can be prohibitive as you implement new features, functionality, and even additional business applications.
By far the most forward thinking approach is to "technology enable" existing systems, externalizing components by supplementing application logic with externally defined business rules, workflow technologies and event management. By applying advanced technology to your existing solutions, you avoid building obstacles to reengineering your business in the future as the world continues to change.
About
the Author
Cindy
Jutras has over twenty-nine years of experience in applying software
solutions to business problems. Experienced in a wide range of functions related
to the software industry, including sales, marketing, product development, customer
support and product management, she is also an industry observer and trend-setter
in business and business applications. Having worked with manufacturing companies
for the full extent of that time, she is both a visionary and a pragmatist.
She
is currently the Director of Solutions Management for SSA Global, since their
acquisition of interBiz, previously a division of Computer Associates. At Computer
Associates she was the divisional Vice President of Product Strategy and was
instrumental in defining and guiding the product direction of ERP systems as
well as advanced technology products.
Ms.
Jutras' work has been published and she is frequently quoted in industry
publications on a variety of topics including manufacturing, ERP, e-commerce
and e-business management, and CRM. She is the original author of the concept
of "Virtually Vertical Manufacturing" and speaks at industry events on this
and other topics.