Hard Thing

Hardest : 3rd party system integration

This is the first part of explanation from Hardest : back end enterprise system development article. In this post we will dig down about how hard is it to use 3rd party system into our system.

3rd party system can be either using hardware with drivers, plug ins, or different programming tools such as Microsoft BizTalk and SharePoint. Using 3rd party system in your system sometimes can be easy, or hard. But usually, it is harder than the system development itself.

Different bridging support

This is one of the hardest point in third party system integration. Talking about hardware, usually it comes with built-in driver from the same vendor. However, not every language are supported by the driver. For example, the driver library may not happen to come in python or Lisp language. In worst case, you will need to execute command prompt for bridging with the hardware.

Talking about other programming tools/system, they either provide a supporting language library, or bridging protocol such as tcp/ip, http or command prompt. Different system and different vendor provide different library and bridging method.

Different process

Even in same product type (barcode scanner for example), they can have different syntax, and even different process structure. For example: one use event-driven while the other use threading / polling and the rest use procedural result. The different process structure make it harder to abstract the driver and integrate it with your system. Sometimes it forces your system to change following the process structure.

The same happen when talking about software integration. Most of them have different process and operations. It is hard to abstract them. Moreover, usually they are not supporting transaction processing, making it harder to rollback when error happens.

System error

In some extremely rare side cases, some error can happen in the driver / library or even the component itself. It will makes it harder for the support to identify the error, and the repair will be even harder. In worst case, you need to have the vendor repair the component to even fix the problem, and no workaround can be made.

System Change

Now we get the above problems. Now in some case, the vendor is no longer sustainable and we are forced to change vendor, or the item produced is discontinued and changed with a new one. The can be very costly and time-consuming as well. Change management need to be defined in order to keep business running during the transition, and we don’t have any choice but to do it.


3rd party system integration is harder due to some limitations and lack of control over the component itself. It makes harder to develop, abstract and worse at debugging.

Edit 2015/05/28: 3rd party hardware integration’s scope is too small and is similar with 3rd party system integration. Hence the modification.

Hardest : back-end enterprise system development

What is the hardest thing during developing back-end enterprise system? As a programmer, I have experienced full cycle of building a system in a company from start until being used. Based on my experience, when I try to order them into priorities, this is how I will do it. Please note that this list is different while developing framework/foundation (maybe i’ll list them later):

  1. Handle exception and negative case
  2. Server administration (uptime, backup, re-index, disaster management)
  3. Implementation / publishing / change management
  4. Business requirement gathering
  5. System Documentation
  6. 3rd party system integration
  7. Programming

Of course the priority can be changed based on what system to develop, how good is the company / enterprise with planning the system, etc. And this list can be biased only by my experience alone. But I think the adjustment cannot be shifted very different. If you are a programmer, do you agree with the list? Why is programming / developing the code is the easiest in developing back-end enterprise system? What is my priority based on?

Edit 2015/05/28: 3rd party hardware integration’s scope is too small and is similar with 3rd party system integration. Hence the modification.