I Can Haz Mashups?

It's a popular misconception that if you throw some SOAP, WCF, or J2EE service layers on top of an application, it's automatically easy to integrate.  I place the blame for this misinformation squarely on PHB's and Gartner conferences, because this is simply a case of management by buzzwords.

A good friend of mine used to tell me all the time that the reason we're entertained by a dancing bear isn't that the bear dances well - it's that the bear dances at all.  There once was a time when just being able to talk to a mainframe routine from Java, or talk to Java from .Net, or talk to a routine on one of your partners' computers was a major technical triumph.  Web services made the bear dance, it's true.

Now that we've seen the bear dance, though, we're looking for a few new steps and a little more rhythm.  We want the bear to dance well.  We want quick integration.  We want security.  We want reuse across our enterprises, and yes, Virginia, we want mashups like those kids are doing on face-space, or my-book, or whatever the hell it is they're using.  We drunk the Gartner kool-aid, and we want some of that Web 2.0 stuff, too.

But sadly, integration isn't something you pull out of your Web 2.0 Conference swag bag like a door prize.  You will, in fact, have to know what you're doing to achieve any really meaningful results.  Here are a couple of places where conference-oriented development gets tripped up.

Misconception #1: If we're using web services, no additional effort is needed to make our systems integrate well.

Even though nobody actually makes this claim in black and white, lots of executives (and even some software architects) seem to believe it at some level.  Even Garter will tell you that SOA is a lot of work, but somehow, that's not the message that people seem to internalize.

The truth is that integration on an Enterprise scale is still hard work, and your results are still dependent on planning and execution.  It's true that web services make integration easier than it was in days gone by, but you won't end up on the cover of CIO magazine just because you can spell WSDL.

This may not be a popular point of view, but I believe you've really got to treat integration as a product in its own right in order for it to truly be successful.  The API's you create have users, and that means you've got to consider the usability of your API's just as seriously as you'd consider the usability of a flagship application.  I won't go into detail here on what usability means for an API, but it's really comprised of exactly the same factors as application usability.  If you don't pay attention to the people who are going to use your API, your integration isn't going to be much more successful as an application that all your users hate.

Misconception #2: We can mask our business problems by using web services.

Sorry again.  I've seen this a bunch of times, and it never ceases to amaze me.  If you've got a business problem you can't seem to solve without the benefit of a web service, it's unlikely that a web service (by itself) is going to fix your problem.  Data problems?  If you've got data integrity rules to enforce, a web service is great at enforcing them, but if your data is already messed up and you don't have clear algorithmic rules to fix the data, a web service isn't going to help you very much.

Similarly, if you've got a well-defined business process, a web service may be just the thing to expose that process to other applicaions.  If your business process isn't well-defined, or (worse) if your business users can't agree on a process or other requirements, a web service won't bridge that gap.

Business issues like these really have to be raised up and dealt with in cooperation (at least) with your business leaders.

So embrace SOA and web services, yes.  But don't blindly trust that they're going to fix your problems for you.