Ugly Ducking

In the past few days, we had somewhat painful discussion with one of our clients. This client is embarking on an SOA based project that I'm quite excited about. Of course as in any other project, almost right after launch, we realized that we have bandwidth shortage problem. Rarely does a project exist where the scope is lighter then the resources and the skill sets involved.

Being the SOA strategist for the company and de facto architect of the very first SOA implementation, the ball fell in my court to find someone that fit the bill. "That should be easy." I mused. I just need to bring in some of the folks we work with if we are short on bandwidth in our company. Few phone calls and we have someone available! That in current state of the economy is an achievement! We talked about the whole arrangement and presented the person to the client. They all liked each other and everything was right on track -- until procurement got involved that is.

While talking to guys in the procurement maze, it became clear that they had a different view and take on the whole thing. The department had created a set of job profiles and related rate ranges. That sort of thing works well for most mainstream skill sets. It makes sure that the cost of certain skill set is streamlined across different departments. IT managers from all over the company can query procurement about what a typical, say, system administrator would cost. In this case, after the initial discussion, procurement folks concluded that this is a "software developer" requirement and thus falls within a certain rate range.

Now, I'm not going to judge how much they should pay to whom, but I can certainly say that SOA solution developers are not as plentiful as, say, Java or J2EE developers. While most of them would have done Java development in the past (and may still do as part of the SOA solution), it's not the same. Essentially, Java != SOA and C# != SOA and XML != SOA

To me, SOA solution development requires a different mindset. The way services are architected (message formats, granularity, composability etc.) is different from a Java application. Simply exchanging SOAP messages doesn't make a service. One needs to learn and internalize difference between SOA and glorified client-server application. And we all know, that more learned you are, the more price you can command -- And rightfully so. The more specialized a skill becomes, the more the demand per person there is and the laws of supply and demand say, higher the price.

Of course, not everybody has to agree with that argument. What's your take? Is SOA consultant the ugly (read pricey) duckling of the pack? feel free to add a comment or send email to naresh@tasmanAve.com.

Incidentally, our story has a happy ending. We have the consultant working on the project now.