What do I do?

I often get asked what I do for work. The answer usually goes one of two ways. Either the conversation is ended quickly with an answer like "I am an IT consultant," or a long winded explanation is given which always makes me feel like I am boring the person to death. I do have an "elevator speech," but that's for people at least aware of my industry. Besides, I don't want to sell anything to the people asking the cocktail party kind of question. Everyone is so different in their interest and understanding that a prepared response wouldn't work anyway. So, let's do this. I will write a blog post about what I do. Next time I get asked I can say "read my blog." Then they'll think I'm a blogger and be impressed. Until they read it and realize that in reality I am just an IT consultant pretending to blog.

What I do is classified as EAI. You can read all the abstract details of what that is on the page linked to on Wikipedia. But, that's only a description of the outcome. The outcome is fairly easy to arrive at once you know all the gory details, but EAI in my experience is never independent of larger system changes. Someone has to design the integration at the same time as the application is being designed. In really fun cases both sides are being designed at the same time so neither side provides traction. Furthermore, the business processes that are usually driving the new system also drive and should align with the web services, messages, etc. that are implemented as part of EAI. Basically, things move a lot through a project. Integration is one of the many endpoints in a modern system and any changes internally (design or after go-live) affect all endpoints potentially.

To get a handle on all these pieces an EAI consultant needs to understand the other systems, business processes and core technologies. This is why I like it. A lot. I get to act as a translator between various world views which forces me to look at things differently.