side-stepping the labyrinth - part ii -...

Copyright © 2005 by Klee Associates, Inc.

www.SAPtips.com

Side-Stepping the Labyrinth - Part II: Choosing the Best EAI Scenario Solution

for SAP® NetWeaver™

By Axel Angeli and Lynton Grice Editor’s Note: Our readers who attended Axel Angeli’s presentation at the SearchSAP.com conference in Chicago recently may have gotten a sneak peak at this white paper already. For readers seeing this 48-page white paper for the first time, you will find it thoughtful, provocative, and comprehensive. As with Part I of this discussion, this paper is co-authored by Axel Angeli (in Germany) and Lynton Grice (in South Africa). Their virtual international collaboration is made possible by numerous integrated entities from their local PCs to cables, routers, servers, and satellites, resting finally on our server in beautiful Colorado, awaiting your download. In this extensive paper, Axel and Lynton finalize their discussion of EAI options for SAP NetWeaver. They evaluate and discuss the pros and cons of the larger “high-end” products as well as many of the smaller, more obscure packages on today’s market, and step forward with their personal recommendation. We won’t give the winner away here, you’ll want to read the paper for yourself and understand how they reached their decision. Be sure to download and print the paper, as you’ll surely want to use it for later reference or for making a case with management as you implement your EAI initiatives.

"It's easy to decide what you're going to do. The hard thing is deciding what you're not going to do." - Michael Dell

To be, or not to be, that is the question: Whether ‘tis nobler in the mind, to suffer The slings and arrows of outrageous fortune Or to take arms against a sea of troubles And by opposing end them. Hamlet, William Shakespeare

Making the transition to a service-oriented architecture (SOA) will be a decision that will transform the way that your company does business. It will be a transition for the better, of course, but also a decision whose impact will be felt for a decade, if not even for the century. Therefore, deciding for or against a special product or vendor won’t just be like buying a piece of software, it will be a decision of no return! Many aspects need to be considered; not only technical ones, but also questions of strategy, trust, persistence, and general politics. We wrote this article series in order to bring these themes together. Sometimes, SOA may feel like a deal with the devil, promising the world and delivering uncertain value. To do SOA right, you’ll have to set aside the easy approach of “in one vendor we trust” and gather the know-how to forge your own path. As we will show, SAP is certainly worthy of being the primary vendor in an SOA, but your SOA destiny is always in your own hands.

1 Introduction Part I in this series examined where application integration is today, and how Web services (and their accompanying standards and technologies) are molding the way in which complex integration scenarios will be formulated in the future. Following on from this, Part II will now revisit the focal point on how one should go about selecting the best EAI scenario solution for SAP NetWeaver. Practical questions and critical aspects to consider when evaluating an EAI solution will be highlighted, and this will provide readers with enough knowledge to be able to confidently separate the empty claims from a true EAI solution that will take them confidently into the future.

Comparing the “Big Players” for their sense of EAI selection, and EAI solution, is far from easy. First you need to sift through an enormous array of possible integration options. Secondly, you


www.SAPtips.com



need to hear conflicting arguments from different vendors as to why their solution is better than the next. You need an EAI product that will grow with your organization; one that allows you to compete confidently as well as be able to effectively run your operations, both now and into the future. Typically most vendors say their solution caters for “everything”…just whom do you believe? We will find that the new Enterprise Service Architecture (ESA) gives us the freedom to choose a good cocktail mixture from the different vendors. Only the decision for the development framework, the high performance message queue, and business integrator, are of strategic importance and will be irreversible once put in place.

2 Sizing Up the Gauntlet The world of “integration” is an absolute mammoth area involving a complex blend of IT, process, and business management. Simply purchasing an EAI product, plugging it in, and hoping for the best is not the general idea here. The EAI product is just one small piece in the larger “integration puzzle”. What is required, however, is a careful understanding of how and where the different “puzzle pieces” fit together within an enterprise-wide environment. Getting the right “mix and match” between these “puzzle pieces” is the key to fulfilling a successful, long-term integration strategy.

An optimized business is a managed business. To be able to successfully manage a business, you need (among other things) a well-understood (yet flexible) set of business processes forming the “backbone” of the enterprise. This is where the “Business Process Management” (BPM) comes into play.

2.1 Business Process Management Business process management is an iterative process. The value and return on investment (ROI) that a company enjoys is directly related to the quality and setup of its business processes. Companies that want to survive in our ever-increasing competitive environment need transparent business models that provide the agility and flexibility to be adapted at any time. A company that has the ability to deliver its products and services to its customers faster than its competitors will stand out amongst the rest – period!

The main problem in companies right now is that no one person is responsible for business process management (BPM) as a whole. This results in a company having “business process silos” with different divisions and departments being responsible for their own respective processes. But who is in charge of organizing and understanding the company-wide value chain? Ideally this should be the Chief Information Officer (CIO) whose aim should be to also become the Chief Process Officer (CPO) of a company. The key task of management should be to optimize the interrelationships and interactions between processes, people, and resources to achieve the organization’s goals and objectives.

For a company to implement intelligent business strategies, it must not only have flexibility in its business process management, but it must also have the ability to rapidly transfer innovative management concepts to the IT systems in the organization. Added to this, management needs to get a clear, real-time view of what’s happening in the organization at any single point in time (Business Activity Monitoring). This is, more often than not, a very difficult task, as business and IT do not view processes in the same way, nor do they share the same language or tools. The IT department has a very technical view of the data, systems, and interfaces in the landscape, and it is often difficult to communicate these concepts to senior management. Implementing company-wide BPM initiatives often becomes a very costly and time-consuming experience that typically falls far short of initial expectations.

Figure 1 is a “high-level” look at how the different integration “puzzle pieces” fit together, and shows some crucial aspects that need to be considered before embarking on purchasing an integration solution.


www.SAPtips.com



Figure 1: Business Optimization Requires the Assistance of Many Sections in a Company

An optimized process is a managed process. In the perfect world, the entire life cycle of process modeling, configuration, implementation, execution, monitoring, and optimization needs to be merged together into ONE solution. This, however, is not reality…. BPM has many layers associated with it and often deals all the way from innovative, strategic business models (captured by senior management) right down to the technical process modeling/orchestration in a product like SAP XI. Often different tools are used to model such processes, leaving management wondering how these tools and processes are going to work together in order to get a seamless view of the entire value chain in an organization. This is by no means an easy task.


www.SAPtips.com



This article focuses on finding an EAI solution that fits well in the SAP NetWeaver environment, while still directly aligning itself with the “corporate process strategy”. Taking this into account, we may want to look at things from a slightly different angle, as illustrated in Figure 2.

Figure 2: Corporate Business Strategies and EAI Solutions Are Closely Related

The majority of big companies out there are somewhat behind in their BPM strategies but have nevertheless at least started modeling their “high level” BPM strategy using some visual design tool like ARIS by IDS-Scheer1. ARIS provides the right process methodology and tools to get a company kick-started on its way to true BPM (albeit typically “high level”). But once again, how does a product like ARIS integrate with an EAI solution, to get one view of the entire process – from “high level” to “transaction level”?

The business process architecture of a company encompasses its business processes from a pure business management level, to the configuration level, right down to the integrated description of the executable processes. The high-level design phase in business process management typically answers the following questions:

• “WHY do we do”

• “WHAT, WHO does it”

• “with WHOM”, and

