Integration Project Challenges – Part 1

As business software systems become more complex, integration projects meant to utilize their capabilities outside of the contained application tend to become very challenging.  This is especially true in the SaaS (Software as a Service) world where a company has exposed software application services or functionality for other organizations (partners) to use while to the benefit of both parties.  Re-coding internal capabilities for external consumption produces a new revenue stream that otherwise may not exist, but poses design and implementation challenges that are often unforeseen.  Here are just some of these:

  • Timeline/Deadline ( coordination of efforts by additional external development teams )
  • Technical Design ( technology stacks and implementation may be vastly different )
  • Behavior ( similar to Technical Design challenge, when back-end systems may require a much different business model than the calling applications )
  • Initial development costs vs. long term revenue stream

Its fairly normal that all of these above challenges are present in enterprise integration projects together.  In order to overcome them and move forward, a team of people should be formed that have a unique set of skills at the onset of the opportunity to lay out these challenges and discuss the overall plan. Here are some guidelines for each challenge:

Timeline/Deadline – always include a 200% time overhead for team coordination between integration partners.  Regular weekly integration meetings need to be scheduled ( in person or on the phone ) to discuss technical designs/implementation details, the overall schedule and how each partner is tracking toward it need to be an agenda item for every meeting.  Realistic deadlines need to be agreed upon with very clear goals that are documented.   Any “blockers” toward progress need to be immediately highlighted and shared so that partners are aware of dependencies.

Technical Design – another typical scenario is that system integration is going connect heterogeneous systems.  For example, a Microsoft .Net based application will then reach out and connect with a Java/WebSphere based service provider and maintain this connection 24×7 for the foreseeable future. When partners realize that this will occur, it is a best practice to train, hire or contract with an engineer or team that is familiar with inter-connectivity between the systems.  Smooth and dependable communications between systems will be paramount to the success of the project.  Do not leave connectivity to the end of the project, place that as an initial critical path task to get by early on.

Behavior – regardless of the technologies that the systems are built on, the other issue to overcome is heterogeneous behavior.  Asynchronous vs. synchronous is one such difference that can and will force additional integration coding or introduction of “connectors” or “adapters” to smooth out communication.  Batch vs. Real-time is another example, that would force significant changes on one side of the integration or the other.

Initial Development Costs vs Long Term Revenue – more often than not, partner integrations are agreed to in order to gain access to previously unrecognized revenue streams or capabilities.  However, developing and rolling out integration projects may end up being extremely expensive and time consuming.   A full technical due-diligence is required during the initial negotiations and stages of the project to understand what the upfront costs will be.  Partners will frequently down-play their own efforts because they are very familiar with their own functionality and underestimate what it takes to incur change and integrate to another system.

For more information regarding this or other software projects, please contact us with your inquiry.

Leave a Reply