SOA and the Simple-heads

A lot of effort went into making this effortless. —secret truths of simple-heads

James and I were discussing expanding the reach of SOA sales “down market” this morning. The context was that selling to the Really Big Customers was saturated, and going quite well. These are the Enterprise Good Ol’ Boys who are and have spent millions on Enterprise Architectures. In the context of SOA: lots of WS-* re-tooling and other software to manage the new SOA delivery of business services. What was once one-off systems and monolithic applications is now city-planning and Lego bricks.

Those Without SOA

There is still, though, Everyone Else. The rest of the market who’ve yet to benefit from applying SOA-think to their IT needs.

This part of the market may not have “complex” needs at the moment, but as they become successful, their needs will move from the “simple” needs (and, thus, software) they have to the “complex” ones that the Enterprise folks have.

So, how do you get these people to buy into SOA?

Simple-heads vs. Complex-heads

And that’s where the discussion started getting a little wonky. James knew that there was a vast schism here between the simple-heads and the complex-heads. The REST and the SOA heads. The WS-Deathstar vs. the WS-* people. Essentially, the two camps don’t want to have anything to do with the other because each thinks the other is fatally flawed:

• The simple-heads think the complex-heads make everything too difficult in the name of…well, they’re not quite sure why. Maybe to sell more software, because they like punishing themselves, or because they don’t know any better.
• The complex-heads think the simple-heads are using “toy” technologies that surely won’t work in “the real world.” Simple software can’t be used for large scale, high-dollar problems: surely you couldn’t transact billions of dollars a day with “simple” software.

Success is Painful

All this framing clouds the issue because it skips over the technologies themselves, instead focusing on the (supposed) goals and acceptable outcomes of each group. There’s a core assumption that’s made in most discussions I have about the above: complex problems need complex solutions. It’s as if the more valuable and “important” a problem is, the more tedious the solution must be.

Thus, “simple” technology like HTTP, XML, and JSON are great if you’re writing blogs about your cat. You can code these things in a weekend, even open source it! But, if you’re updating sales data with distributors or doing energy trading, you’ll need complex technology like transactions, JEE, and service descriptors. Success in complex software domains must be expensive and painful.

Really, though, both the simple- and complex-heads want robust, scalable, software. They want software that works and satisfies their goals. It’s not like REST fans are cool with their stuff breaking and customers being un-happy. Both camps want success.

It’s the Technology

Where they, differ, however, is the actual technology being used. The “rest of the market,” mentioned above, simply doesn’t want to use WS-* stuff. They want a different technology, and while they may cast it as “simpler,” that’s beside the point when it comes to marketing. They just want to go about reaching the same ends with different tools.

As Al puts in a comment:

So how about we just replace SOA with SOR, Service On Rest loose the WS* hair-ball and UDDI dinosaur, make everything a service based resource – RESTFarian style. The moment you can just hyperlink to everything is when clarity and loosely coupled common sense kicks in.

You will also need some slick agile coding on top to act as the mortar coupling it together – Groovy/Grails, Ruby/Rails, or even Python.

This to me seem like the problem with selling SOA’s “down market”: while everyone wants the mom and apple-pie stuff (software that works and makes you successful: agility, five 9’s, scalability, & co.), what the simple-heads care about are the languages, technologies, and methods used to get the moms and apple-pies. They’re not going to put up with having to use WS-* and the heavy process that they believe comes with it.

More importantly, they don’t believe high cost and suffering are needed to solve “real” problems. On the other side, the complex-heads simply can’t believe that anything could be otherwise: how could some nutty, open source ESB help process millions of dollars every day?

The subversive simple-heads, at this point in the thought-process, would like to move their thinking up market: why assume the complex-heads would like to stay so? But, that’s a culture-war for another time.

This is the weird situation I always find myself in when talking about SOAs: it always becomes about the technology, not the over-all goals or even architecture. It seems like the complex-heads are always trying to lessen the importance of low-level technologies in IT — which language is used, which operating system, which development methodology, etc. But, the discussion always comes back to technology. And in this problem of figuring out how to sell SOAs to a wider audience, it seems like a discussion of the technologies involved is what’s missing.

I leave you, dear readers, with one of the most interesting, relevent little tidbits I’ve come across recently, from a long chain of via’s:

“We just bought a registry, we spent a lot of money.”

I said, “Great how many services are you gonna put in that registry?”

“Well we have three or four.”

And my point with those folks is, “You could keep up with that in an email or a wiki page. Why do you need a registry for three or four services?”

Technorati Tags: soa, ws-*, rest, goodenough, simple, complex, enterprisey