What is it I do? (part 2)

In a posting yesterday, I started to explain what it is that I do.

I explained that my role is to help IBM WebSphere customers be successful and gave an example of a customer relationship management problem in the auto industry.

I hopefully gave a reasonable overview of the problem to be solved. What I didn't do, however, was tie that back to my core mission: making WebSphere customers successful.

To do that, we need to think about the problem in a little more depth. I used hand-waving phrases such as "good customers", "inviting them to evening drinks", "bought lots of optional extras".

These phrases turn out to be key.

Who are the good customers? How do we contact them? Which extras did they buy?

If all this information was in one nice big database, life would be easy.

The problem is that most companies don't work like that. They have a collection of computer systems, of various ages, littering their IT landscape. Consolidating their entire business onto one system simply isn't feasible. There may be one system that tracks payments made by customers on their purchasing plans. Another one will list the exact order that a customer made. There may be a relationship with a business partner to handle the face-to-face "wine and dine" sessions.

Successfully integrating these systems is difficult. Moreover, integrating them in a coherent, scalable and forward-looking manner (so we don't have to repeat the exercise on the next project) requires even more skill.

When I talk about integration, this is what I am talking about.

At a technical level, we have to worry about message formats, adapters, you name it. At an architectural level, Service Orientation really is key.

Now, there are several other strands (human interaction, business-level monitoring, business-level modelling, and more). However, I hope this has helped begin to give an insight into the kinds of issues we help customers deal with.