WOA, or whatever … Here's some 'detailed' initial thinking

What does WOA mean to those standing up SOAs today?

First a correction from yesterday's blog post. Nick Gall was actually the first dude to mention WOA and Dion further defined it and made it popular. Of course, you can call it the "Global SOA," the "Universal SOA," or whatever works for you. It's really about the architecture, and the notion that architecture extends to the Web resources. Perhaps it's best that we don't get wrapped around the name but drive to the concept. Some name will show up.

Of course, I received a few "where's the beef" e-mails yesterday, so I figured I would put some meat on the bone.

So, what does WOA mean to those standing up SOAs today? It's clear that many of the services we consume and mange going forward will be services that exist outside of the enterprise, such as subscription services from guys like Salesforce.com, or perhaps emerging Web services marketplaces, found on places like the Programmable Web.

This is outside-in SOA, in essence reusing a service in an enterprise not created by that enterprise, much as we do today with visual information on the Web. Thus, those services outside of the enterprise existing on the Internet create a Universal SOA, or WOA, ready to connect to your enterprise SOA and perhaps providing more value. This is nothing new, by the way; we have been talking "Universal SOA" for some time now, at least the notion, but we are seeing reliable resources appearing today.

So, how do you prepare yourself? I have a few suggestions:

  • First, accept the notion that it's okay to leverage services that are hosted on the Internet as part of your SOA. Normal security management needs to apply, of course. This is the largest issue out there, as I see it. People love their datacenters, no matter how much they cost.
  • Second, create a strategy for the consumption and management of outside-in services, including how you'll deal with semantic management, security, transactions, etc. Lots of work here, you need to create policies and procedures as well as the technical mechanisms.
  • Finally, create a proof of concept now. This does a few things including getting you through the initial learning process and providing proof points as to the feasibility of leveraging outside-in services. You could be consuming services today, if you know what you're doing.

Other, more technical issues you need to consider:

  • Consider your firewall issues. Look at how easily you can consume services from sources that are outside of your enterprise and what has to be done to make this possible without compromising security. Typically you'll have to upgrade your infrastructure to allow for outside-in Web services.
  • Consider connectivity. So, how do you make Web services known to your enterprise applications? How about your legacy systems? You need a strategy there, and connectivity is not as easy as it seems. You have to account for the differences in interfaces and protocols.
  • Consider semantics. So, how do you account for the differences in applications semantics within the consumed services, and your native application semantics? The answer is an integration server or appliance. Do you have one, and is it the right one?
  • Consider governance. You need a governance strategy to make sure the services you leverage are secure and won't become another problem. Remember, we're attempting to solve problems here, not create new ones.
  • Consider change. This is a fundamental change in the way things are done in most enterprises, and now is the best time to change both understanding and attitude towards this huge, dare I say it, paradigm shift. Most enterprise architects and developers I run into can't comprehend that services from the internet could replace applications developed internally. However, those that embrace this first will have a huge market advantage. This will prove out as we move forward. Will you be ready?