System Integration Project Best Practices - Part 1

System Integration Project Best Practices - Part 1

In this post we cover 5 best practices for system integration projects and how data governance (data intelligence) can help.  In a following post we cover 6 additional best practices.  Here are the 1st five best practices:

  1. Get started and organize the integration project
  2. Document the business requirements of the project
  3. Understand the source and target systems
  4. Build a preliminary data mapping document
  5. Make the technology decisions

StockSnap_6DB609DF59_Integration_BP-1

 

Let’s get more in-depth into the best practices:

1. Get started and organize the integration project – First of all, acknowledge that system integration is hard.  Expect that requirements will change and plan for it.  Assign an integration project manager or coordinator.  As in all projects, document the project.  Make sure that there are no unspoken assumptions or desired functionality that is unknown.  Determine what success criteria looks like such as following mapping document and finishing test cases.  Make sure all parties are working towards the same goals and are collaborating on any issues that arise.  You want to avoid finger pointing.  Make sure that everyone is aware that finding problems during testing is a good thing.  Getting organized and getting everyone on the same page is critical to project success.

2. Document the business requirements of the project - Determine what needs to move functionally. Ask many questions and document the answers. Ask why are we moving this data?  Do we need to?  Make sure that you document any current manual processes.  Determine what decisions is the user making that needs to be built into the integration logic and determine if these decisions should be automated.  Some things do make sense to have a manual review or decision.  Also document the answers to the following questions:

  • What triggers (the initiator) the move?
  • What is included in the move? (selection criteria)
  • How do you handle errors? Can you reprocess information?
  • Is there different behavior for Create and Update? And do you need duplicate resolution?
  • Are there performance (speed) requirements?
  • Can this project be done in phases? What is critical?  What can be done later?  What is nice to have?
  • What system shall be the system of record?
  • What is the depth of the data integration (usually for migrations)? Do you migrate every record from years ago or just the past few months?

There are a few things to avoid in your documenting:

  • Moving data into a transactional system as a pass-through to reporting
  • Updating the same data in two systems and wanting to synchronize
  • Postponed Perfection – we suggest continuous improvement over perfection some time in the future
3. Understand the source & target systems – Make sure that you leverage each systems business logic whenever possible. Understand create behavior and update behavior for each system as well as the error handling.

Document the fields in your source and target data systems including:

  • Objects and fields
  • Data definitions and descriptions
  • Data type and format
  • Required?
  • Expected data values

4. Build a preliminary data mapping document – This document will eventually be your final mapping document. Do a mapping for each transaction. Make sure you include functional description of source and target systems.  Think about directionality, initiation, translations and substitutions.  Make sure you determine the default data.  And add narrative for complicated logic such as if then else logic even if not sure what it is.  Make a stab at it. 

5. Make the technology decisions – Determine what architecture and tools will be used for the integration. Also decide if you need any interim systems such as an Enterprise Service Bus (ESB) or custom code. Think about the processes that will be automated and scheduled.  And how will notifications and monitoring be handled.  Remember that there is a source system, intermediate processing component and a target system to worry about.

An integration project is not easy.   It has many components.  It has many cases that can occur.  It involves many individuals (and often many departments).  Therefore, it is critical to integration project success that best practices be followed.  We hope that the few mentioned here do help you.  In another post we provide more best practices.  Also view our video on the 1st 5 best practices.  Also check out our other integration resources in this blog post.  Get additional resources regarding linking data governance with technology projects in this blog post.

IData is expert in integrating higher education data systems including ERPs, SISs, CRMs and financial solutions.  We have connectors and our IDataHub enterprise service bus that makes integration easy.  IData also has experts that can assist with data governance, reporting and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.

 Contact Us

(image credit StockSnap_6DB609DF59_Integration_BP-1 #1088)

Jim Walery
About the Author

Jim Walery is a marketing professional who has been providing marketing services to technology companies for over 20 years and specifically those in higher education since 2010. Jim assists in getting the word out about the community via a variety of channels. Jim is knowledgeable in social media, blogging, collateral creation and website content. He is Inbound Marketing certified by HubSpot. Jim holds a B.A. from University of California, Irvine and a M.A. from Webster University. Jim can be reached at jwalery[at]idatainc.com.

Subscribe to Email Updates

Recent Posts

Categories