Blog: Jill Dyche: SOA Explained. (Second Time's a Charm)

« Shhh! It's the Voice of the Customer! | Main | Foreign Keys: Building a Terrorist Database »

SOA Explained. (Second Time's a Charm)

In which Jill does a mea culpa to her partner, Evan, for not only pinching a good story but bungling its telling. As you'll see from the footnote, payback's a bit... Well, you'll see.

Okay, I botched it.

You see, I’m up in front of a few hundred people at the Teradata Partners conference talking about Customer Data Integration and why it’s a key and growing trend in the quality, integration, and propagation of customer data across the enterprise. Everything’s going swimmingly until I get to the part about Service Oriented Architectures. Then I decide to get cheeky and throw in an analogy that my partner Evan uses to introduce SOA. Except I sort of mangled it.

You see, Service Oriented Architecture changes a lot in terms of the way our systems talk to one another and share data. It has particular consequence for CDI. I said so. Then I tried Evan’s analogy that compares the pre-SOA days to the olden days of Ma Bell. In the periphery I spied Evan off to the side gazing up at the ceiling, and I thought, Uh oh.

Rather than give you my version of Evan’s SOA analogy, I figured I’d let Evan explain it himself. He tells the story this way:

Years ago, when telephone service came into existence, you’d pick up the phone and talk to an operator. You’d ask the operator for a telephone number, for instance, “BR549.”* Back then, telephone numbers weren’t uniform—they included both characters and digits. So the operator would figure out the location of the number and then manually make the connection to another operator in the network who would then contact another operator, down the line. All these operators would be plugging in wires manually to their switchboards to connect the call.

Gradually, the phone company—there was only one at the time—realized that in order to support this series of manual connections and the brisk increase in call volume, it would ultimately need more operators than there were people in the U.S. Ma Bell needed to streamline call connections. This meant standardizing both the numbers and the network.

Before SOA, if you wanted an application to talk to another application, you had to write custom code on each side. A programmer would have to understand details of network hardware, communications protocol, and the messaging mechanism that both systems could understand. If security was an issue, this needed to be programmed into the solution. Technology improvements like open standards and EAI alleviated some of this—hardware and protocols were addressed by vendor products—but vendor dependence remained an obstacle. The advent of web services removed these barriers. One system could communicate with another system without being dependent on a particular vendor’s products.

The phone system of old required significant manual intervention to create a connection. Same with application-to-application communications before SOA. SOA simplifies connecting systems, and expands the type of information that can be shared between those systems to support unstructured data and even executable code. It’s the new standard for inter-application communication.

So there it is, this time straight from the horse’s mouth. Thanks to my presentation attendees, whose kind words afterwards washed away my momentary nervosa, and to Evan for setting the SOA record straight.

* For the trivia buffs in the house: “BR549” is the phone number of Junior Sample’s used car lot on the show Hee-Haw. (Happy now, Evan?)

Share: