When people ask me what I studied or in which field do I work and I say IT they always ask me if I develop. When I say no, if they know a little about IT, they ask if I test or if I'm a system administrator. And I keep saying "No", which just confuses people. In the end I say that I "integrate", which people take as if i have said "assimilate" or some other word that, while kind of knowing the meaning, doesn't tell you anything....
In one of my earliest long posts I mentioned a little what does it means, but I though I'd spent some time explaining it a bit more...
Integration, for starters, is really a meaningless word. It means to basically put everything together, and in a way that's what I do, but not really...
I do not program, apart from sometimes automatizing some tasks. I do not test much, although there is some testing. I do not administrate systems, although I do connect to servers and run things in there sometimes.
What I do mostly is to act as a firewall between all the teams involved in providing a service and the final users and clients. I'm also (in theory) the person who should know more about a service so, when issues arise, the right team receives work.
This is still pretty vague and sounds as if I spent all day sitting in my chair and twirling my fingers waiting for people to contact me.. so, let me explain a bit more..
I plan, or help plan, things. For example, we have a new version of the system and we need to install. The team that installs needs to tell me how long will they take and when they can start doing it, and then I go to the users, check what are they doing the day we need to install and plan when can we do it. I then prepare all the paperwork necessary, including requests to the team that installs about what needs to be installed and where.
We also have paperwork(well, it's all Web-based and through computers, but it is basically bureaucracy) about what do we have in our servers and computers, so i do paperwork updating these versions once new deliveries arrive.
Another important part of the job is to help the users (mostly testers, except for the operational period when we're actually live and the users change) to use the system. Loooots of times someone comes to me and says "your system is not working".
After punishing them adequately for their lack of details regarding what is really not working or in what way it is not working(by being adequately sarcastic or passive-aggressive or as clear as they were when answering about it), I go to where they had the problem to visually see what they mean , check the system and the different monitoring tools we have to check the system status (here I'm not talking about system administration but more on the line of checking logs to see what our application says it's wrong), and find the cause of the issue and a solution. If the cause is not evident, finding a solution first also works.
Most of the time the solution is to smack them on the head and point them to the fact that they missed a step when doing the initialization steps. However, sometimes I need to smack someone in my team (or myself) for breaking something temporarily after having done something stupid, or passing the problem to another team more qualified to know what's wrong. This could range from security and network teams (the real sysadmins) if things are slow or crashing for no reason, to the company that produces the data that our system reads (because they are giving us the data in a crappy format), to the people that actually prepare configuration files and parameters of the system during installation, or to the developers if we really have a bug in our code. A big part of the job is this, to investigate problems until you can figure out more or less what is happening, why, and even ways we can fix it.
As usual, the trick is knowing enough to send to the correct team while offering a solution or workaround if possible. It is like in that joke where a guy goes to fix a machine, presses one button and everything works, and charges a lot of money for it. In the detailed bill, he writes that pressing the button costs one dollar, and the rest is the cost of knowing which button....
We have plenty of users and special moments when we need to give extra help, so I have a team that helps me in doing all that...so, I also need to teach my team, prioritize problems and plan stuff with them like vacations and such things .
I also need to speak with the clients, understand what they want and try to make sure they are happy and that when they check the service nothing breaks.
Apart from all that, I help to guide where the service will go in the future. This is not my job directly, but by having the knowledge about how people use it, my opinions in the matter are at least considered, and when something is a pain in the ass to do I try to warn so it gets improved later on. As part of this, I need to manage all petitions to change stuff in my service. Again, this is mostly paperwork, but you can see which changes have been requested, when are they going to be done and stuff like that. Another part of the job precisely is to check that these changes have been done at the time people planned to be done.
Since all this means interacting with other companies and other teams in different parts of the world, there's lots of meetings, conference calls, presentations, trainings, etc...in some of them I am presenting, in some of them I am listening only and in some of them I'm commenting on stuff.
I also do some testing, but not much. I just test things that could not be tested before. For example, you may have tested part A of a system, and it's fine, but after installation you have A connected to B and C, receiving from F and saying hi to Z every 10 minutes...and you cannot test all that until the whole thing is in place, especially because sometimes Z and F are done by another company. Most of this test is done by another team, but my team sometimes needs to test one of those interactions(like A with C, for example).
Another important aspect is to calm down tempers...as the guy people go when there is a problem, part of this job is to make sure there are no panics and things are treated with the level of importance they deserve. If we really need to panic I will say so, but I also need to assure users and show that it is going to be fine and we're working on it, that things are under control. Perception is very important, and sometimes it does not match with reality. Therefore you need to calm down things, shown is not that bad, offer solutions, etc, not only until things work but also until people realize things work.
Finally, there is periods called operational periods where we give extra help doing work shifts(yes, that means night and weekends sometimes). These periods can be testing periods or the real thing, but in anyway during these periods we work from this nicer area that looks like NASA with lots of screens and projectors and TVs. From there we need to use our systems to prepare the sevice to be live. During the testing phase the users do that, but if we are in operations my team does it. We also practice steps required to do each task, and therefore I need to write plenty of documents about these steps, and improve them from time to time. This way anyone with some knowledge of the project can theoretically do these steps. It's usually in these steps that we can try to do some scripts or little programs that are not oficial but that make our life's easier, but that's the extend of our programming in this position.
While in operations we also take care if issues differently, with more pressure on fixing things faster and in any way possible. Again, all this without touching code, just using back doors, emergency solutions and our knowledge of the systems. This period also means we have several teams together so we need to interact with all of them, learn communication channels and how to propagate information to the people that will come next day. I also need to manage the people in my team in these periods, ask for reports, do daily reports myself, track problems, all that...
I don't know if these explanations help to give an idea of the type of job or the level of work we have, but I can tell that it fills our days quite completely, and the fact we are in front of the clients makes everything more intense, fast and stressful...but I do kind of enjoy this^^
