posted on Tuesday, May 10, 2005 9:13 PM by scotts

Where’s SOA?

You are probably familiar with the Where’s Waldo picture books, especially if there are children around the house. I’m starting to think it might be fun for us Geeks to start a new game; let’s call our version Where’s SOA? Instead of flipping through pages of a book, we’ll click through entries in our RSS aggregators, constantly looking for SOA. Just like the picture books, there will be all sorts of people dressed up like SOA, wearing his shirts, his glasses, maybe carrying his walking stick, but how will we know if its really him? It’s a tougher game then it sounds. At first glance you think you see him everywhere, but upon closer inspection you find it’s just someone imitating him. 

Perhaps the reason we can’t really find him is a) we really don’t know what he looks like, or b) maybe he’s not even really there?

Here are two very well respected people that are beginning to question whether he even exists; Clemens, Rich. If you know anything about these people (which I hope you do), you might fall into one of two camps; “He is the last person I would expect to ask that question” or “I always knew this guy really knew what he was talking about” I'm on the second campsite.

Here is a link to a whole group of people that are going to get together and play Where’s SOA. They promise to let us know what he looks like if they ever find him. It might make things easier for us when we are looking for him. This sounds helpful.

I have to admit, I love playing Where’s SOA, it becomes addicting. It seems every time I open my aggregator these days, I loose focus on the content because that rascally SOA guys keeps peeking at me challenging me to come look for him. This morning I was catching up on this week’s Tech news, looking to see if anything exciting happened while I had my head buried down in code and meetings all week. Besides for all the blogs I read, there are also the articles written by people getting paid to tell us what’s happening. One of the worst culprits for getting me into a good game of Where’s Waldo, oh, I mean Where’s SOA, are these guys. Man, they always suck me right into a good game. I think I’m going to have to unsubscribe from their mailing list, just so I can have more time on the weekends to get important stuff done, like picking up the yard from my dog’s week long mess and cutting the grass. Boy, if my wife ever found out that I postponed my chores just because I was playing Where’s SOA, I think I’d be spending a few days with the dogs in their house. She thinks’ I actually spend a few hours on Saturday morning working.

Here is today’s article that I spent most of this morning’s coffee pot with, playing a pretty fun round of Where’s SOA. This was a pretty tricky one that I really had a tough time with. On first glance, it looked like he was everywhere. But as I got close, he got sneaky and kept hiding behind the word “an”, as in “an SOA”. I hate when he does that because it makes me stumble as I look for him. For some reason, I always want to look for him behind an “a” as in “a SOA”, as in “a Service Oriented Architecture”. I might be wrong grammatically, but the point is that I myself just stumble getting there. I suppose the “an” is really referring to “an architecture” and the “SO” parts are just some silly adjectives that get in the way.

This article claims that these people currently have 180 Waldo’s hiding somewhere. But, then again they claim that they’ve been playing for about 3 years, so I suppose they are pretty good at finding him. They are hopeful that they can get this count up to around 1500 if all goes well. Wow, 1500 instances of Waldo, he should be really easy for us to find here.

They certainly did a good job explaining one of the reason I keep looking for him by quoting someone saying: “It sounds like a light beer commercial, but [an SOA is] faster, it’s cheaper, it’s better, at providing a more coherent IT strategy,” Wow, faster, cheaper, and just plain better! I really can’t wait until I find him too.

I thought I was on to something today (as it always feels when I’m playing), and perhaps that rascal SOA would be captured at last. But unfortunately I lost him again; he managed to finally escape for good somewhere around here “Challenges in SOA deployments include platform heterogeneity, message brokering, data silos, security, and lifecycle management”…”Security and the issue of data silos can be addressed through security and data services layers respectively” and here “The true measure of an SOA is its ability to enable service reuse”...“At some point, someone has to stop writing code”

I thought the SOA I was looking for solved the platform heterogeneity issue, not exasperated it? Right? Isn’t that one of the benefits? “Service A” could be hosted on a Win platform, “Service B” on a Linux flavor, and “Service C” could be exposing some mainframe batch processing results. Isn’t SOA supposed to be what makes this seamlessly all act like one big homogenous “A”. If the platform heterogeneity issue is a challenge of SOA, then I think I’m looking for the wrong guy.

I also thought the SOA I was looking for would not be challenged with “data silos”; but embrace them. If each Service in my SOA follows the tenets of good SO, then there is no such thing as a data silo problem; it is a data silo design. Each service is supposed to be autonomous and explicit. Therefore, it would be expected that any data concerns would be internal to that Service and should be invisible to the other services. You know, “what happens in Vegas, stays in Vegas” It comes with territory. You can leave messages for the people in Vegas, and they might even call you back when they get a chance. But, you will never really know what’s going on in there. That’s just the way it is when people go to Vegas. Additionally, does “solving the data silo concerns” by introducing “data services layers” sound like explicit boundaries and automity? I’m not sure. “Data service layers” is an interesting topic, with a lot of value. But a “Data service layer” shared between the S’s in a SOA is like telling people about your Vegas stories, which I don’t believe you are supposed to do.

I got worried that I might really be missing something here when I read that they are solving the Data Silo challenge of SOA by introducing Data Layer services. So I ran a quick Google search on [“Data Silo” SOA]. And much to my surprise, the number 1 hit was this Enterprise Architect article, entitle “Architect Data Services”, which included this comment in reference to SOA: “…As long as these services each have their own, nonoverlapping data, a messaging layer such as an enterprise service bus (ESB) is sufficient. However, when services share interdependent underlying data—such as inventory or customer data—a data services architecture (DSA) is required in addition to the ESB to ensure that each service is working with consistent information.” That’s just scary. Multiple services operating on the same data? Now, I’m dizzy. These can’t be SO services, can they? If we look at the now famous 4 tenets of SO, could we ever, ever say something like this: “services share interdependent underlying data” And, if they are not SO services, then what does the “SO” in the “SOA” of this article speak to? I’m afraid that I’ve lost Waldo for another day.

Comments