• “WHEN and in WHICH order”? 1 IDS Scheer is the company founded by Professor Scheer and has been well known for many years due to his process design and documentation tool ARIS, something like VISIO especially designed for use with SAP. The latest version of ARIS focuses on supporting SAP’s ESA strategy by providing a custom tailored visual business process model design (http://www.ids-scheer.com/)

http://www.ids-scheer.com/


www.SAPtips.com



Business processes are usually treated in a “top-down” fashion. This often starts with executives or business owners drawing up a business model (“high level”), which will form the basis for all subsequent steps of business process implementation, execution, and monitoring. To illustrate this, consider Figure 3, which shows how the Enterprise Service Bus forms the infrastructure for the inter-process communication of independent components.

Figure 3: The Enterprise Service Bus Provides the Infrastructure for Inter-Process Communication


www.SAPtips.com



Figure 4 looks at the different layers of business process management from a different perspective. It depicts a basic “logistical scenario” that consists of the following 3 levels:

1. Scenario Level – A scenario is typically depicted as a collection of business processes that interact with each other in an enterprise. This could be a set of specific processes that create a value chain of all key processes in a specific industry (e.g., automotive).

2. Business Process Level – a process can be seen as a “sub-process” in a bigger scenario. A business process has well defined starting and ending points and defines the logical sequence of events within the process.

3. Transaction Level – this is the real “nuts and bolts” of the business process. It encompasses the physical processing of messages, and accompanying integration and workflow steps.


www.SAPtips.com



Figure 4: From Scenario Design via Business Process Model to Transaction Level

So how does one go about “linking” the high-level business scenarios to the low-level business process transactions? Any failure to understand business processes in an end-to-end manner


www.SAPtips.com



from “high level” management concepts, right down to the transaction level, will severely impact a company’s implementation strategy.

“ARIS for SAP NetWeaver” is a product developed by IDS-Scheer and SAP that allows companies to get a complete view of their BPM solution. Business processes can be analyzed from the design phase (business innovation and strategy), to modeling (business model) via configuration, right down to the technical and business monitoring of business processes. ARIS is used here to provide the formal content description of business processes contained in the SAP NetWeaver architecture. The models are physically stored in the SAP XI repository, while the processes themselves are controlled by the Workflow system. Most of the methods and tools being developed by SAP and IDS-Scheer revolve around supporting the new Enterprise Service Architecture (ESA).

Figure 5 illustrates how SAP NetWeaver, SAP XI, and ARIS stack up together to provide companies with a strategic BPM platform that they can work with.

Figure 5: How a Process Design Tool Like ARIS Sees NetWeaver

So we can see that “ARIS for NetWeaver” augments the SAP NetWeaver platform quite nicely with its “business-level modeling”. This is by no means suggesting that you have to use this set of products to get a comprehensive BPM solution in place; there are other companies out there (like Seeburger) that provide just as good integration with ARIS as SAP XI does (thanks to the BPEL standard). Yet, it is still nice to see companies like SAP and IDS-Scheer working together on a seamless BPM solution that customers can gain long lasting benefit from.


www.SAPtips.com



2.1.1

2.1.2

2.1.3

Business Activity Monitoring Business Activity Monitoring (BAM) was introduced in Part I of this series, and basically revolves around the fact that most business problems can be associated with one or more breakdowns in a business process. BAM comes to the party with its ability to accumulate and leverage real-time operational information that gives managers (and users alike) the ability to make business process improvements that will inevitably impact business value.

Monitoring Process Performance To be able to improve a process, you must be able to measure its performance. To measure performance, you must know what a transaction is doing at any point in time. It is one thing to be able to automate messaging transactions between trading partners and other systems; it’s another to be able to provide your suppliers and strategic decision makers with the “business intelligence” they need to get accurate visibility into your production schedules and inventory levels. Giving all parties access to the “real time” processing of daily transactions is crucial. This would include “message tracking” and Web portals that would allow a supplier, for instance, to check her stock levels in real time. Providing this sort of functionality will bring about better collaboration and improvements in the supply chain.

Following a business process technically can be very challenging. However, Web services and their associated enterprise service bus have provided us with a new, rich set of “points in the process” that can be more easily monitored. This is the essence of BPM transparency. For process performance assessment, “Business Activity Monitoring” (BAM) can now track time spent in the process, time spent waiting, and the number of errors occurring in the process.

In the end, a seamless connection between BPM and BAM is the key to true business process optimization. BAM and its association with “dashboards and cockpits” were discussed in Part I of this series. As mentioned, many of the EAI products out there will use words like “Business Activity Monitoring” in their sales talk, but all they usually provide is good “technical monitoring” of the solution, nothing else. Therefore it becomes imperative that the chosen solution be built on an open architecture (supporting ESA) that at least allows you to build or purchase you own BAM solution easily.

BAM, Business Events and SOA BAM actually provides a nice “mix and match” between service orientated and event-based computing (also termed “event-driven architecture” (EDA).


www.SAPtips.com



Figure 6: Business Activity Monitoring Listens to Activities on the ESB and Sends Alerts via the Bus

Event-based computing has the ability to capture events, which can act as further input into other applications, or services that may (or may not) converge later, to deliver updates to a dashboard. Furthermore, when these alerts or events occur (SMS, email, workflow, etc.), the person (or application, or service) receiving the “event” should be able to act on it. Factors to consider in this would include providing the person or application with the necessary information to make a decision, and the authority and tools to invoke a response.

So you can see that BAM consists of numerous intricate areas like service orientated computing, events, workflows, processes, notifications, and people. In order to get the greatest return on investment, you need to create a “bridge” between events, services, and processes. Choosing a platform that supports the service-orientated architecture and event-based computing will make your life easier in achieving such “business analytics” in the future.

From where we are right now, you can clearly see that an EAI solution cannot just be seen as a “silo” on its own, but MUST be seen as the “glue” that seamlessly integrates people, processes, business events, and services within the extended enterprise.

2.1.4 Enterprise Service Bus The ESB was described in Part I of this series. However, there stills seems to be a lot of debate as to whether an ESB is a product, an architecture, or just a “way of doing things”. An ESB is an “architectural stack of technologies” that works together to enable developers and architects alike to create intelligent, adaptable applications that can automate business processes, as well as interactions, between multiple systems and organizations. An ESB can be thought of as the central component of a service-oriented architecture. The SOA presents “services” to the ESB that then routes, transforms, and validates inputs and outputs from these services. Once an ESB is in place, further projects and components can just “plug in” to the existing “service backbone” and provide greater flexibility and reuse in future projects. Figure 7 shows how the different ESB technologies and standards stack up together.


www.SAPtips.com



Figure 7: Enterprise Service Bus Stack of Technologies


www.SAPtips.com



2.1.5

As more and more companies start exploring the “service paradigm” in their new projects, it will become increasingly important that the chosen integration product and vendor have a clear and well-defined ESB strategy going

B2B Gateways? The world has never been as inter-connected as it is today. Mergers, acquisitions, and new partnerships are relentlessly negotiated and formed. The world of EAI is no longer confined within the walls of the enterprise—for true cost savings and efficiency; a company’s processes must be seamlessly integrated with its value chain partners. This is depicted in the following:

Figure 8: Extending the ESB Across the Company’s Facilitates B2B

Looking at a scenario, an inventory pull in one company may have a ripple effect down the supply chain, impacting things like billing, stock, and shipping in other trading partner systems. Today, more than ever, there needs to be a strong “synergy” and interaction between processes along the entire supply chain. The fact that you can use EDI and XML, etc., to communicate with your larger suppliers is great, but what about the small suppliers who are incapable of funding such an endeavor? Do you just ignore them? No, this is most certainly not the answer, and you need to find ways that enable you to accommodate ALL business partners along the ENTIRE supply chain.

With all this in mind and the fact that the chosen solution needs to align with the “Corporate Integration Strategy”, “Business Process Management”, etc., you can now start to see that selecting an EAI package is not just a simple thing like buying a “word processing” package. It entails a deep understanding of the surrounding environment and its impact therein. Once again, it will be very difficult to “rip out” the wrong integration solution once it is in place, so careful consideration and planning is required!

2.2 Considerations to Choose the Right Orchestrator The previous section highlighted key aspects that need to be considered when analyzing an EAI solution. In a world where “buzz words” and “hype” reign supreme, a technology or vendor promoted one week may very well be chewed up and spat out by the following week. Web services seem to have survived their early life quite well, but will they be able to steer themselves


www.SAPtips.com



2.2.1

2.2.2

through all the “hype”, and provide the agile, pivotal “backbone” needed by companies today? The following section looks at this and other issues, and further compares how the “big players” in the integration market shape up against each other.

Business Criticality If a company makes the (recommended) transition towards a service-oriented enterprise, the decision on the right EAI orchestration tool will be crucial. The EAI will be the very backbone of your daily business operations. Your staff will blindly rely on its proper functioning once they get accustomed to the benefits it provides. These benefits will include things like a higher throughput and quality of business processes, easier handling, and an abundance of immediately accessible information. Once the solution is widely accepted, there won’t be any realistic fallback strategy that would allow your business to continue without it, just as your business won’t continue without computers any more. There might be alternative procedures that let your business survive for a limited period of time, but you will loose your competitive advantage.

Business Compliance: Big and Mighty or Small and Smart? Because the decision for the EAI will be driving the heartbeat of your business, a decision cannot be made from a technical viewpoint only. The full context of a solution needs to be compliant with your business. Whether that means going with a big vendor or a collection of smaller ones is a matter of evaluation. From our viewpoint, however, the larger vendors are the ones you want to align with when it comes to SOA. In the first place, you have to be sure that your vendor is able to execute over a long period of time.

• ESA – A Decision for a Generation Once you made the decision for a certain solution, you will no longer be in a position to change it easily. It would simply mean that you would need to go through the full implementation and change process again, causing enormous costs and even more trouble and frustration within your organization. Simply imagine how costly it would be to replace R/3 with any other solution, or even to just replace current hardware with a different one. This might make you vulnerable for gouging (or something near extortion) when it comes time to ask for any new services, negotiate license fees, or perhaps trying to buy a product from one of the fiercest competitors of the EAI vendor.

Some may remember that there was some uproar when Microsoft changed its licensing policy without respecting the wishes of their customers. Many threatened to switch from Microsoft to Linux, but then the businesses said “Stop!”, as such a transition would have simply been even more expensive.

But it is not actually “evil will” of the big vendors that may jeopardize your full IT plans in the first place. In the case of Microsoft, it has been a simple rule of the markets, because the potential competitors of the Linux world did not really promise reduced TCO in the long run, so Microsoft adjusted their prices to what the market would be willing to pay. Other vendors like IBM have clear company ethics that would not allow driving a customer into bankruptcy due to IBM’s fault or bad will. However, there are gray sheep amongst the big vendors as well, especially if company politics are dominated by the personal vanities of individual CEOs or founders.

• Be Sure the Vendor Won’t Be Washed Away The real risk lies in the guarantee of technology persistence. It is primarily an issue with smaller vendors, as there is a potential that they may go out of business due to financial problems. Other risks are that they might fall victim to bigger competitors as we have all seen in the case of JD Edwards and PeopleSoft. In this situation the continued existence of their products is purely in the hands of the Oracle board. But one can also see in the case of Microsoft (Navision) that it need


www.SAPtips.com



2.2.3

not be that way. When Microsoft took over Navision, they had to take over a very complex and unconventional treaty construct upon which the Navision distribution politics had been built. This led to the ongoing situation where Navision had a different distribution policy, incompatible with Microsoft’s general strategy. But it guarantees the persistence of the product in its original form.

Not being dependent on the fatal end of a specific vendor has always been a striking argument in favor of SAP R/3. Having a readable and changeable source code in your hands does not only give you great comfort, but also provides the security that your company can continue to use and maintain the software efficiently, even if heaven falls on the head of the software manufacturer. That is also the argument to prefer Java over any of the other “Java like” solutions. They may have the potential, but the manufacturer disguises the source code in a final paranoid moment.

The decision in favor of a smaller vendor is therefore a very political one, given the potential risks that come with it. If a huge corporation relies on a small vendor, it must be ready to eventually take over the company and all its technology components. But that already carries another risk: what if your strongest competitor simply takes over the company before you, and now possesses the key to the core technology that your company depends on? One of the presumable reasons of SAP’s success with R/3 in the 90s lies in the fact that by then aircraft manufacturer Boeing decided to use BAAN as their corporate ERP system. For fear that BAAN could end up on the good will of Boeing, many companies looked for alternatives, and found them in R/3.

Key to Successful Integration Evolution We often hear phrases like “seamless integration”, “more agile”, smarter, quicker, etc., but as we all know, there is often a big gap between vision and reality. Enterprise-wide integration is not just about choosing the right EAI solution, but also involves a number of other facets that need to work in unison to get the enterprise integration strategy moving forward as one unit.

• EAI Projects Are All About Communication Too many times companies have purchased EAI solutions without a solid integration strategy in place. This is like buying a Ferrari without having thought of building any high-speed lanes. Then, after a successfully installed pilot project, the EAI solution begins to gather dust. A concrete integration strategy and business plan need to be in place before the pilot project even kicks off. But it’s even more important to realize that EAI projects are large “communication projects”—and communication is never easy. And we are not just talking about communication between applications here; integration requires the successful communication between companies, people, processes, and data. BPM is not just about modeling your business processes; it necessitates an entire paradigm shift in mindset that requires the active involvement of all relevant target groups. Getting this mix working together well is the key to a long lasting integration solution that will form the “backbone” of the enterprise.

One of the big issues that needs to be sorted out is the miscommunication between business and IT people. There needs to be a shift in mindset that will bring business and IT people closer together rather than have them sitting on opposite sides of the fence, staring at each other in utter confusion. Deciding on the ESA is comparable to setting out for new shores that have never been seen by any of your “fellows” ever before. You will have to live with them in close contact, and nobody shall ever be allowed to lose “the vision”. Everyone on the crew needs to be able to recall the very Cape from which the mission was launched from the beginning, and even from before the adventure commenced. Therefore, keep in mind:

Get people sitting around the same table early on!


www.SAPtips.com



2.2.4

• EAI Solution Provides an Infrastructure Not a Solution The integration market continues to grow at an alarming pace. Confusion reigns supreme as solution providers continuously bring out new buzzwords, acronyms, standards, and technologies. This can give the perception that integration is in a constant state of confusion. To avoid this confusion, we need to get a clear understanding of all the possibilities, by taking all the pieces out of the box and then re-arranging them into something that resembles an integration solution. There are many technologies out there; you just need to find the right “mix and match” to get a solid solution up and running.

One of the big misconceptions in the industry today is that installing an EAI solution will solve all the integration requirements of a company. Integration is seen more as a project-based, technical event than a strategic, enterprise-wide activity. A company needs to put a “stake in the ground” and get its business processes, system architecture, and stakeholders tightly aligned in order to get a successful, long lasting integration solution deployed.

Because EAI projects are so delicate and specialized, a company will do itself a great justice if they invest in setting up an “EAI competency center”. This “EAI competency center” will house dedicated EAI staff that are not “bogged down” by everyday issues but can rather focus on the integration tasks at hand, and share their knowledge where appropriate.

To get an EAI solution, and company-wide integration strategy kick-started and heading in the right direction, focus on getting the following right:

• Get a clear understanding of the enterprise integration strategy

• Select a tried and tested EAI solution, and associated infrastructure

• Put strong project management into place

• Keep it simple!

ROI Analysis There has never been such a great demand for enterprise integration vendors to be able to deliver appropriate return on investment (ROI) on the solutions they deliver. Tighter IT budgets, and even greater pressure to deliver faster, more innovative solutions, is not an easy situation for an IT manager to be in—but it is reality! Without seeing valid ROI potential, few customers out there are willing to invest in any new integration technologies or products. Because integration wraps its tentacles into all areas of IT and within the business, it is very difficult to work out or calculate “actual” ROI from the solution. However, one needs to step back for a second and really get a deeper understanding into what the EAI solution really has to offer the company.

• No Quick Dollars But Long Term Business Advantages There is no question that a considerable amount of time should be taken early on to analyze the pros and cons of the software package. This may include developer, customer, and business partner advantages (to name but a few). But it should not stop there; look at aspects like improved time to market, better customer and supplier relations, better business process management, and the ability to create new business opportunities. Are you able to put a price on factors such as these? The fact is that you can’t easily put a fixed dollar value on “creating new business opportunities” or increasing customer satisfaction. You should not walk blindly and merely look at pure financial rewards only—there is a bigger, more strategic piece to this puzzle.

But let’s look at this from another angle. Let’s say, for example, that your company exports certain products and materials to other companies in the world to be re-sold. This is big business in many


www.SAPtips.com



industries and typically can add hundreds of millions of dollars to your company’s bottom line. Let’s also say that you have a “mediocre” EAI/EDI solution in place that inhibits you from getting new interfaces to these business partners in an efficient manner. Are you able to put a financial figure on what it would mean to your business should you happen to lose just one potential overseas deal? It’s not nice “speculating”, but this has the potential to be millions of dollars in missed business, due to a company’s inability to get a message mapped, and implemented in a quick and agile manner (not to mention the loss of a strategic partner).

• Business Monitoring Reduces Mistakes and Enhances Efficiency There are other areas to look at as well. A good EAI solution should be able to increase the efficiency of the IT department, and hence “could” give managers the ability to move staff around a bit, or even reduce IT headcount. The freed up personnel could then work on further process improvements, and so the iterative process begins.

Business process management (BPM) has been mentioned before, but it should once again be stressed that the ability for management to better monitor key aspects of the business, streamline business processes, and map key performance indicators (KPI’s) against actual performance in the business, is invaluable for longevity and general “value add”.

• Innovation Drives Business Innovation is the name of the game these days. Change is not only good, it is IMPERATIVE! But what good are innovative ideas if you don’t have the tools and technologies available to make them a reality. AS2, RFID, web services, etc. are just some of the enabling technologies eagerly waiting to be taken to their full potential. Without the appropriate infrastructure (or at least strategy), these technologies will just be something your company reads about and never actually implements. Innovation means radical new ways of thinking! These innovative ideas usually stem from the misfits, geeks, and weirdoes in your company. But you need to remember that in today’s world these are the people who have the ability to think “outside the box” and take your company to the next level. Support them; give them the platform and technologies they need to be able to put their ideas into practice! (They may just be your saving grace!)

Let’s take a look at another simple scenario to consider. You have a “custom” ANSI X.12 message that needs to be mapped into an SAP standard IDoc. Let’s say your company has a process in place to map the message, but this involves outsourcing the “mapping development” to another company. Let’s say the total mapping turnaround time (including testing) is seven days. With the proper EAI solution in place, you should have adequate “drag and drop” mapping facilities at hand that could potentially decrease mapping time from seven days to a matter of hours, or even minutes (depending on message complexity of course). This is quite an easy one to put a cost on. Costs can add up very quickly if you have a “legacy” mapping process in place and have an SD consultant “waiting around” to get a new EDI message mapped! Do an internal checklist as to the exact steps needed to get an EDI message mapped and tested. Look at things like: how many people are involved, how much programmer development time, etc. Then turn the scales around and either get a live mapping demo from the EAI solution you are interested in, or ask reference sites that use the product what their typical turnaround time to get a message mapped is. Is there a significant difference? Do the sums—more often than not you will be shocked! Big time and cost savings can be seen in this area alone!

One of the inevitable things in an ROI analysis is accounting for both the known costs (EAI software, hardware, consulting services, third-party tools, etc.) and variable costs (operating and support costs, maintenance fees, etc.). Vendors usually provide you with numerous payment and licensing options. Analyze these different options, negotiate with them, and come up with a result that is fair to both parties. But remember, don’t just look at the initial cost of the EAI solution—look


www.SAPtips.com



2.2.5

2.3.1

at the bigger picture of what strategic advantages and opportunities the new solution will offer the company. They are difficult to see, but find them and stretch your company’s potential to the max!

Finding an EAI Solution that Plays Well with NetWeaver It may sound like a paradox: wasn’t NetWeaver actually marketed as SAP’s premium solution for EAI? So why are we looking for something to do EAI in conjunction with NetWeaver?

• From One-Single-Vendor to Best-of-Breed It is no paradox; it is the essence of EAI that it abandons the “All-in-One” in the sense of the “One-Single-Vendor” paradigm. The requirement for the Service Oriented Enterprise has a different focus however: all players within the company’s IT infrastructure should behave as “social electronic citizens” who deliver their services on request to any other member of the society of software components.

When we are deciding to have an EAI solution that works well with SAP NetWeaver, why don’t we just buy everything from SAP? Having a single vendor will please both purchasing and computer center operations. Once again we have to bring in the basic motif of the big ESA and EAI into symphony: there won’t be a single vendor ever who could fulfill ALL the requirements in business, just as there won’t be a single car manufacturer who could fulfill the needs for all specialty cars. While it is good to have a common procedure of doing bookkeeping across companies, it is fatal to apply the same algorithms to every production process in industry; they are simply too different.

• A Democratic Society of Objects Enterprise Service Architecture will give you the freedom to choose an application from any vendor around the globe to work seamlessly with the provided architecture, as long as it complies with a minimum common standard.

If you ever look at a modern street system, you will see where the idea comes from. There are so many different vehicles: small ones, big ones, quick ones, slow ones, etc. There is no central institution that controls the movement of every car, like it is the case with air traffic. The ground traffic functions because all abide by a very small set of rules, like staying on the paved lanes, respecting green and red lights, and a small set of conflict resolution rules. If you added more rules, the traffic won’t become safer and vehicles would not be able to move faster—the contrary would happen. This is the idea that also drives ESA.

So we are investigating who would be the one to build the highways for our EAI, so that we can still run all of our valuable NetWeaver components (that already exist and run perfectly well). Should we let SAP build the highway? Or are there others who have a better, cheaper, or more visionary way to build the common transport system to be used by everyone?

2.3 What the Big Vendors Claim We are now going to give a synopsis of what the big players in the ERP market – namely the front-runners, SAP, IBM, Microsoft, and as a representative of the challengers, Oracle, have to offer from an EAI architect’s point of view.

What They All Have in Common Trends are not set by a single company, but are set by the times. A good idea that comes too early is doomed to fail just as if it happened to come too late. An ingenious thought at the wrong time will make you look like a fool instead of a hero. Leonardo da Vinci was highly respected as a painter of religious paintings but his drawings of a helicopter and the human anatomy were seen


www.SAPtips.com



2.3.2

as an outburst of diabolic fantasy. So it is no wonder that the big players have an analogous strategy as well.

All the big players try to offer a full-range software integration suite that should be sufficient to run an enterprise without the assistance of third-party products. While this is the traditional strategy, they all shifted their paradigm from all-in-one and single vendor politics towards modularization, standardization, and openness for external components.

The technology leaders in this area are IBM, Microsoft, and SAP; and they all offer strategic solutions in the five areas of interest:

• People Integration - where we primarily think of portals and collaboration tools

• Knowledge Integration - Business Warehouse and related solutions

• Business Integration - refers to classical ERP and specialized industry and niche solutions like APO

• Technical Integration - Middleware and data exchange standards like WSDL fall into this category. Currently this is the most crowded battlefield with hundreds of competing vendors of all sizes.

• Common Runtime and Development Framework

Here we speak about Virtual Machines that overcome the differences in hardware and operating systems. This is where the technology fight takes place.

So we can basically state that all the modern solution providers have agreed on a common structuring of the business requirements. We now need to check out how well prepared each solution might be, as well as which solution may slip in best for a certain business structure.

Message Queues

• MQ-Series: World-class Message Queue When it comes to high performance message queuing, IBM WebSphere MQ is second to nothing. The technology and algorithmic built-ins there have their roots in the job entry subsystems (JES) of the early 1960s and has gone through many evolutionary steps since then. Performance, high availability, and data protection are the key arguments in favor of WebSphere/MQ.

• Microsoft MSMQ: Built-In Professional Performance If you run with predominately Microsoft servers, then the preinstalled Microsoft MSMQ will be an appropriate option for standard cases and necessities, unless you have very special requirements for high availability and performance. This, however, is generally not a question when you decided for a pure Microsoft (and hence INTEL) server farm.

• SAP Leaves the Field to Specialty Vendors

SAP does not provide for any true, high performance message queuing system. SAP XI and the WebAS IDoc engine pretend to act as a message queue. On the one end, the IDoc engine excludes itself as a contender because it is just a single queue for a special purpose. On the other end, SAP XI excludes itself as a serious competitor because it requires data to be delivered


www.SAPtips.com



2.3.3

ultimately in XML, while an indispensable requirement for a message queue is to be able to collect and bunker data before it does any processing steps.

Business Integrators (Workflow Engines) A great message queue is unfortunately a dumb piece of software, and as such is dependent on software that actually consolidates and processes the messages.

There are definitely more than 100 business integration engines out there. There are the sharks and the small niche providers. Interestingly enough, hardly any of the integrators deliver a complete set of the most commonly used design patterns when using their workflow tool. In practice, this means that every customer has to code (and test, correct, and enhance) the same algorithms over and over again. When all the integration engines finally comply with the BPEL standard, there is hope that someone will bring out a toolbox that solves the most common problems. These include: the multiple redundant messages in a queue, content-based serialization, and simply appropriate adapters.

• A Market for Team Players: Seeburger The big players in this market are Mercator, TIBCO, and SeeBeyond; none of which are outstanding. One product worth mentioning is the approach done by Seeburger2. They have actually come out of the EDI business and have standardized their EDI message adapter and monitoring engine into a fully featured BPEL compliant business integrator. What makes Seeburger an interesting choice is the feature rich business-monitoring dashboard, and its strategic partnership with SAP. Furthermore, Seeburger is the SAP endorsed supplier of EDI adapters for NetWeaver and XI. Although furnished with a standard J2EE engine, Seeburger plugs transparently into SAP XI and is capable of running on the SAP WebAS J2EE engine as well. Currently, you won’t really see a benefit out of this, but if your company decides on SAP NetWeaver for strategic reasons, then you would need to consider a feature rich and tested adapter suite (mainly, but not exclusively for EDI). Secondly, when SAP releases its “unbreakable Java”, Seeburger will immediately make use of the new robustness. Interestingly enough, this may lead to a situation in which Seeburger will be an argument to establish XI; because it establishes such a great symbiosis.

• IBM Puts Stakes on Wizards IBM offers WebSphere Business Integrator software. This is a classical workflow and adapter tool that allows picking messages from a wide variety of formats and data sources, normalizes them, and hands them over to a processor. This all is accompanied by a standard toolset for handshaking, monitoring, logging, and error handling. IBM always stresses that its goal is to deliver model-driven development tools that allow a functional consultant to draw up business processes that automatically compile into appropriate workflow code (be that BPEL or anything else that suits the need).

• BIZTALK Goes WYSIWYG It comes as no surprise that Microsoft BIZTALK follows the visual design approach. The design tools provided on BIZTALK are certainly among the most elaborate, with its familiar touch of Windows and Visual Studio. If you allow your organization to rely on Windows and i386 technology for the next decade, BIZTALK is a most serious choice.

2 SEEBURGER is another long-time associate of SAP. They had been, for a long time, the only EDI converter tool that concentrated on being an EDI interface provider for use with R/2. SEEBURGER is now an official provider for EDI solutions along with SAP XI (http://www.seeburger.com)

http://www.seeburger.com/


www.SAPtips.com



2.3.4

• SAP XI Has Still a Long Way to Go SAP XI may be a future challenger; but currently it is only something for pure SAP shops. It is still in evolution so it can be recommended for smaller experimental applications but not for any mission critical ones. The endless list of notes and bug fixes on installation of XI makes administrators swear day and night. We currently feel like we are back in the early days of Windows when we spent more time on installing and fixing the software than using it productively. The visual design tools are not really what you would call “state of the art” and developing a cunning process monitoring dashboard would certainly be a fertile area for a third-party development. A strong point for XI would have certainly been if it ran exclusively on top of the robust ABAP engine, instead of the current J2EE engine. Then you could benefit from the established maintenance and development experience of ABAP and R/3. The situation will be different if SAP bring XI together with the future “Unbreakable Java” J2EE engine, which will introduce managed processes as an indispensable prerequisite for running a workflow engine in a business critical environment.

People Integration

• SharePoint: Portals and Slightly More When it comes to people integration, there is hardly anything to beat Microsoft’s offer. You may either like Windows or not, but it’s a fact that it is a standard in most offices, and the end-users won’t really follow expert disputes about GUI designs and whether Linux or Windows has a better offer. They all know Windows, and software that looks like Windows is most welcome.

• Windows Is the True Portal There are many collaboration tools, no wonder, with all the abundance of Windows software available. Microsoft itself offers its SharePoint software (that originally was designed as a Web-based collaboration system). When the Portal hype started all over, Microsoft quickly reinvented SharePoint as “SharePoint portal server”, with the result that it is now the most sophisticated and feature-rich portal software out there. When you look a little closer at SharePoint, and Windows in general, you would ask yourself if a Windows GUI for portal content would not be the most appropriate, and by far, cheaper and convenient solution, when used for intranets only.

• IBM Complies to Open Standard IBM WebSphere has its own portal server, unspectacularly named: WebSphere Portal. WebSphere Portal is a strict follower of the open portal standard RFC. This allows plugging in portal components designed for any other portal that abides by this recommendation.

• SAP Enterprise Portal You would probably not choose SAP EP if you do not run SAP NetWeaver for other purposes already. EP has its strengths only if the majority of portal content is information-backed, in one or another, by SAP R/3, SAP BW, and the like.

If you are to choose a portal solution that has predominately non-SAP content, then it would be wiser to discuss whether to stick to a fully open standard solution like WebSphere portal, or developer friendly approaches like SharePoint. Other vendors, like Oracle, may have an appeal if you already have a relationship with the individual supplier. Generally the decision for a portal solution could be based on the already existent server landscape, so let your administrators and developers fight over what makes the most sense.


www.SAPtips.com



2.3.5 Business Content and Information Integration The strength of the new Enterprise Services Architecture is the full freedom of choosing the best solution for an individual niche. If you run R/3, you do not necessarily have to use SAP BW as your data discovery tool. If you like how SAP BW does the job, go for it, at least in runs on ABAP, which is a great advantage if you plan to develop your own special data evaluation tools. If you are more interested in scientifically supported time-series analysis and prognosis, you might consider the (SAS) Statistical Analysis System (http://www.sas.com/) tool that also delivers a neat SAP bridge, and in addition, has highly professional graphics and any kind of statistical analysis that science currently endorses. For an SEM solution, you might also want to have a look, specifically in the Windows market where a larger number of specialty and niche vendors deliver simulation software that targets the needs of individual interests and industries. As far as a general business intelligence tool goes, we very much liked the Windows-based BOARD M.I.T. from Swiss company Orenburg (http://www.board.com/).

IBM plays a different card: their strategy is based mainly on third-party vendors. It is a declared work sharing: IBM delivers the engines and working framework, while others produce the software. This strategy is mainly headed towards SMEs, and is convincing because the smaller vendors have a good appreciation of the business needs, while being in need of a strong, reliable development framework.

.NET is the Windows world, so you can choose from several thousand ERP solutions all over the world. Microsoft itself claimed its share but apparently could not decide which one would suit it best. They have three big ERP solutions in their portfolio: the old fashioned Great Plains, the modern Navision for small and mid-sized enterprises, and AXAPTA, that targets the high-end market. None of them are genuinely developed for, or on top of .NET.

A player that still needs to be observed is Oracle. It is yet unclear what Oracle wants to do with its acquisition of JD Edwards and PeopleSoft other than trying to weaken the market position of SAP. The fact is that, currently, the uncertainty within present PeopleSoft sites is high, and the number of specialists that position themselves as “PeopleSoft to SAP migration experts” is on the rise.

2.3.6 Business Process Integration IBM is definitely the technology leader in the area of ESA, if you regard it from a scientific point of view. They attack the field with pure technology. IBM is one of the protagonists of the Enterprise Service Bus, and if you ever wanted to know more about the technical background of it, you would need to start digging into the abundance of material found at IBM “developerWorks” or dive into their “Redbooks” (http://www.redbooks.ibm.com).

• SAP Is the Shooting Star SAP is the clear challenger with its Exchange Infrastructure. Although it took SAP until the SAPPHIRE Copenhagen, and Boston 2005 conferences to finally commit themselves to the ESA paradigm, they already have a strong positioning in the market. The current releases of XI are certainly over-estimated when compared to what other middleware products have to offer. On the other hand, SAP seems to be the only performer in the circus that can honestly provide a full, big enterprise with all their own products. This said, it is intriguing to use NetWeaver XI as the middleware and technical ESA layer, despite its current deficiencies. Time evidently plays in favor of SAP. Transforming the enterprise to ESA will take time, time that will help SAP to make XI mature enough to be competitive with the leaders in this area. Though, we are still tempted to claim: if XI were a pure ABAP product, they would have achieved this already.

http://www.sas.com/

http://www.board.com/

http://www.redbooks.ibm.com/


www.SAPtips.com



• Microsoft Excels Through Windows An interesting product to look at is BIZTALK, with its wealth of features and almost certainly the most mature (and easy to use) design interface. The difficulty with BIZTALK is that it requires Windows, and hence, also the accompanying hardware restrictions. If one has a general look at Microsoft, then one has to admit that the Windows landscape is already a very good ESA infrastructure, based on the DCOM (and now .NET), distributed application framework. They are also very quick learners when it comes to standards, so BPEL and WSDL were quickly adopted by Microsoft in the respective products. While others were fighting about the right standard, Microsoft implemented what they thought would be required, and hence set the standards through pure facts. HTML and more on point, Javascript, are now defined by the capabilities and DHTML support of Internet Explorer rather than the W3C body. If you use XML, then the first reference is the Microsoft “msxml3.dll”, which is part of every Windows installation. Therefore, whether you like it or not: if an application does not run through Internet Explorer, you cannot sell it to the masses. Period!

• Big Specialized Vendors are Still Dominant Currently it is not necessarily a fact that IBM, SAP, and Microsoft are truly dominating the market. There are other big names in this area like Mercator, TIBCO, IONA, SeeBeyond, etc. They are all great products and have proven their value in many cases, but unfortunately some of them give the impression today that they would rather invest in marketing than in technology and education.

• The Hour of the Smaller Vendors We are all blinded by the light shining from the big players, but we can now take off our sunglasses and see what else the market has to offer. There are numerous other vendors providing Business Integration middleware and many of these products have much more too offer. This comes as no surprise, as most of these vendors come from the pragmatic edge, and developed their products not with marketing considerations in mind, but because they needed something to solve a specific problem. We encounter the same situation when we look at software revolving around CRM or Business Warehouse capabilities. Here, most of the average PC products you can buy deliver far more useful features, and higher performance, than the big vendors will ever be able to offer. Unfortunately they seldom have a faint idea of how to roll-in their software to corporate headquarters and onto the clerk’s desk. After our test, we decided for technological reasons, that Seeburger BIS best suits our needs, because it plays so well with NetWeaver, and has strong EDI capabilities. But you cannot use this as a “generalized” decision for all companies. Nevertheless, take a closer look at some of the smaller vendors out there; they may just offer you exactly what you are looking for.

• Fiorano Muscling In… One vendor that has potential as a new challenger in the market (and that we, unfortunately, did not evaluate) is Fiorano3. Their “Business Integration Suite” of products shows awesome SOA and “event-driven architecture”(EDA) support, and they provide an equally impressive “Business Component Architecture”(BCA) framework. Added to this, Fiorano has shown very impressive test and performance results when compared to other products like Tibco and IBM WebSphereMQ. The runtime deployment infrastructure, and associated integration and modeling

3 Fiorano is a leading provider of Enterprise class business process integration and messaging infrastructure technology. Companies use Fiorano products to develop Real-Time Enterprise competencies, improving operational efficiencies and business performance by easily deploying flexible business processes spanning multiple applications, platforms, and partners. (http://www.fiorano.com)

http://www.fiorano.com/


www.SAPtips.com



2.3.7

tools provided by them, looks highly impressive, and this could easily be another “smaller” vendor that you should keep your eye on!

Development Framework IBM WebSphere applications run on top of the IBM WebSphere Application Server (WAS), which is a container-based J2EE framework. The descriptive attribute of IBM WAS is its stability and robustness under stress and extreme operating conditions. The primary programming language is Java. Process isolation application flaws may only bring down their own process, and do not affect any other processes in the runtime environment. IBM is the original contributor of the Eclipse framework, and Eclipse can be used to develop for WAS.

• Development Framework Microsoft’s .NET framework is an immediate extension to the Windows operating system. Without simplifying too much, one can say that .NET and Windows are the same. The core of .NET is the common language runtime, a set of sophisticated libraries, and a pseudo “just in time” compiler that translates the Microsoft Intermediate Language (MSIL) into native code.

Microsoft provides its own development environment, the Microsoft Visual Studio. There are, however, other IDEs available (e.g., the open source Borland Delphi is also capable of producing .NET compliant code). A remarkable point is the big choice of programming languages. There is the modern C++ derivate C# (pronounced C sharp), a new fully object-oriented version of Visual Basic (which actually looks more like Modula-2), and Microsoft’s Java dialect: J#.

The choice of components that can be used with .NET is absolutely endless, and it furthermore allows using any registered “COM” component from the underlying Windows installation. This contributes to a higher productivity and quality level in application development by simple reuse of software components.

• ABAP Is Unbeaten The true strength of NetWeaver is its ABAP development and runtime environment (and, of course, the full featured and unmatched ERP suite).

3 Test Drive and Examine Your Candidates Going away from the business politics, we find ourselves in a crucial decision-making position where we need to look at the technical considerations for choosing an EAI solution. EAI will quickly become the central nerve center of your IT systems. It will be something like the central highway, conducting the traffic from and to the central business areas. If it fails, or your message handling pipes get congested, then all of your business alongside the highway will suffer. As a consequence, EAI should be able to prove its worth on the “battlefield”, and should be put through some stringent test scenarios. You want to bombard the solution with everything you have, to ensure it will survive the toughest of days in the production environment. Because an EAI software solution has so many facets and intricacies to it, you will need to sit down and carefully decide on what specific, crucial areas you want to tackle—more specifically you need to decide:

• WHAT are you going to test? For example, you may decide that you want to see how well the EAI solution works if it gets 10,000 messages dumped onto it at any one time. This is not always just to test the EAI solution, but also how well it interacts with other software products, like SAP, under such a stressful situation.


www.SAPtips.com



3.1.1

• WHY are you going to test? You may speculate that the likelihood of a huge number of messages coming into the system at one time is very high, and you need to ensure that the solution can handle the extra stress without creating a negative effect on business.

• HOW are you going to test? This is debatable and will be specific to the situation at hand, but would typically entail setting up a “lab type environment” whereby simple, stressful scenarios can be easily set up, and results evaluated.

• WHEN are you going to test? You may be tempted to say you’ll test it before you buy it. But there are other decisions to make. Do you test before you install the applications you want to plug in? Do you first decide on EAI standards? And more important, will you do a test drive, or will you buy the software based upon the impression of a presentation, and then start the bullet test?

• WHO is going to test? It needn’t necessarily be you who actually performs the tests. It can also be the vendor’s obligation to deliver accurate and reliable test results. Normally, it should be sufficient to demand a vendor certificate for the results you request.

Further along in the article we will discuss how to go about “defining an investigation pattern”, to show how you would test the EAI product from all angles.

3.1 Criteria for Evaluating an EAI Solution It is not just about pricing. Actually the packages offered are so different, that they cannot honestly be compared with each other, except with respect to price and value. There may be some packages that simply fall out of your budget, regardless of the great features they have, just as a Mercedes would normally fall out of your budget when deciding for a new family car. Nevertheless, an EAI solution’s performance, implementation speed, and scalability are crucial to any long-term integration strategy. Furthermore, a vendor’s viability and strategic alliances can be pivotal in deciding on one solution over another. In the end, the chosen solution should increase operational efficiency, lower costs, and provide the business with an agile platform with which they can move forward confidently.

There are so many things that an EAI solution needs to support, from basic “message brokering” functionality, to mapping to adapter support, to even things like the RFID and AS2 support. It will all depend on your individual needs, but, in the end, there will always be a few pieces of functionality that are required in any solution. The following takes a look at what “bare essentials” you need to look for when evaluating both the EAI solution and providing software vendor.

From a technical perspective, the solution should be built on top of an “open standard framework” that satisfies the following basic requirements.

Basic Requirements of an EAI Solution

• Queuing A queue is a programmable space that receives and buffers messages for further processing. A proper queue must be capable of accepting, storing, and sorting any message it receives. This is usually handled by creating instances of queues that collect the messages they take care of. There must be a “dead letter queue” that collects all undeliverable messages. A message sent to a queue must never be rejected.


www.SAPtips.com



• Message Transformation and Formatting The best-liked area of most EAI tools is that of writing transformations. There should be simple table maps along with the ability to plug in programmed conversions. Clever EAI tools can automatically guess a likely mapping that only needs to be adjusted by the queue designer.

• Message Routing In EAI it would be the exceptional case that the creator of a message would know the address of the recipient. It should rather be that the queue can determine the receiver from the “message context”, like message type, syntax of the message block, and special tags in the content. The SAP IDoc setup is an example of how the routing problem is solved impractically. When you send an IDoc, you have to specify the receiver with the IDoc header record provided, although the receiver is usually coded somewhere in the context as customer or vendor number (or similar). Good tools look into the document to determine the receiver.

• Queue Consolidation This is still a seldom-found feature. There are many abstract activities that need to be performed on a queue that still have to be programmed by everyone individually. Problems are messages that are received redundantly like a message received from a Web site where the user clicks several times on the submit button (“nervous finger syndrome”) or messages are received from different sources with contentious content, e.g., a material master record where one message changes the price and another one the texts.

• Easy Partner/System Configuration and Connection A quick and intuitive tool is what an administrator wants. They have no time to read endless documentation, and they would not want to set the same partner port for 250 vendors, that need to receive purchase orders via EDI.

• Business Process Management This goes into the area of workflow. The queue handler should be able to trigger appropriate further actions from “hints” found in the message. It also needs to track the successful execution of the following steps, and eventually alert an interested party if something happens that is worth mentioning.

• Monitoring and Exception Handling This is one of the weaker points of most EAI tools. While they can easily monitor their own information and messages; a dashboard that monitors many heterogeneous and hybrid applications plugged into your EAI is often much more difficult.

The problem is that almost all good EAI products provide this sort of basic functionality in their products to a certain degree. So what separates one product from another?

One thing that immediately comes to mind is the ability of the software solution to provide “standard maps” to make the mapping of complex messages easier and less time consuming. You’ll be very surprised how few EAI vendors actually provide this sort of functionality in their products to support a company’s “vertical industry needs”. That’s one of the problems with some of the big vendors out there, as they have plenty of support for the latest and greatest technologies and standards, but don’t provide the “niche” functionality that’s often required. Besides this, you could also carefully analyze how the algorithms and underlying technical architecture of the solution actually work, and then compare this to other similar solutions. Benchmark tests and associated results can come in handy here.


www.SAPtips.com



3.1.2 Analyzing the Vendor

• General Reputation of a Vendor You will, however, also need to turn your attention directly to the vendors themselves, and see exactly how they are perceived in the market. A great indicator of this is to take a look at the Gartner “Magic Quadrant for Application Integration Suites”. This will give you a good indication of the vendor’s market presence and their product’s efficacy. This report quickly sums up who the market “challengers”, “niche players”, “visionaries” and “leaders” are. This is not to say that the “market leaders” are necessarily the ones you need to focus on, in fact, often the smaller, more “niche” players are the ones to keep your eyes on!

Besides looking at the “Magic Quadrant” to get a good overview of the different vendors, you should also do a little of your own homework on the vendors to see how they shape up in the following areas:

• Vendor Viability – How does the market perceive them? You want to see sufficient customer references, including implementations of large, successful, enterprise-scale, complex scenarios.

• Vendor History – Look to where vendors have come from – if they’ve been in the integration market for a number of years, they’ve probably been involved in numerous integration projects, have hit their heads a few times, and have been able to use these experiences to restructure and redesign their product to provide you with a more solid offering. “Tried and tested” is always better than “new and hyped”!

• Vendor Strategy with SAP – This is not generally a problem with the majority of EAI vendors out there, but it is nevertheless crucial that SAP sees the EAI vendor as a “strategic partner”.

• Size of Vendor – This needs to be considered carefully. Small companies react quickly, big ones have more overhead. This overhead is welcome when you ask for many repeating actions, as it guarantees repeatability and compliance to standards. But a standard is often the smallest common denominator, so size can actually work against you when you require quick reaction times and specialty advice and support. Sometimes, when a vendor gets too large, their organizations start behaving like a big tanker ship. Reactions are lazy, and every action outside the normal plan requires enormous efforts and costs. They may very well appear as if they have got a very “arrogant” attitude, and you could find yourself locked into a lifetime of following “their rules”. On the other end of the scale, you don’t want a vendor that is too small, and is out of “geographic reach”.

• Implementation Skills and Consulting – The vendor should have a proven track record with many successful, large-scale implementations. The vendor should furthermore be able to provide the right consulting expertise to ensure that your implementation can be as smooth and painless as possible. Perhaps the vendor can also provide you with a document that walks you through the major phases of the implementation. Does the vendor provide remote consulting expertise? This typically revolves around providing special, short-term consulting to troubleshoot problems over the Web or telephone. We need less talk on integration and more about implementing integration solutions!


www.SAPtips.com



3.1.3

• Speed of Implementation – Implementing a new integration package is never easy, and depends heavily on how quickly you can get it up and running, how much of the business is impacted, and what value the solution will provide. A company can gain quick advantages in the market by selecting a vendor whose solution can be implemented quickly, and that provides great strategic value. The speed of implementation should be one of the core features you look for when analyzing a vendor.

• Service, support and training – The vendor should provide you with the flexibility, training, and support you require to ensure that your everyday operations can run as smoothly as possible (without breaking the bank!) Furthermore, do they provide training in EAI technology and EAI best practices? Are you able to leverage your existing resources and skills?

• Single B2B and EAI Solutions – Many application integration vendors out there (be it moving from the EAI space to the B2B space, or visa versa) are becoming increasingly aware that their products need to support BOTH strong EAI and B2B application integration. Let’s face it, EAI is no longer confined within the walls of an enterprise, and it is becoming increasingly important for integration products out there to provide the necessary tools, templates, and mappings to make trading partner integration as easy as possible. Questions you should ask yourself include:

• Does the EAI solution require you to purchase the entire vendor product suite?

• Does the vendor own the EAI solution, or have they merely repackaged someone else’s product?

• Single Vendor Strategy? This is by no means imperative, but you should “try” to use the same vendor for both your EAI and B2B requirements—it will just make things simpler in the long run. Some of the larger vendors like IBM, Microsoft, and Oracle provide great “generic” integration suites, but often require you to plug in other “adapter” products or modules just to get a simple B2B scenario working. This may not be the best option—you should be able to purchase ONE solution to cater to both your EAI and B2B requirements!

• Scalable License Options – The vendor should be able to satisfy your infrastructure with the appropriate “flexible” and fair license scheme.

• Cost – Obviously cost comes into play when deciding on an EAI solution. You should get a good feel what the “market perception” is on “how much a similar product would cost”, and then move forward from there. The vendor should be “open-minded” to hearing your case, and you should be able to negotiate in a fair and professional manner.

Features We Like to See in an EAI Solution

• Mapping Tool – Your EAI solution should let you repeatedly leverage existing mappings. One challenge the product should overcome is the ability to easily map non-XML to XML data structures.


www.SAPtips.com



• Data Validation – The amount of time spent checking error messages sent from or received by your organization can become an absolute nightmare. The integration solution should be able to cleanse and continuously crosscheck the data to ensure it is correct and error free.

• Development Environment – Performing a message mapping should, for example, be provided with a simple “drag and drop” mechanism.

• Mainstream Integration Skills – Should the solution require programming, it should not entail learning a proprietary programming language, but should rather be based around the mainstream languages of J2EE and .NET.

• Open, Standards-based Architecture – Does the EAI solution work on a variety of the most popular platforms, application servers, and databases? Can the solution work efficiently in your current client/server architecture? Is it flexible enough to allow you to have both JDBC and ODBC connections into numerous data stores? What about Web Service support?

• Adapter Support – The EAI solution should support a large number of industry specific adapters that allow it to plug into another vendor’s product line.

• Scalable – The solution should be able to scale according to your requirements.

• Metadata Management – Any good EAI solution should allow for the easy setup and maintenance of metadata used in integration processes and scenarios.

• Workflow Management – There should be a simple “drag and drop” environment in place that allows you to define quick workflow scenarios that can be tested in minutes.

• Process Modeling – You are going to need a product that allows you to orchestrate the communication between certain systems and services in a seamless and easy to understand manner. A toolbox or palette should be provided within the development environment that provides you with the objects you require to whip up a BPEL process in no time. This is closely related to “workflow management”, above.

• Business Email – Email integration is still one of the most widely used means of communicating today. Why not get a product that gives your smaller suppliers the option to use “business mail” to send and receive documents like Orders, Delivery Notes, Invoices, etc., to you via the simple email interface. Small suppliers can receive a pre-configured form via e-mail, and once it has been filled out, it can automatically be transformed into an XML document and seamlessly integrated into you backend system.


www.SAPtips.com



• Collaborative Design – EAI projects often span several countries and different time zones. The EAI solutions should have a suitable “check-in and check-out” facility that allows developers to work on the code they need to, and then be able to “resynchronize” with the central repository to update and get the latest source code version(s).

• Business Dashboard – Business dashboards should provide users with key performance indicators (KPIs) that enable them to measure and improve the speed and effectiveness of organizational operations. The difference between dashboards and cockpits was mentioned in Part I of this series, but you can equate them to an airplane cockpit or the dashboard in your car. You are able to drive a car, or fly a plane without a dashboard, but doing so is both dangerous and error prone. This is also true for the enterprise; management needs to be made aware of exactly what is happening along the entire value chain at all times, or they may fall victim to what problems lurk around the next corner. This is, unfortunately, where most EAI solutions fail dismally. They typically provide great “technical monitoring” but fail to provide the “business process monitoring” needed to monitor a business process from end to end. This is what management is crying out for. This “business monitoring” may provide gauges, meters, flashing icons, etc., that give management the view that they need to be able to see exactly what is happening in the business, at any particular point.

• Simulation – Many businesses have high volume, resource-intensive workflow processes that are not easy to test or debug. It is very useful to be able to easily simulate and test these scenarios to get an idea on how they will perform, before they are deployed. This will allow the systems analyst to determine what resources are needed to achieve the best performance, what bottlenecks are occurring (if any), and if there is any unproductive use of any other resources.

• Message Filtering – Often, messages coming into an integration product are very complex, and need to be filtered before being forwarded onto the target system(s). Filtering analyzes incoming messages, and selectively leaves out certain content, etc., before passing it onto the integration server; or the message is simply sent onto the target system.

• Intelligent Routing – Basic message routing is a “basic” requirement fundamental to any integration solution. Simply put, “routing” is the mechanism of moving information from one system to another. It is crucial that the solution is able to split information coming out of one system, and send it to multiple target systems. It must be able to “group” information coming from many systems, and send a consolidated message to a single target, and able to handle messages coming from many systems, that need to be sent to many other systems. Intelligent, or “content-based” routing builds on this, but on a more “dynamic” and “intelligent” level. When a message arrives in the integration server, it is first analyzed to determine what system it comes from. Once the source system and message schema are understood, the message is transformed (if required) and additional services and rules are applied. Once the message has been processed, the integration solution routes the message to the correct target system.

• Business Events – Business events occur daily in a business. However, with the correct solution in place, they provide an actual opportunity to increase the speed and accuracy of business processes. By “speed” we mean manufacturing a car faster, or being able to deliver better customer service. In a typical business environment, a business event would be something like the arrival of a new


www.SAPtips.com



shipment, employee address change, or a batch job failure. When a business event is raised, it should trigger the relevant business process, which could involve a combination of both automated (i.e., SMS, email, etc.) and human activities. The applications that will be developed in the next five years will better address business events than those developed in the previous 25 years.

• Intelligent Workflow – Any alert or exception raised by the application should be escalated to different managers, based on the importance of each alert, and the role of each business user. This might also mean alerts via email, SMS, etc. Be sure your EAI solution caters to this—remember we want business transparency and seamless integration. Workflow is at the heart of this.

• Flexible Adapters – Most EAI products these days have numerous adapters or modules that allow you to quickly and easily integrate into third-party software products and systems (like SAP, SQL Server, etc.). Most adapters these days are, however, somewhat “thin” in nature, meaning that they typically provide no enhanced functionality but provide only a simple “bridge” between communicating applications, and actually have a negative impact on performance. To make matters even worse, the majority of these adapters are proprietary in nature. The following shows where adapters are heading to – the “model-driven” approach.

• Model Driven Architecture We are slowly but surely moving away from “thin”, highly customized adapters into a more “model-driven”, “richer” adapter. These enhanced adapters provide developers and architects with a pure abstract view of the configuration details needed to get the adapter working correctly. Because these adapters are “model-driven” very little code is required. The adapter allows users to get a nice, businesslike, graphical view of the process, without having to worry about the complex connection details in the background (and is therefore able to focus more on the business issues at hand). So you might have an abstraction for middleware services (like connecting to MQSeries), or another abstract layer that allows you to connect to a database like SQL Server. The adapter will encapsulate the complexities behind connecting and communicating with the application or data source and will just present users with a friendly, graphical view. With all the benefits these “richer” adapters can provide, it comes as no surprise that integration vendors are moving more and more towards them. However, this type of adapter requires a substantial amount of time and money to develop, and therefore some vendors are somewhat reluctant to take the plunge. There is no doubt that as integration becomes more sophisticated and challenging, enterprises are going to be looking for integration solutions that follow a “model-driven” development approach, require little or no programming, and give architects a “minimalistic” view of the enterprise. Therefore, be sure the EAI product supports these “richer” adapters, or at least has a strategy or partnership that supports such a requirement in the future.

• Miscellaneous – There are certain pieces of functionality that can be very useful in the production environment. As an example, let’s say 1,000 messages have just come into your EAI product, BUT there is a problem: the “plant” in each message needs to be changed from “2300” to “2400”. What do you do? Not that you should ever edit the contents of a message in a middleware product, but under certain “adverse conditions”, you may be forced to. Re-sending the messages may not be an option, so the software should provide some sort of “find and replace” functionality for updating the required data in a specific segment of the message. These little pieces of extra functionality can be very valuable under stressful times.


www.SAPtips.com



3.1.4

• Many More Objectives to Consider The list presented here is long, but even so a list of additional options you might want to consider is probably even much longer than this. Nevertheless, this one gives you a good idea of what type of questions you should be asking EAI vendors out there, to ensure that you are getting the best deal for your money.

Robustness of the Runtime The application framework debate has been around for quite some time now. The maturity and stability of the underlying framework is not really the striking argument here.

• Standard J2EE Engine Lack of Stability J2EE is the only architecture that has questions surrounding its robustness and stability. But let’s face the facts; the majority of integration products out there run on a J2EE engine, so we need to get used to J2EE in our company setup – period! But the question still remains: is it really possible to build a Java application server that never crashes?

• WebSphere Runtime and ABAP as Positive Examples IBM WebSphere has proven its robustness and stability over the years. This has mainly been attributed to the reliable IBM Java transaction engine running beneath it. The SAP ABAP application server followed very much the same path as IBM and based its architecture on “process isolation” from the very beginning. Many may even debate that SAP WebAS has shown greater stability in the productive environment than both Microsoft.NET and J2EE4.

• SAP to Introduce Process Isolation for J2EE SAP WebAS is the powerhouse behind all R/3 enterprise systems and has given companies unrivaled stability over the years. SAP has taken a strategic direction to incorporate J2EE into their product suite, and has subsequently invested heavily into ensuring that SAP’s J2EE engine implementation becomes as robust as the “tried and tested” ABAP engine. To aid this, SAP announced the “Always on Java initiative”, which set out to create an “unbreakable” Java engine.

Java has always typically followed the “big bang” approach, whereby everything is processed within one virtual machine (VM), and this VM runs inside one process on the OS level. This has the potential to negatively affect all users on a system, should a single user’s request fall into error. SAP, however, has decided to take a different approach and has based its Java implementation very much on how it architected the ABAP application server. In ABAP you have a dispatcher and a number of work processes that handle the user requests. The dispatcher ensures that only one user request can be processed by a work process at any one moment in time. If the application the user is busy with crashes, only the current process is affected: all other processes behave as if nothing has happened.

4 See “Clash of the Titans Part 3: Why WebAS Beats Microsoft.NET and J2EE” by Axel Angeli, logosworld.com


www.SAPtips.com



Figure 9 depicts how both the ABAP and Java Virtual Machines run within one work process, providing full isolation for the requesting user.

Figure 9: Process Isolation Makes Java VM More Stable

• NetWeaver Unbreakable Java Will Bring Java Further Since most integration products out there run on a J2EE engine, it becomes very important to select a J2EE implementation that is robust enough to last you through the worst weather. SAP’s Java implementation looks very promising, and its “Java isolation” concept is a welcomed enhancement. Should you choose an integration product other than SAP XI, make sure that it supports a robust Java implementation like IBM or SAP’s version. Seeburger is one such company that has ensured its new “Seeburger AS” (application server) product is fully compatible with running on the new SAP WebAS J2EE implementation. This is great news because you


www.SAPtips.com



3.1.5

know that a company like SAP can’t afford to have their J2EE engine crashing, and hence, stability is pretty much ensured.

Artificial Intelligence Once applications have been integrated and processes orchestrated, processes themselves may become intelligent.

They can:

• Become aware of their role and overall impact within a ”bigger picture” process, and may very well understand how they are affecting customers

• Introspect/analyse data to determine the value of the impact

• Automatically send notifications about bad or erroneous data coming through the process

• Learn to predict when problems are likely to occur

For instance, if the process knows one supplier is starting to take longer to respond to “just in time” (JIT) requests, it can notify someone and start giving more requests to alternate suppliers who seem to be doing better.

• Intelligent Adapters Today, most of the adapters out there are “static” in nature, meaning they have no real understanding of the systems or schemas they are connected to. This means that they have been manually coded to both send and receive information, using the sender and receiver schemas. These “static” adapters have no mechanism in place to dynamically change their configuration should the schema change on either side (i.e., an underlying database schema changes, or database table gets more fields added to it).

We are now moving into an era wherein certain adapters need to become more intelligent in nature, so that they are able to “learn” about the environment they are in, and are able to adapt accordingly. Typically an “intelligent” or “dynamic” adapter is able to learn about the systems it is connected to when it is first connected, but more importantly, it continues to adapt itself to a changing environment by “re-synchronizing” with the connected systems, to see if anything has changed. For example an “intelligent” adapter will understand when an invoice number attribute changes, or perhaps it will even wait until an underlying record in a database table becomes “unlocked”, before trying to update it.

• Paper-To-ERP The Internet has enabled us to communicate like never before; nevertheless, most transactions still occur via paper and manual operations. This can mostly be seen when dealing with things like invoices and orders. Manual processes are error prone and are often associated with things like:

• Manual data entry errors

• Lost documents, like invoices or orders

• Increased time needed to fulfil a customer request

• Inability to verify the receipt of documents


www.SAPtips.com



• Increased cost and time associated with manual data entry

Any company wishing to continue their competitive advantage, needs an EAI solution that is able to automate many of these manual processes. What we are all looking for is an Artificial intelligence (AI)/Optical Character Recognition (OCR) solution that truly works.

• Document Image Recognition Here we can already think a step further: we would probably not only want to recognize written texts but also scan and interpret drawings and sketches. It is nice to digitize the construction plan of a motor, but it would be nicer if the software could already identify the parts, and put them into the proper inventory.

For an EAI solution to be really valuable, it should provide the functionality to scan an image, capture the data, and then assemble that data into something usable by an application.

• Radio Frequency Identification (RFID) The proper implementation of radio-frequency identification (RFID) solutions can provide significant improvements in the value chain, as well as help provide real-time access to inventories. Bar code readers are very common in warehouse settings today, because they are simple and easy to set up.

Because both bar code and RFID technology are somewhat related, it becomes crucial to understand how the two can compliment each other in the enterprise environment. A distinguishing feature of RFID over bar code technology is that RFID does not require line-of-site interaction between the RFID tags and readers.

It is not very complicated to write software to collect the information sent by a barcode or RFID scanner. What we do need, however, is a standard procedure that comes with the EAI software, which allows us the flexibility to not have to write those programs, drivers, and adapters over and over again. The chances are good that your company already has a functional and working system based on bar codes and business processes that have evolved over the course of many years. The big question remains as to if you should refactor your existing business processes to cater for RFID, or just leave your current bar code solution intact. The aim should not be to replace one solution with another, but more that they should work in “unison” in the future. The EAI integration strategy should reflect this.

• Supporting Telecommunication Standards Like AS2 It’s never easy for a company to integrate with all their trading partners. Many smaller companies often don’t have the economical and technical support to enter into such a collaborative environment. There are many technologies available that would easily allow such collaboration, but unfortunately, most large organizations have not implemented these offerings for their smaller trading partners, and therefore, “inefficiency gaps” still exist in the process chain. The huge amount of new standards and technologies has eliminated previous network limitations, and has given the possibility for a company to integrate with all its trading partners. The less technologically sophisticated your business partners are, the more reason you should look into easier-to-adopt technologies such as HTTP web services, AS2, and even FTP and SMTP. The key challenge is for a company to understand what communications options and protocols are out there, and they need to mix and match these with the right customers and suppliers. We can already say that for smaller companies, SMTP would certainly be the easiest means, but for larger traffic, other options are gaining momentum.


www.SAPtips.com



3.1.6 EAI Orchestration When one thinks about EAI orchestration, one needs to almost view a situation where you need to “link the dots”. You want a certain set of applications/processes to be interconnected so that a specific outcome can be achieved. The goal these days is not so much to speed up business processes, but rather to ensure that they are flexible enough to rapidly adjust to ever-changing market conditions. It is, however, crucial that there is a clear understanding between “technical process modeling” and “business process modeling”.

Technical process modeling is provided in a tool like SAP XI or Seeburger BIS and allows you to connect processes within applications, in a flexible manner. You would choreograph integration scenarios and processes not only within a company, but also between companies.

Figure 10 depicts a technical workflow/process orchestration using Seeburger BIS.

Figure 10: Orchestrating Business Workflows Using Seeburger BIS Workflow Designer

Business process modeling, on the other hand, is modeling at the business level. This is typically accomplished by a product like ARIS, and gives a clear business perspective on the process architecture of a company, ignoring the technical details.


www.SAPtips.com



3.1.7

3.2.1

So then what is the difference between an “orchestration scenario” (i.e., BPEL) and workflow? Well, in a nutshell, the “orchestration scenario” is the map of the roads and the streets, while workflow is the traffic and payload that rolls over the lanes.

Composite Applications Composite applications are basically solutions built around processes. The goal of this is to make processes faster and easier to change. Principally they are nothing other than workflows, and you should be able to model the big majority of composite requirements by simply defining them properly in BPEL.

For reasons of performance and easier development, it might occasionally be preferred to use other approaches to code and assemble the applications into a new hybrid. SAP xApps do exactly this, but it is still a question whether this technology should be followed. BEML and BPEL modeled processes are easier to follow, document, maintain, and, last but not least, easier to replace.

One big advantage of a BPEL design is that all steps are visible and defined as ontology in a common language. Any step can, hence, be replaced, and execution can be rerouted to an arbitrary execution platform. If, for example, you calculate your material requirements in APO, you may change to a competitor’s product, like Manugistics or I2, just by rerouting the respective WSDL section within the BPEL stream.

3.2 Defining the Investigation Pattern In this section we will try to define the common patterns of daily operations, and more importantly, the typical patterns of failure.

Load Test A “Load Test” checks to see how well the system handles an enormous load that is suddenly dropped onto it. For example, let’s say we have 10,000 messages sitting in a queue in MQSeries, and they are all suddenly injected into the EAI solution. How does the system behave? Does it still give appropriate response times? You may have a “time critical” environment that requires a minimum of 5 messages to be mapped a second; if this changes to be 1 message a second (under a “Load Test”), is this acceptable to the overall business process?

The aspects to investigate here are many.

• No message must be lost, whether it is processed or not.

It should speak for itself as it is a matter of course, but reality shows that many message queues have severe problems with it.

• Acknowledgement must be sent in a timely manner if requested.

In an asynchronous communication, the acknowledgement that a message has been received and accepted (not necessarily processed) is very important for the sender. This is like bringing an important letter to the post office: you trust the postman that he will take care of safe delivery but as long as he does not confirm that he accepted your delivery order, you sit down and have to wait.

• Forwarding messages for processing must not bring the receiver down

This investigation is related to the side effect test further down, and simply means that the queue cannot take the load of 10,000 messages, and dump them into the SAP system, whose performance is then slowed down unacceptably.


www.SAPtips.com



3.2.2

3.2.3

3.2.4

Stress Test A “Stress Test” is closely related to the “Load Test” and monitors and checks the stability and reliability of the system when enormous loads are placed on it regularly, over an extended period of time.

The additional point to investigate is whether the system can guarantee the requirements set down in the load test, and also when the load is put on over a longer period of time. The classic failure here is a system that can accept many, many messages, as long as the load fits well into available RAM. But when this runs out or stack memory is low, the systems starts paging, or garbage collecting, and won’t have any time left to do its most important job. This phenomenon is typical for straightforward, un-tuned object oriented systems, where the developer has no control over the moment when garbage collection takes place. But there are also situations where the system gives up all of a sudden. We have seen error messages like this one often: “More memory is needed to complete task. Aborting”.

Volume Test A “Volume Test” checks to see what the absolute maximum number of messages your system can handle at any particular time is. This is obviously also determined by the processing power and threading model of the chosen server.

The interesting parameter to check is related to sizing and scalability. There is certainly an amount of messages that can be handled by the hardware. The question is, “Is it an absolute barrier, or can you increase your capacity by adding a bigger (or another) machine?”. This question should be answered clearly by the manufacturer.

Fail Over Test A “Fail-Over Test” is an interesting one because it monitors how well the system operates when “one link in the chain” is broken (so to speak). You would do this test by simulating failures in different parts of the system. For example, you could crash the JVM and see if the system automatically restarts it or not. In the end, this sort of test is used to determine if business can continue in the event of a system crash.

• Does the system recover automatically when it is brought down?

You can imagine pretty sophisticated mechanisms here. Crashing the JVM is certainly one of many circumstances in which you may find yourself. An example of a more challenging situation you may encounter are the “frozen tasks” we all experience in Windows from time to time, when a task simply does not get sufficient CPU time assigned. An external (and independently running) watchdog, that permanently supervises the health of the queue, is certainly a nice feature. Here are some elements you may want to look out for. If you could answer all of them with “non applicable” for the product in the test, then you would have a fine tool in front of you.

• Hardware or power failure

• A leased connection is terminated unexpectedly

• Central dispatcher freezes

• Acknowledgement is not received in time

• Acknowledgement is received only after resending the message


www.SAPtips.com



3.2.5

3.2.6

3.2.7

Side-effects (Safety) Tests It can’t be emphasized enough that your EAI solution will not live in isolation, but will rather live in an ecosystem with other software solutions and products. You really need to follow the entire process to see how the other products in the landscape are affected in adverse conditions. Take an EAI system that communicates directly with SAP. Is there, for example, a mechanism in the EAI solution that provides some sort of thorough “handshaking” between itself and SAP? You want a scenario where, if 10,000 messages are suddenly dumped on the EAI solution, then it “politely” queries SAP, “I have a message, are you able to process it now…Yes…ok, here it is…next message”. We don’t want a potential scenario whereby the EAI solution can handle the huge volume of messages, but the receiving system cannot.

If the receiving system cannot do a proper handshake, we need to have mechanisms to cope with it. SAP’s standard IDoc handler IDOC_INBOUND_ASYNCHRONOUS, for instance, only confirms that the RFC was successful, but not that the message could be stowed away safely for processing. In that case, we need a strategy like a “lazy sending”, that allows you to assign a certain (and adjustable) viscosity to the data stream, so that the message can be sent with a delay in between, or in small packages.

Standard Operation Procedures This is an issue that comes out of daily operation. Does a vendor of a software product have some sort of “Standard Operation Procedure” to react to common incidents, or does the vendor simply wait until something happens and then pull out the guru joker to solve the problem? It is quite clear that a solution cannot handle all the possible problems and scenarios. But there should be a clear procedure for what to do if the worst case happens; know what to do to avoid the worst-case scenario from happening.

What to Do With the Test Results Following the actual tests, it is necessary to know what was planned to execute, and how to analyze and interpret the test results. You should have a good idea on what is actually “required from the business” and, following that, you can gauge if the test results were acceptable or not. So what do you do if the test results are not satisfactory? Do you follow tradition and buy a bigger box? Sometimes the answer to this is yes, but in some instances you may need to seriously consider running benchmark tests between other EAI solutions to see which one actually has the best performance.

4 Discussing Test Results In the following text we are going to demonstrate how we applied the testing requirements, and how we discussed the individual issues. The examples given will mainly be taken from the winner of our selection process: “Seeburger Business Integrator”. Seeburger suited us best because it works so well within the NetWeaver family and has the option to work both as a stand-alone as well as a plug in to SAP XI.

• There Is Currently No Outstanding Product We need, however, to make one thing clear. It has been the winner for our installation. Like for all EAI applications, it holds true for the EAI orchestration tools as well. There is not one single vendor who can deliver a solution that would fit perfectly with all the different business needs and company infrastructure. Indeed, there is currently not one product that is truly convincing in the sense that it is outstanding, or beats the competitors in most categories. We are still at the beginning, but are in somewhat of a dilemma; we need to decide on something that should hold as a strategic platform for a decade or more. This leads us also to the only “knock-out” criteria that was formulated; the vendor must give believable evidence that their strategy is committed to


www.SAPtips.com



openness, and any future option will be a competitive offer, but all the time not ruling out the use of any product acquired from a third party.

• Today There Is No General Recommendation There have been a couple more orchestration tools under consideration, and test results for them exist. We, however, believe that it does not make much sense in putting them into direct comparison. The reason why a certain product is better or worse than another one, is so dependent on the actual situation, that it would not be fair to point it out under the premises we made.

We are only discussing the sector “Business Integration” here, as it is the most interesting and most competitive spot in the full EAI symphony. Other areas like message queuing are usually already firmly established within a company’s infrastructure, so it is rather a set factor to consider when choosing the remaining elements, than an object to be replaced.

4.1 Author’s Choice: Seeburger Business Integrator We know that people like to read a recommendation. It is, however, clear that such a decision is very sensitive to the environment of the corporation where the solution will be implanted. So, there won’t be a general recommendation. We needed an example to demonstrate how our selection process came to a conclusion. We have selected Seeburger Business Integrator as our choice for a Business Integrator software to work in combination with an already existing IBM WebSphere/MQ and an SAP-loaded ERP environment. It intrigued us because it showed the best overall performance with respect to:

• Completeness of required features

• Lack of “knock-out” criteria

• Reliability and safety

• Total cost of ownership

• Sustainability of the product

It was typically only due to a higher price, or the presence of an individual knock-out criterion (like lack of a complete suite of EDI message format adapters), that a specific product lost position against Seeburger.

In some cases, like WebSphere or SAP XI, the EDI adapters are third-party developments, plugged into the central engine. In the scenario we had, there was a strong need for EDI (in conjunction with the EAI part); however, there was no need for a high performance and high availability message queuing mechanism, as there was already WebSphere/MQ (without WebSphere Business Integrator[WBI]) in place to guarantee that all message traffic is tracked and secured, so that no messages are ever lost. Based on these performance considerations, we found the “Seeburger Workflow Designer”, monitoring tools, and the better SAP integration make it the best option for an SAP Business Integrator tool.

• Seeburger Can Snap into NetWeaver Another argument from our side was the fact that, from the business end, Seeburger officially partners with SAP to deliver the EDI adapters for SAP XI. Since XI has been a strategic choice in the given context, we also took into account SAP AG’s recommendation to use Seeburger as the adapter engine, in combination with SAP XI.


www.SAPtips.com



4.1.1

4.1.2

The more mature systems like WebSphere, Mercator, and TIBCO had no problems at all with such requirements, while some of the “EDI-only converters”, or older and more trivial middleware software, surrender when a certain message load was reached. So it is generally the case that with the high priced products you will get mature and highly reliable software, but you may buy a lot of features that you don’t and won’t need. Some of the big ones, however, appear to be a simple collection of a bit-of-everything, and if you assemble the parts, they are obviously very complex.. The EDI-centric products are more focused on data conversion, and play well in conjunction with a mature orchestration tool, but often lack the state-of-art, and extensible, message orchestration engine.

Defending the Architecture Many issues (during a software evaluation) cannot be measured by non-intelligent methods, but rather, need a thorough balancing of the risks and benefits. In addition, dump test results are only figures. They provide a good indication of trends or facts, and they may support or void a certain opinion or assumption. But the final decision is always a very intellectual one – one that needs to be discussed seriously in a discourse with all decision makers and technical people. Sometimes, the decision is also paired with a “gut feeling”. This is usually an indication that the data upon which you are basing your arguments, may be unclear, or lacks some essential information. Keep in mind: data always maps into your existing knowledge. Measurement results will tell you nothing, when they cannot be associated with some solid, previous knowledge or expectations. This is also an argument as to why the decision cannot be made by the corporate board members, after a brief report or discussion with the technicians.

Deciding on EAI software is a decision that may revolutionize (or not) your company. So you should take a scientific approach – as it is habit in medicine, for instance – to let all parties report and defend their position, until the final decision maker has enough information to decide. It cannot be said often enough that it is not the duty of a decision-making board to question technical and marginal details, but rather to make sure that those who investigate the machinery give valid evidence that they have shed a light on every essential aspect and were able and willing to consider the concerns of a third party while evaluating and preparing their proposal.

So the question remains, how do I properly defend a decision? Here, classical rites known from universities come into play. This is done by a rigorosum. A rigorosum is a public hearing – somewhat like a court tribunal – where all parties try to convince a neutral arbiter that their decision is based on sound investigation. Every scientist has to go through this if he proposes to change current operation procedures. In our case, we would let the testers and software manufacturers demonstrate that they have taken care of all issues and are able to defend the chosen solution.

So, we defined the scenarios we wanted to test, and asked the vendor to execute them. This is an appropriate way of doing it. In industry, it is even standard that the manufacturer delivers a certificate, wherein they guarantee that the requested specification is met. If it turns out later that the certificate has been falsified, and the product fails because of one of the deficiencies in question, you can take them to court (or elsewhere) for redemption and indemnity.

Stress Test Results Stress tests were conducted in our second round of evaluation. We clearly decided that we should not do the stress testing ourselves. Infrastructure software, like a business integrator and adapter engine, is complex, and definitely not well understood, in all details, within a couple of hours. In order to set up and tune the test subject, it would have been necessary to attend an intensive training session, followed by a longer period of practicing and experimenting. Doing this for all the short-listed products is simply impossible, unless you operate as a full-time test laboratory.


www.SAPtips.com



Seeburger was asked to put their product “through the trenches”, so to speak, and later give verified feedback of the results. What was nice about our test requirement was that it was focused around how well Seeburger BIS operates under stressful conditions, within an SAP environment. This was to ensure that appropriate “handshaking” was done between Seeburger BIS and SAP at all times to ensure that nothing “falls over” when Seeburger BIS has an enormous strain placed on it. Needless to say, there was absolutely no problem here.

Quite clearly, hardware choice is a very important feature and can influence test results quite dramatically. To prevent other EAI vendors assuming that this is the best Seeburger BIS performs under stressful conditions, we will just say that a “somewhat” powerful server was used and no extra configuration enhancements or “tweaking” were done at all. Seeburger BIS was tested on an absolute “clean” installation.

Typical automotive mappings were thrown into the system (i.e., EDIFACT to invoice IDoc) and were tested in packages of 10, 100, 1,000, and 10,000 messages. Crosscheck indicators and measures were used to get the accurate times spent processing the messages, and results were revealed.

NOTE: The following are only a fraction of the test results presented to us, but should give you an idea on some of the basic test parameters you would want to see in a similar test situation. Once again, the results here are by NO means the maximum capability of Seeburger BIS. It would be able to operate MUCH better in a productive environment with all the “bells and whistles” configured and “tweaked”. When analyzing the results in Figure 11, pay special attention to the SIZE of the messages going through the system.

Workflow Mapping File

Count Size of input message in KB

Size of output message in KB

Test Start Test End Duration Files Per second

Receiving Treatment

EDIFACT_to_ IDOC_INVOICE

10 10,000 14,000 11:38:43 11:38:45 0:00:02 5

Receiving Treatment


100 10,000 14,000 12:31:26 12:31:58 0:00:32 3,125

Receiving Treatment


1000 10,000 14,000 12:34:51 12:42:08 0:07:17 2,288

Receiving Treatment


10000 10,000 14,000 14:07:10 15:26:03 1:18:53 2,112

Figure 11: Stress Test Results for Converting EDIFACT Messages to IDoc

Figure 12 illustrates some further test results observed when numerous standard “receiving treatment” workflow scenarios were driven through Seeburger BIS (using common EDI mappings). The test clearly shows how the number of files that can be processed per minute is dependant on the size of the incoming file, as well as the specific mapping that is called. Once again, results will vary depending on the chosen hardware and configuration.


www.SAPtips.com



Figure 12: Stress Test Results for Converting Numerous EDI Formats to IDocs

So, it can be said that Seeburger BIS operated extremely well under all the different test scenarios that were thrown at it. The strategic interaction between Seeburger and SAP showed clearly throughout the product evaluation, and it eventually became a “no contest” situation as to what strategic integration product we should choose for our SAP environment.

4.1.3 Useful Business Features If two or more products play in the same league and seem to be comparable in their basic value, you may want to look at other features they provide as an added value. The most precious offer a product can make is to save time, which is usually equivalent to saving money. In the case of our selection process, we had an eye on the value of the product for use with an EDI-loaded environment.

• Ready to Use EDI Converters Being able to design and change EDI mappings and routings, along with proper triggering and monitoring of subsequent business workflows, had been a focal point in this evaluation.

It is no surprise that Seeburger soon became a favorite for the final choice. Seeburger BIS has strong support of EDI standards and provides a ready-to-use map for nearly any type of data exchange between SAP IDocs and EDI standards (like VDA, ODETTE, EDIFACT, ANSI X.12, etc.). An editor that makes it easy to design new maps, mainly from flat file formats into IDocs (and backwards), is appealing. But, if you are selecting for an organization where EDI plays a minor role, or is handled elsewhere, then pre-selection under this aspect is of no value.


www.SAPtips.com



• BPEL and ARIS Integration Seeburger has had a long-standing, strategic partnership with IDS-Scheer. This is great news for managers who want the ability to integrate process models in a “top down” fashion from a product like ARIS to a product like SAP XI or Seeburger BIS. Seeburger BIS has a “business process engine” that is based on BPEL standards. This enables customers to design and build business processes on ARIS, and then later download them to Seeburger BIS to be executed. This is exactly the same in SAP XI.

• Paper-to-ERP Manual, paper-based processing is still rife in many organizations and often stretches itself throughout the entire supply chain, creating unnecessary bottlenecks throughout the process. The handling of these documents is error prone, time consuming, and most of all, unnecessary. Seeburger’s innovative approach to ensuring “total supply chain integration” has brought about an exciting new “Paper-to-ERP” module that is providing new efficiencies and real-world benefits to an organization. This is most certainly an area that will gather great interest in the years to come, so be sure your solution caters to (or at least has a strategy for) this requirement.

• SMTP Mail Forms When you work with workflow, you will soon realize that the acceptance and compliance depends highly on the way work items are treated. What most people like to see is receiving an email that presents the necessary information, allowing clicking on a possible choice, or filling out some missing information in a form, should this be required. So, it comes in handy that we found a solution within Seeburger that creates the necessary SMTP messages and handles the matching results automatically. So Seeburger comes to the party here (as well) with a solution called “Business Mail”, that combines the high availability of email with the flexibility of XML. It gives smaller suppliers the ability, for example, to process and submit delivery notes, invoices, etc., all via the simple mail interface.

5 Conclusion The dynamic world is here, and it’s here to stay! The topic of integration has slowly but surely moved its way steadily up the priority list of organizations, as both business and IT people are now getting a better understanding on how it can deliver true value. Once purely looked upon as "just another technology", integration has now become a strategic priority.

The new service-oriented enterprise (SOA) - or Enterprise Service Architecture (ESA) as SAP names it - has dawned and is set to provide organizations with the platform they require to create on-demand, agile, and cost effective business applications and processes. Companies failing to take advantage of the SOA paradigm will find themselves with multiple integration “silos” as they try to adjust to the dynamic marketplace in years to come.

Probably the most crucial aspect of SOA is the fundamental shift in thinking, for both management and IT. Integration projects, in the future, will be viewed as enterprise-wide strategic activities, rather than “technical initiatives”. “Failing to plan is planning to fail” has never been more true than in today’s integration world. SOA is a strategic journey that will require the continuous approval and support from IT and management. SOA will prove to be one of the key technology providers that give decision makers the ability to continually optimize business processes and be able to quickly discover market opportunities and threats in real-time.

The EAI solution your company chooses will become entrenched within the company integration culture and strategy, and it will be very difficult to replace. For a successful


www.SAPtips.com



integration deployment, you must ensure that your corporate integration strategy, business processes, integration architecture, and stakeholders are all fully unified and talking the same language. Companies failing to pursue one consolidated solution will eventually end up with multiple integration "silos", as they try to adjust to an agile marketplace.

Parts I and II of this series guided you through where we are in integration today, and how to go about changing your mindset for the future. Key aspects to consider were highlighted when analyzing an EAI product. The ability for a company to use the correct blend of technologies and innovative ideas will be the spark that ignites the EAI solution, extending into parts of the supply chain that they never thought possible!

6 After Hours Chat Room Editor’s Note: In this section, our tireless EAI reporters share the results of an online conversation on major EAI points not covered in this article.

Lynton: “Axel, you’ve been in the EAI game for many years now and have a great mind for separating “hype” from reality. Many large organizations out there have some sort of “business process management”(BPM) strategy in place (albeit often only exercised loosely related to practice using a product like ARIS or Visio). The aim eventually is to have some sort of solid “drill down” capability from “high level” business process models right down to the transaction level workflows in a product like SAP XI or Seeburger. This will give managers a real-time view of the organization. With standards like BPEL showing so much potential and with companies like SAP and IDS-Scheer forming solid “BPM partnerships” do you think we will be able to view processes “end-to-end” in the near future? I mean surely the fact that both SAP XI and Seeburger are fully BPEL compliant is a great sign for integrating into other “higher level” process products like ARIS? Do you think this will provide great value to business?”

Axel: “Those are actually many questions at once. What I can say with certainty is, that BPEL will add great value to business. Simply because it provides something that is the basis of every progress in the history of mankind: BPEL provides for a common and unique language! But one should not ignore that BPEL by itself is only a common language that describes workflows. Currently BPEL is mainly used to tie up external processes. The results are workflows or “meta-transactions”… actually it widens the area that xApps were meant to occupy.”

“BPEL will only unfold its true value in combination with BPML, the Business Process Modeling Language. BPML will actually be the first widely accepted language for business ontologies. This will indeed give an end to the time-consuming and fruitless disputes that usually are fed only by different interpretation of terms or an imprecise vision of the actual model used.”

“If we manage to use BPEL to design the internal flows of a transaction then we shall have a real breakthrough, mainly in terms of quality and transparency of application development. “

“It has not been decided whether BPEL will be success or not. If the Open Source community won’t adopt both BPEL and BPML as their child, it will remain an insular solution. I have always had the picture of ADA in mind. ADA is the programming language that actually has nearly everything that we have today, it is Delphi, Java and ABAP combined in a clever design. But there were never really cheap or at least affordable compilers available. So ADA stayed in a niche and still waits there like the Sleeping Beauty, but no prince will wake her up again.”

“The tools that will soon be available to model BPEL and BPML will certainly aid in bringing a better and quicker understanding of business processes. However, this will only work when the tools come free of charge and out of the open source community. If the tools are sold they will reach the elites and some little corner in an enterprise where they produce documentation all day. But the results won’t be accepted or even known by the people who actually need to know them:


www.SAPtips.com



the developers and design architects. So, only if the BPEL tools will all be free, then the developers will start designing their work in BPEL first and then start coding it. UML is suffering this fate currently. UML is interesting and Rational Rose is a great product, but who actually uses it? In times of restricted budgets, you’ll probably invest it in another RAM memory stick rather.”

Lynton: “You’ve mentioned “dashboards and cockpits” numerous times in the text. Most EAI vendors out there have great technical monitoring for their own products but that seems to be where it ends. What to see as the future for “dashboards and cockpits”? The only way I can really see a company getting exactly what they want is by creating a custom dashboard or cockpit themselves using .NET or something similar? What’s your take on the “Business Activity Monitoring” scene and what do you think the future holds in this space?”

Axel: “I think, as always, you carried the answer in your question already. BAM must be agile and highly adaptable to business needs. There are many toolboxes out there that at least are full of nice gadgets and visual gags like graphical instruments, charting aids and statistical formulae. They will at least take away the tedious efforts of having to develop all the “salt and pepper” parts of an application yourself.”

“I see the real problem in the applications. Most apps won’t actually provide appropriate interfaces for BAM. In mechanical engineering it is good practice that any machinery will provide plugs where one can insert a probe whenever needed. Software applications need such measurement points as well. Could be an area to enhance BPEL or WSDL, just a thought.”

Lynton: “There are many great books out there like “Enterprise Integration Patterns” (by Gregor Hohpe and Bobby Woolf) that seem to totally speak on building and deploying “custom written” messaging solutions. They speak of message channels, message routing, and message transformation etc (basically the things that a typical EAI product should provide for). With SOA and the ESB becoming so popular these days do you ever foresee a time when most of the mapping, transformation and routing will be done using re-usable services deployed on the ESB that merely interact with other services in an orchestrated scenario? How should we read into books like “Enterprise Integration Patterns”? Where will applications and patterns like the ones shown in the book fit into the bigger scheme of things?”

Axel: “That is indeed the nature of a pattern: that you can write an abstract framework, a “master template” that describes and implements the pattern. From this master pattern one can derive the instance and give this instance a special flavour.”

“The ESA tools are actually the ones that are challenged here to act. 4 out of 5 queue actions can certainly be modeled as an abstract pattern. The ESA market is tough and crowded. Here lies a wonderful market chance: I think, the vendor that comes fully quipped with most important patterns first, will make a big step forward. It is like with SAP. While everyone was selling database engines, SAP decided to deliver what nobody had in the portfolio but every customer needed so badly: content for the database!”

Lynton: “You’ve been involved in many EAI projects over the years. You seem to be the number one person people call when their EAI projects are failing. What, in your experience, are the main reasons why many EAI projects fail?”

Axel: “Communication. They all lack of communication. Many projects think that EAI (or EDI) can be solved by someone making a design and someone else implementing it. But EAI means that different people, different departments, different companies have to come to a decision. This won’t happen if only done via email or some telephone calls. It only works when people sit together very often and discuss all problems in person. I see projects, where I write an email to get a contact to a key person. He or she replies three days later, forgetting to give me an answer or their telephone number. When I manage to arrange a meeting after two weeks it then turns out


www.SAPtips.com



that the person with the key to information is located somewhere at the other end of the continent … and the game begins all over again.”

“To implement EAI there is no tool, no project strategy that helps. It is as simple as this: the developers have to sit next to each other, talking to each other and have the possibility to look over each others shoulders. Basically, an EAI project can only function when very key people– from manager to developer – will be able to understand the work of any other person in the task force.”

Lynton: “How do xApps actually fit into an ESA scenario?”

Axel: “We need to have a closer look as to what xApps actually are. They are what we used to call “meta transactions” or “composite transactions”. They are basically applications that call several transactions in sequence. So we need to think twice in order to find out exactly how ESA tackles such composite applications. And the answer is as simple as this: BPEL is designed as the unified language to describe such composite applications.”

Lynton: “You are familiar with writers and speakers like Tom Peters, Tom de Marco and Paul Graham. You have just got Tom Peters new book “Re-Imagine! Business Excellence in a Disruptive Age”. You also seem to be able to predict and philosophize about the future very well. In a nutshell where to you think the world of business and IT is going? “Change” and “innovation” seem to be the name of the game these days. What’s your take on this and how do you see companies wanting to cut budgets more and more surviving in the future? There has to be a balance somewhere?

Axel: Thank you for the flowers but the secret of seeing the future is mainly to look with wide open eyes and ears into the past. Graham, deMarco, Peters or Ed Yourdan, they basically teach the same lesson, because they simply speak out what is obvious. He that has eyes to see, let him see and he who has ears to hear, let him hear…. The true problem in the business is the same as always: people jumping on hypes instead of trusting their own judgment. Managers are more afraid of doing a wrong step instead of seeing the potentials. They follow the masses and in their vanity they forget that they behave like the Emperor of Andersen’s Emperor’s New Clothes or a Don Quixote.

Change and innovation have always been the drivers of success. “Change” is a synonym of life, change is not something you want, it happens to you. And innovation is the criterion that makes a business superior to another.

But everything what we see happen today in IT happened in similar fashion before. It is most obvious when you look at the ongoing fight of the frameworks. The arguments exchanged in favor or against Java are widely the same we have heard many years ago when PASCAL was fighting against C. And the argument is just as meaningless as they have been back then. Here is also a very positive trend towards using design patterns. An expression that became popular with Java. But it is less positive that it only demonstrates that it had been forgotten for long time that patterns have always been the foundation of application development, but I learned it when it was called “Algorithm and Datastructure”. The book with the same name by PASCAL (and computer mouse) inventor Professor Niklas Wirth and Donald’s Knuth “The Art of Computer Programming” are a must read for developers but seem to be forgotten by the Java generation.

The secrets of success in IT are working and customer oriented programs, ready to use applications. SAP’s success began as they started to write programs for databases while the rest of the world was designing ever better database engines. But a database without data is like streets without vehicles. We are facing the same situation now: it doesn’t matter whether we run J2EE, ABAP or .NET as long there are powerful programs that run it. They are often referred to as killer applications. EXCEL has been such a killer application for Windows.


www.SAPtips.com



And we now see the likewise development when we speak of middleware. There are hundreds of middleware programs out there on the market. In my opinion there are all equal: equally poor! They can do more or less well all the basic feature like message storage, mappings and workflow management. But there is hardly anyone that delivers prêt-a-porter solutions for integration brokers. There are many repetitive tasks that have to been developed over and over again in every project, in every company. Think of the “nervous-finger-syndrome”, when someone submits his credit card information through a web site and clicks the submit button several times. You don’t want to think of the hassle your accountants have if they need to rollback all the erroneous credit card charges. A good queue can easily implement such a pattern.

And here we see the answer of producing quality with lower budgets and where the future will move to: standard reusable applications written for the ESB. BPEL seem to have the potential to drive this development for the business process design.

And where will IT go? We will reap the benefit of the internet revolution, something that changed our life just like Gutenberg’s invention did. The easier corporations can communicate with each other the more the standardization from bottom up (not dictated by organizations like ANSI etc.) will make progress. It will be these companies that cannot react on change – again change happens – who will end up in the defensive. The customer will conquer back his terrain and the vendors that stick to proprietary solutions will disappear. Windows has always been open, the IBM business model has always been based on ISV and SAP learned this lesson, NetWeaver is open. The trend will be to reuse agile components from many different vendors that collaborate.

Lynton: And how will ERP look like in 10 years time? Axel: Instead of having one heavy ERP monster like R/3, we will have hundreds of small independent components, any little R/3s if you want, that collaborate transparently like people collaborate between offices within a corporation.

Axel Angeli, logosworld.com. Axel is a senior SAP and EAI advisor and principal of logosworld.com, a German-based enterprise specializing in coaching SAP and EAI project teams and advising IT management on implementation issues. Axel has been in the IT business since 1984, and throughout his career, he has always worked with cutting edge technologies. Axel's SAP experience stems from the good old R/2 days, and he is an expert on SAP’s NetWeaver technology and any kind of ABAP development. A speaker of several languages, Axel specializes in coaching and leading large multi-national teams on complex projects with heterogeneous platforms and international rollouts. Known for his intensive and successful trouble-shooting experience, Axel has been nicknamed by his colleagues as the “Red Adair” of SAP projects. He is the author of the best-selling tutorial “The SAP R/3 Guide to EDI, IDocs, ALE and Interfaces.” Lynton Grice is an application developer contracted to one of the big automotive companies in South Africa. He has a passion for programming and new technologies and takes care of SAP Portal development as well as other SAP EAI requirements. Coming from a typical Java school, he is now just as familiar with ABAP. Lynton’s email address is [email protected]

mailto:[email protected]

http://www.logosworld.com


www.SAPtips.com



The information in our publications and on our Website is the copyrighted work of Klee Associates, Inc. and is owned by Klee Associates, Inc. NO WARRANTY: This documentation is delivered as is, and Klee Associates, Inc. makes no warranty as to its accuracy or use. Any use of this documentation is at the risk of the user. Although we make every good faith effort to ensure accuracy, this document may include technical or other inaccuracies or typographical errors. Klee Associates, Inc. reserves the right to make changes without prior notice. NO AFFILIATION: Klee Associates, Inc. and this publication are not affiliated with or endorsed by SAP AG. SAP AG software referenced on this site is furnished under license agreements between SAP AG and its customers and can be used only within the terms of such agreements. SAP AG and mySAP are registered trademarks of SAP AG. All other company and product names used herein may be trademarks or registered trademarks of their respective owners.

side-stepping the labyrinth - part ii -...

Documents