Fiorano Logo  
     Fiorano Login 
Architecture Center
Fiorano ESB™
Introduction
Business
Requirements
Business Advantages
Architecture
FioranoMQ®
Introduction
JMS Communication
Models
Key Features of
FioranoMQ®
FioranoMQ® System
Architectures
Interoperability
J2EE
.NET
XML
Web Services

Developers


EAI Best Practices  

Best Practices for Successful EAI


Are you on the hook to execute your company's grand integration vision? You should probably be aware that when it comes to EAI projects, it takes more than the right technology to succeed. Despite the many credible products on the market, success and failure often rest on the project team's ability to plan, construct and deploy the solution effectively. In my book "Integrating Your eBusiness Enterprise," I cover a number of practices and tips for a successful EAI project. In this article, I'd like to share a few of those essential practices with you.


Best Practice #1: Building with Deployment in Mind

In the early stages of an EAI project, the focus is often oriented toward technology selection. This isn't altogether surprising, given that comparison of EAI technology can be complex, dominating the project team's time and attention. However, it is vital to keep the end goal in mind--deployment. In a sense, the EAI isn't real to the rest of the company until a solution is deployed. Yet, often, key deployment issues are ignored in the design and construction phases of the project. Here are four ways to actively address deployment in your solution:


Instrument components for monitoring. Primary system components should be instrumented for monitoring. These include the ability to provide information on the availability of the system as well as other metrics such as CPU utilization, memory utilization or open resource connections. This information is vital for systems administrators to tune the system for optimal performance. It also affords the development team detailed knowledge of how the system performs in a production scenario.

Account for installations and updates. Any deployed solution must account not only for the initial installation but also for ongoing updates to system components. In some deployments, updates to integration rules and components such as adapters may prove to be a regular activity. The ability to install and update without the loss of continuous operations is essential once the system is in production.

Establish service level agreements. Service level agreements (SLAs) should be established and articulated well before deployment. In fact, they should be articulated as part of the requirements process. The SLA defines the system's requirements at run-time with regard to availability, resource consumption and system performance characteristics.

Build a deployment plan upfront. Building a deployment plan before a single line of code is written is a way to ensure that deployment issues surface earlier rather than later. A deployment plan should walk through how each phase of deployment will be enacted. It needs to articulate all the necessary activities required to support deployment and ongoing maintenance of the solution. It should include coverage of installation, documentation, technical training and the timing of the deployment.


Best Practice #2: Profile Performance Early and Often

Unfortunately, many EAI projects fail because of performance issues discovered at the point of deployment. Performance profiling is aimed at correcting this. Profiling system performance should be a practice conducted at key points throughout the development process. Measuring and analyzing system performance carries two primary benefits.

First, it is far less costly to correct performance issues and bottlenecks early in the development life cycle. This is particularly true if the performance issues are related to a design flaw. Addressing fundamental design issues during or after the initial deployment is very expensive.

Second, discovering the root of a performance problem after the entire system has been constructed can be extremely challenging from a technical perspective. You are often limited by the scope of what can be observed, and this in turn is a result of the tracing and auditing facilities built into the system. It can also be influenced by many more variables, such as network traffic. Instead, by testing not only the individual components as they are constructed but also the baseline architecture, you can establish a more granular view of system performance.

Discovering and resolving performance limitations early is simply easier and leads to better results at the end of the project.


Best Practice #3: Build a Traceable System

One overlooked aspect of EAI is the challenge of run-time debugging. Detecting problems in distributed integration architectures is extremely tricky and requires that the system be instrumented with tracing code. Tracing code allows you to track the progress of data and the execution of code segments as that data is processed.

Often, in an effort to meet the project schedule, the time allotted to building in tracing code is eliminated in preference for functionality. Whether you are constructing your own EAI system from scratch or leveraging a product to implement an EAI solution, you need to ensure that the system is traceable.

The reality is that no matter how much testing is conducted in the lab environment, some problems inevitably arise only in production scenarios. The introduction of "live" data coupled with production application usage often results in extending the system in ways that are not possible to duplicate in the test lab. When such problems are discovered at run-time--or sometimes even when production deployment is under way--it becomes difficult to fix them without being able to trace the flow and execution of the EAI solution.

Also bear in mind that levels of traceability need to be defined, since tracing can hurt overall system performance. It helps to set a low tracing option initially as you debug the system.


Best Practice #4: Reviewing and Addressing Secondary Scenarios

Secondary scenarios arise when the flow of data is not completed within the expected course of execution. For instance, the scenario depicted in Figure 1 below provides a context to discuss a secondary scenario. The integration flow can be understood in four steps:


A customer searches for a product online, entering product data into the corporate Web site.
The data is used to look up more information from a product catalog database.
Rules combining product catalog data and customer info are applied.
An entry is made into the Siebel CRM application about informing the sales staff of a customer's status.

Figure 1: Example of an EAI Secondary Scenario

However, what if the database is busy processing other operations and the request for customer data times out? How does the system handle a failed retrieval or a returned error? This is an obvious but common secondary scenario.

Another scenario may occur if, in the course of executing the rules in step 3, the server goes down. How does the system deal with an integration flow halted in midprocess as a result of failure at one point?

The number of secondary scenarios for a given system is seemingly infinite. Practically speaking, it is not possible to address every one of them. However, a regular practice of conducting reviews of possible secondary scenarios--documenting and subsequently addressing them--must be an essential practice.

An EAI solution that addresses secondary scenarios will adhere to certain principles of behavior:


Message preservation. The system should never lose data in the event of a system failure.
Data integrity. In the event of a system failure, the system should always preserve the integrity of the message.
Predefined exception handling. Failed operations must have a predefined course of execution.

Graceful exits. Operations that fail because of unavailable resources or errors should always "exit gracefully" and return to a known state. Failure should never leave the data flow in an undetermined state whereby data is not reliable and the corrective course of action is unknown.


Conclusion

The reality is that many EAI projects are delivered late and over budget. Certainly, a significant factor is vendors promising more than the product can actually deliver. However, it is possible to reduce the exposure to failure and increase the likelihood for success by following a few sound project management practices. EAI best practices are distinct in being specifically oriented to integration projects, and they offer practical advice for the EAI practitioner.

The best practices discussed in this article can serve as a starter list of steps to take. Continue to discover what works for you and share them with me. I look forward to hearing from you.


About the Author

Andre Yee is the vice president of engineering for NFR Security and a member of ebizQ's conferenceQ faculty. He is a frequent conference speaker and a noted author on various enterprise technologies, including security. His recent book, "Integrating Your eBusiness Enterprise," describes enterprise integration technologies and practices. Yee can be reached at andreyee@aol.com.

 



© Fiorano Software Technologies P Ltd. All Rights Reserved. Privacy Statement |Terms of Use
  Site Developed & Maintained by Fiorano Webteam.


 World Wide Support
 USA
:
+1-408-354-3210
 INDIA
:
+91 80 4017-0000
 UK
:
+44(0) 19328 95005