|
The Art of 3rd party integrations |
|
Written by Brian Austin
|
|
Tuesday, 24 February 2009 |
|
3rd party integrations require a lot of skill, finesse and diplomacy if
they are going to be successful. I recently had the opportunity to
spearhead the development effort at my company with a OEM lead provider
integration. Depending on the development shop you may find yourself with
either a very rigid process or a more loosely defined experience. In
either situation communication is the key to success.
If you find yourself in a loosely defined process like I did then you may
have to deal with adjustments to your code as well as the providers. If
the process is especially new you will likely uncover bugs or flaws in the
process which need to be corrected. With this in mind it's far better to
keep development iterative and to communicate and address issues in a
timely manner.
On the other hand if you find yourself in a very rigid design process
you'll most likely be provided with a firm data spec which is relatively
concrete as well as a series of test cases to qualify your integration.
In this case you'll need to iron out any potential issues upfront and to
fully complete your design before coding. In most cases you'll want to
code to the test, but also analyze your own system for any potential
bottlenecks or choke points which could create and issue during
testing.
In the end, regardless of which type of integration you use you'll want
to include numerous methods of feedback to provide monitoring and quality
of service assurance after deployment. I've found that it's often
beneficial to enable debugging or verbose monitoring during the initial
deployment as well as when unforeseen issues are encountered.
|