To understand SOA, map it without technology

There's been no shortage of confusion around the true meaning of SOA, and plenty of contention around what constitutes "true" SOA versus what people think is SOA. Do legacy apps exposed as services constitute SOA? Do Enterprise Service Buses constitute SOA? Does having a registry and repository constitute SOA? What if services can't be shared? What about BPEL? BPMN? JMS? SCA? WSDL? SOAP? REST? WS-*?

Let's face it, what some people see as "service-oriented" may seem like ugly, ramshackle contraptions to others. Perhaps the best way to understand what really makes a service oriented architecture is to take technology entirely out of the equation.

That's why I like Dan North's recently published explanation of SOA. Dan walks us through the employee vacation-booking process at a large 1950s corporation. And the emphasis here is completing the process effectively, and addressing messaging issues.

A basic transaction may go as follows: "Bob" completes a vacation time request form and sends the request to personnel, but the message is lost in the company's internal mail system. After a week, when he doesn't hear back from personnel, he calls them, and they respond that they haven't seen the form. So, Bob writes up another form and sends it off again to personnel. This time, personnel gets the request and authorizes it.

Here's what happened in SOA terms: "The personnel department is a service provider. ... Bob is a client or consumer of the service. The vacation request form describes a service contract. The filled-in form is then an asynchronous message—Bob doesn’t suspend his activities waiting for the reply to come back; instead he gets on with his regular work... The internal mail is a message transport — an unreliable one in this instance. Luckily, Bob has an error-handling protocol, namely a timeout."

Bob's follow-up call to personnel was a "synchronous interaction — he is on the telephone in real time," Dan explains. "He then implements an error-correcting strategy, which is to resend the message... A second asynchronous message is sent, and this time Bob receives a response in his inbox. This is an asynchronous response. Finally, Bob correlates the response with the original request, and the exchange is complete."

UPDATE: Aloof Schipperke called this example of a 1950s company EOA, or "Elvis Oriented Architecture." Good one!