When is it "SOA"? Ever?

Joe McKendrick asks "When is it SOA?"

When you have a bunch of Web Services, is that an SOA?

To give my answer on this question, I'll take a step back first. Twelve years ago, I was working in the EDI area. The company which I worked for managed the flow of structured business documents on its network. These documents were sales catalogs, purchase orders, corporate tax returns, and medical test results. Fast-forward to 2008, and now many of those documents are formatted as XML and sent over the Internet through secure pipes, making use of SSL and WS-Security.

At Vordel, many of our customers would fit into the category of "linking systems together using structured XML documents as the intermediate data format". Is this "SOA"? I can think of one example, a Vordel customer who provides services to telecoms providers. They receive feeds of data from their customers as XML. If I asked them "do you have an SOA?", they may answer "No", even through they are sending gigabytes of XML data between systems daily. What would make it an SOA? I would say the answer depends on where the initiative came from. If it came top-down from a CIO, with the registry bought up-front, then it's an SOA. If it's a grassroots pathfinder project from developers who want to make use of XML technology for integration, then it's not an SOA for the simple reason that nobody calls it an SOA. In that case, it is just a bunch of (very successful) Web Services.