Integrations with 3d party systems: what not to forget

I am leading integration projects recently, so decided to look for best practices of what must be done/clarified to make integration successfull.

Accidentally i was given a book to read – Software Requirement Patterns (Best Practices) by Stephen Withall

In Chapter 5 there is an overview of what is important for integration projects.

All integrations have following main issues:
– systems cooperation might be time-consuming and unpredictable undertaking
– interfaces for other systems might be very complex
– if external inteface is used, it might not do exactly what we want or might work as we expected
– if we are developing own interface, we become dependent on other system to implement it properly
– and of course testing becomes more complicated, since not all problems are identified so easily (communication, technical and other issues)
– all upper issues become even more difficult to manage if both sides are working on integration at the same time

To manage integration more successfully we should define requirements for inter-system interface this way.

Interface requirement
1. Interface name – meaningfull name
2. Interface ID – unique number within the scope of the system
3. The system at each end – it might be that the same interfacw might appear more than once, so it needs to be explained
4. Interface purpose – self describing 🙂
5. Interface owner – describes which organisation is responsible for a certain interface
6. Technology to be used for interface

Extra interface requirements
Individual types of interaction; Throughput; Scalability; Extendability; Availability; Traffic verification and recording; Upgrading; Security; Documentation

Considerations for Testing
1. Explicit interaction requirements
2. Implicit interactions, which help to satisfy goals stated indirectly (f.ex. security requirements might involve additional kinds of interactions)