A Matter of Perspective
At Open Sky Group, we have a strong culture of sharing knowledge, experience, and ideas openly and freely. A topic got started from one of our consultants needing ideas on how to keep systems integration costs (and effort) to a minimum for a rapid implementation (or in our world, a normal project).
Two of our people jumped in and offered their experience and wisdom. What makes it interesting is that these people came from different ends of the project team; one response was from a program manager’s point of view and the other from a developer. Let’s look at the different points of view (POV) and see if, or where, they intersect.
Systems integration recommendations from the Program Manager
- If at all possible, use a file/message format that is already in production for the client vs. using a new one.
- Use current standard specifications for transactions and avoid customizations as much as possible; development of standard specifications is generally less costly than custom specifications.
- Ensure data requirements are completely defined prior to any development activities. Conduct a walk-through with the teams on both sides of the interfaces to get all questions raised and to make sure there is a complete understanding of what each field, segment, etc. means to each application.
- Ensure the specification format will support correct data flow into the database tables and SQL in downstream processes to avoid redesigns or transformations. For example, if you know your WMS needs an Order Sub Line Number in addition to Order Number, be sure to address this in the up-front design rather than flush it out during development or testing. In other words, make sure application experts are participating in the mapping exercises on both sides of the interface.
- Do not take shortcuts during testing. Go through the full test cycle-unit, end-to-end, user acceptance training to ensure data integrity and scope completeness.
- Document all design and business requirements to help ensure that systems integration/implementation processes do the right tasks correctly the first time, translating to money and time savings.
- Use application tools to automate the QA to Production transition workflows and expedite system integration, reduce time to market and reduce the overall cost of ownership.
The Program Manager’s perspective in summary
The Program Manager is focused on either reusing existing transactions currently in production or using standard interface specifications when possible, paying proper attention to design, and doing complete and thorough testing. Also interesting that the Program Manager wanted to make sure the tools allow for good promotion from QA to Production and emphasized documentation of what was done.
Systems integration recommendations from the Developer
Some brief thoughts on the Developer’s systems integration experience over the last couple of decades:
- 60% of systems integration is simply reformatting data from one form to another
- 30% is reliably sending or receiving data to/from another system
- 10% of systems integration is other stuff (like knowing when to send transactions, etc.)
The must-haves for any good systems integration mechanism include:
Transaction/data logging – Interface points between systems are always breeding spots for finger-pointing so being able to authoritatively say what was sent when, at any given time, turns a potential disaster into good client relationships. Because of this one ability, we’ve wound up telling clients what was wrong with their transaction sets and have been a de facto testbed for them.
Easy to understand error messages/logging – If something is rejected, being able to diagnose why easily saves time and earns client appreciation.
Single monitoring point<form>/active alerting – Having a quick way to ensure everything is running smoothly reduces the hassle and builds confidence. And if something is detected, you may be able to correct the issue before it impacts production (if production is not affected, then it wasn’t a problem).
The Developer’s perspective in summary
The Developer is focused on the robustness of the interfaces and the ability to log and troubleshoot issues, as well as easily identify failed transactions for systems integration.
There’s magic in both POVs
I’m not surprised at these answers – are you? The Program Manager is clearly concerned with staying in scope and on time and on budget. The Developer is clearly concerned with having a solution he can live with. Both side’s objectives can be satisfied. The magic lies in taking the goals from both POVs into consideration during planning when you are ready to build systems integrations.