What are the business drivers and how will the project be funded and managed moving forward?A lot of integration projects cut across several different organizations either internal or external and if so, they will require cooperation and collaboration of the parties involved.

The key issues to identify are:

• Describe in 2-3 sentences why this integration project is important to the business?
• Is there a financial value associated with the success, or failure, of this project?
• Other than the financial value, what else is at stake in this project (e.g. customer satisfaction, employee retention)?
• Is there a hard-stop date by which this project must be live?
• Who owns the budget for the project, what is the budget, and when is it available?
• Other than the budget holder, who else will be involved in decision making in the project?
• How will the project be managed (project manager, team, steering committee) and who has the final say?
• How will you measure the success of this project?
• How will you handle changes in the future?
• Who will monitor and manage your solution?

Next, we look at the systems that need to be integrated and define the source and target systems.

The source system(s) provides the information that will be used to feed the target system(s) that need to use this information.

For example:

• What applications are being connected?
• What versions of these applications are being used?
• What integration options do these applications support?
• Which of these options is best suited to this project and why

In many cases, there may be only one option; in other cases, there may be several options which may have different implications on the cost and duration of the project and the level of functionality that the integration process will be able to support.

Understanding these issues is critical to the success of the project.

Information is like any product or service, it can also be coded and described in many different ways. Understanding these different ways, or formats, is important and will typically require both business and technical knowledge.

The basic questions we ask are:

• If the information is going to be exchanged as flat or text files, how will the beginning and end of fields be marked?
• If information is going to be exchanged as documents, what formats will be used?
• Do the files or documents have headers that describe their contents or do you need to figure this out from the information in the records?
• Do you have some sample file formats?

The good news is that there are a limited number of answers to these questions. If we are clear on the information formats to be used at the outset of the project; then we have taken a big step towards project success.

In any integration project we would look at how much information will be loaded in the initial load process and how much be will added, updated and deleted on a daily basis.

The volume of information that you need to integrate can have a big impact on how you design your integration processes which, in turn, can have a big impact on how much it costs to develop and run these processes.

Having defined what the project is to do, where the information is coming from and what the information looks like, we can then start to think about the integration process.

Integration processes can vary from simple processes that just move information between systems to complex business rule driven processes. For each integration process we would work with you to define:

• What type of process is this? For example: does it synchronize master files, does it update transaction files, does it load information into a reporting system?
• Does it need to map data between different record layouts?
• Does it need to transform dates, addresses or other values?
• Does it need any conditional logic? For example; if the information being integrated is a purchase order you may have a supplier that has a minimum order value and you may need to aggregate POs until this minimum is met.

Having defined the process, we now define how frequently this process needs to run and what will happen if anything goes wrong. These are areas that, in our experience, people often over-complicate.

For example, many companies think that they need integration processes that update systems instantly when a delay of a few minutes would have no business impact and might be significantly less expensive to develop, test and manage. It’s important to think through issues such as:

• Will the process run hourly, daily or weekly?
• Will it run at a certain time each day or will it be triggered when, for example, a certain of information needs to be updated, etc.?
• What happens when the integration has an error due to a network or physical failure? Who needs to know? How should they be alerted?
• What happens when the integration has an error due to bad data?
• What reporting of errors and exceptions do you need?

These issues are important to at the planning stage of an integration project.

If we get it right we will spend a few days or weeks developing the project and then the resulting integration process can run for years.

Integration is typically not static, systems change and business needs change, it’s worthwhile to think about:

• How will you support your process so that it keeps pace with these changes?
• Will you handle minor changes yourself or will you engage a third party to do them for you?
• What are the costs and skills needed to manage and monitor your integration?

We see many integration processes that work well for a few months, then a supplier changes the format of the purchase orders and the whole process has to be redeveloped.

This is one of the reasons why we simplify integration with our RIO solution, with a SaaS model you have the ability to update your integration processes quickly and easily.

For us it makes sense to break a business integration process down into several simple processes, execute on each of these steps, and then build on these successes rather than going for the traditional enterprise level integration project which may take months to develop, test and deploy.

In our experience, very few projects fail because they are too simple, but many fail because they are too complicated!

We collate the above steps into a checklist template to collect the information we need to scope a successful RIO project.

Here's a sample checklist of the first four steps for a simple process that uploads new sales orders from Salesforce.com into MYOB.