SOA Sucks When You Have no Control Over the “S”

For the past four years I’ve struggled to build SOA systems in a timely manner. In every case it has been because it was decided to go with another department or companies service for a crucial system feature.

I’m a big fan of SOA; no one wants an application hitting 20 different database servers directly. SOA is the way to go, but you still need to be the owner of all the “S”ervices you’ll be using.

When other departments own and maintain the service or when other companies own and maintain the service, you are at their will. Their service goes down, you wait, and wait. There’s nothing you can do. At least if the service is home-grown and internal you can take action to get it back online.

In addition to run-time issues, I’ve run into countless design-time issues. If a service I need to consume is not owned and maintained by me, I may have to work closely with another department or company to learn the service, get them to unlock WSDL or deliver a spec, or provide me an API key. There’s nothing wrong with this, except that it all adds time.

If I’ve learned anything over the last four years, it’s that when you choose to use someone else’s service instead of rolling your own, you have no control over your timeline, and any estimates you make are purely wild ass guesses.

This entry was posted in Programming, Ramblings, Technology. Bookmark the permalink.

Leave a Reply

Your email address will not be published.