Integration Analysts Role

[Ray Mullen]

😕

Hi All,

I am looking for some feedback, i currently work as integration analyst, you all know the tasks, programming, writing translates setting up interfaces e.t.c..

We have 2 departments here and one department would be responsible for looking after the API’s installing , stopping and starting e.t.c. . I am not granted access to any of the API’s that the interface engine connects to and if there is a problem with any of them e.g , if they need user intervention it has to be a call to a different department to sort the problem. There can be an argument that it takes resonsibility away from myself but it can also be frustrating if an interface goes down for some apparant reason and the only way to reconnect a thread for example is to stop the api service to reconnect. In this scenario a call has to made to the other department to sort the problem and it can take time, which may  be critical. A lot of my development work is done on a completely seperate network and mirrors our live environment and still the same rules apply. It can be more frustrating on test environment because APIS need to be brought up and down a lot when testing. I was just wondering are other integration analysts in the same situation or is it normal practice to give the integration analyst acesss to the  API’S.

Any feedback would be greatly appreciated

Thanks Everyone.

Topic

[David Harrison]

Ray,

This kind of scenario is all too common in the NHS, although in my organisation I do have access to all systems for stopping and starting interfaces. I insist on this access when I get involved with new integration projects.

In your case it may be worth raising the issue with your manager. It

[Michael Lacriola]

Wow (Our new slogan here at CDH, “Warm, Open, Welcome”)

At CDH, we have access to most of the start/stop processes of interfaces on remote systems. There are few that we don’t, some we just won’t touch because of complexity with multiple servers involved (like Dictaphone). Some of the basic reasons why we don’t handle some is that we cannot get to those servers via remote. For example, Pyxis won’t allow us access to their error logs via remote. I have asked several times. No matter, we call support. And when we are asked as to why it took so long, we give them the painful answer.

It is my opinion that IS should become as self-suficient as possible because this decreases “wait” time getting the problem solved. I’m sure we have all experienced a 5 minute problem taking 2 hours or more to get fixed.

Keep operating the way you do, document, if possible, the amout of wait time to get something fixed, and, if you are lucky, your environment will change for the better when they see how much better they can become.

[Donald Wood]

Our organization is like Michael’s.

We actually “own” the IB/OB lines on the systems that connect to the interface engine.

It’s more work, but we detect and solve problems very quickly.

We are a small shop so the resources you would expect to administer the interfaces are happy we perform the task.

[Anonymous]

The Help Desk is the one in charge of contacting and escalating all the connectivity issues. They can bounce our interfaces and if they see that the other API needs to be bounced, they have info about how critical is the app, contact numbers, support hours, escalation procedures, etc.

This free us to work more on developing and troubleshooting.

For development, we like to work with files so we don’t depend on the other application teams. Once the interface is ready, they are the ones calling us to start/stop it so they can test them. They coordinate among themselves to send/receive the data (we usually leave the test interfaces up)

[Author]

Replies