Keys to Successful Integration

When you install a new application, there is often the need to connect it to upstream and downstream systems, eventually.  Integration is the key to real process improvement.  How can you pull off this task successfully using time-tested best practices?

A system that works in isolation limits its value to the business if it cannot hand off information from one business function to another.  For example, the contract management system should be tied to the payment systems.  The procurement system needs to be tied to the general ledger.  To give a packaged software example, Oracle CM should be connected to Primavera P6 and your ERP system.

Project Kickoff

Exactly how do you start a systems integration project? Every project needs a champion, someone at the senior management or executive level to sponsor the project and provide oversight.  Such a person has the authority to effect change across the organization, which is something the departmental manager cannot do alone.

Once you have a champion, you need to organize a steering committee.  The committee brings together all the impacted parties and internal and external customers.  These people will agree on project scope and make a project plan outlining the required resources and milestones.  It is important at this point to write a project statement answering these questions:

• What is the business driver for the integration?
• Are the expected results and success criteria clear?
• Are the developers able to do this in stages or is it an all or nothing endeavor?
• What are the potential integration points being considered?
• Can the two systems be integrated?

The steering committee should develop a RACI matrix.  This is made up of four areas: responsibility, approve, consult, and inform.  The Responsible party is, who is assigned to the task.  The Approver is also accountable for the task; they sign off on its completion.   The Consultant is the one whose input will be needed at times.  For example, they could outline a realistic scenario for the testers to include in their functional test or give opinion and insight into company practices with which IT people might not be familiar.  Informed is your steering committee, internal customers, and affected parties.  For example, you will need to work with the people who run the contract management system if you are connecting the financials to that.

Now a project manager is appointed plus someone to oversee the project.  A strong project lead is needed to drive the project.   This is not the project manager.  The project manager tracks milestones and progress and can be part time on the project.  The project lead is someone with a strong personality that can drive issues to resolution and make sure that development is tied to requirements.  This person is able to do battle with any vested interests who could cause any delay in the project and keep the project on track, so that costs do not get out of control.

The project lead and project managers determine what resources to bring onboard and when.  That would include the system architect, developers, and part-time or full-time testing resources and part-time business subject matter experts.

Types of Integration

There are two types of integrations:  (1) those for which the packaged applications, such as Oracle ERP, have built-in tools for integration, such as a web services, bulk data loaders, and messaging and (2) those for which a custom interface must be built.

Built-in tools are preferred over writing custom code.  Built-in tools comes with vendor support.  Custom software by definition does not.  Custom software raises the issue of how to keep the interface running months or years after the project has gone live, and the developer who wrote it is long-gone from the company.  This creates risk for long-term support of the project.  During project development, this creates additional complexity due to the effort to architect and program something that works with the packaged software.

If a custom interface must be built, is best to adopt a common approach and a common tool, like LoadSpring’s SpringBoard 7.0, rather than write code from scratch.  Such a middleware-type tool would provide the current project with a vendor-supported solution and allow future projects to use the same tool, thus mitigating the need to write custom code, reducing risk and support issues for other projects down the road, and boosting the ROI from purchasing something like LoadSpring.

Build Out Environment

You need a place to work.  It is necessary to build out at a minimum the following three environments:

Development—this is the environment where developers can write code to send data to mockups of or development versions of the systems targeted for integration.  The code written here will more than likely will not work 100% with any development copy of the targeted system, because that system is already in production, and no development team is maintaining a development environment for that.  For this reason the developers need to mock up the targeted environment by, for example, sending out messages and data files in a simulated fashion.  This environment includes configuration management software, so that software changes can be checked in and checked out of the code base.  Developers do unit testing here, but not the integration.

Test—this environment has a working copy of the targeted system.  For example, if you are integrating with JD Edwards, then a test version of JD Edwards is running in this environment.  Testers run integration tests here.  This environment also has the ability to work as a volume test environment, unless you also have an environment dedicated for that.  The test environment can be erased and rebuilt using the same deployment technique that will be used to push the integration software to production.  The test environment can be rolled back to a point in time when it was last working.  Building the test environment should be started before any code is ready to be installed there, because there you will need a working copy of the targeted system installed here with good test data, so you need resources from that team.  Plus there are the inevitable infrastructure issues, like networking, that will need to be addressed.  It is best to do that up-front rather than be delayed later.

Production—SOX rules dictate that there is a separation between development and production.  That is useful to know, because production support and operations teams exist to deploy software to production.  They know to tread lightly in order to avoid breaking anything.  It is necessary to schedule changes to production in a scheduled downtime window.  There must be a procedure in place to roll back any changes and restore the system to the state it was in should the integration fail deployment testing.  If the integration involves mission critical applications, there is the need to rehearse the final deployment with operations in a conference-room walkthrough.

Optionally there could be a sandbox and a break-fix environment.  In the sandbox there are no rules.  Developers are free to make changes without any change-management process.  Break-fix could also be called P-1, meaning an environment that is the same as production, with production data and a working copy of the targeted systems.  This lets developers fix production bugs in a system that is the same as production.  In the absence of a break-fix environment, there is no place to work on production bugs, because the test environment is carrying forward the next release—so the two systems are not the same.  The mission critical ERP system should have a break-fix environment.  That means once your integration is deployed to production you will have a place to fix bugs.

These are the crucial keys to successfully integrating systems.  It is important to have executive oversight, a steering committee, strong project management, adequate resources, proper planning, and solid communications.

Now that you know what to do, review what not to do. Read our thought-provoking blog, “The Top 5 Reasons for Failed Software Implementations” and be informed on how to avoid these pitfalls. All other questions can be answered by our ready and willing sales and support team. Call them today at +1 978.685.9715.