Skip to content

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: , , , , , ,

Categories: Enterprise Software, Programming.

Comment Feed

4 Responses

  1. Hmmm, I think maybe I didn't explain well enough in my comment to Jame's post. let me expand.

    Although I won't deny that the technology is import, it may not be at first glance for the obvious reasons (i.e. technology for technologies sake).

    Solving the real I.T. tasks that exist within any organisation is very difficult, programming is difficult, at least programming well. Thus if you wish to solve such issues your need Rockstar programmers. The thing is you wouldn't ask a rockstar to come play in your band only if he use your particular choice of Guitar or drums, rather he would bring his 'Axe' of choice, his 'kit' that he was most effective at weaving his creativity with. Thus what I was suggesting in the comment was to solve your problems you need heroes and rockstars from the programming world, but they will only be interested and motivated if they can bring there own kit. In this instance a rockstars stratocaster may be Ruby on Rails, their Telecaster or Les Paul could be Groovy or Python. With there choice of 'kit' they bring their skills, creativity, agility and get-tin it done attitude using their own internal 80/20 agile cycles. Right now there are loads of these rockstars out there attracted to web 2.0 companies or even their own startups, if you want a piece of that enthusiasm, if you want some heros to work for you you will need to provide an environment that rockstars work in, rest assured most of these prefer REST to Ws-deathstar, thats just what they work with.

    So actually it is about the technology but only indirectly because it's actually about the people, the heroes and rockstars that are going to make your company rock.

    P.S. Simple vs Complex – head is totally wrong, its not about simple vs complex it is agile,adaptive fast iteration vs heavy planning, architectural top down design.


  2. I think it is all about the overall goals, but also a matter of resolution. Say the overall goal is "I want to do this, and I want to do this NOW". But when you dig down you notice that monolithic apps are very hard to modify and adapt, so you start looking at service composition as the lower hanging fruit. When we talk SOA this or SOA that, we're already one step away from the overall goal and we are talking technology, even if we want to present SOA is a high level concept. Then we dig a bit deeper and realize that sometimes WS-* is no different than a monolithic app, and you can get more down with REST and a Web browser. Now we've gone one step away from the overall goal into the devil of the details, but still in support of enabling that overall goal. After all, what's the point of having a Certified, Level 5 Mature, CIO buy in, SOA with Governance, if you can't get things down NOW.

  3. is it too late to comment on this post… 🙂

    As an architect at a solutions provider that spends a lot of concrete time with SMB customers and some time with the tier 1 guys, I completely agree with the notion that SOA is cemented in at least the minds, and in many cases the architectures, of the biggest of companies. But I think you miss some of the picture on your discussion of the simple heads. You paint a good picture of the thinking of the ISV that doesn't compete in the tier 1 space, but I would say that the end-customers in SMB, those buying SOA, have a completely different perspective. It's not the technology, it's the complexity and cost.

    In the SMB space, SOA is pipe dream in the mind of the VP of IT because it's perceived as just too complicated and expensive. Most of the SOA press is around improved plumbing, and if I have a limited budget and limited resources (that spend most of their time just keeping things running), I can't afford to replace the plumbing just because new plumbing is cool. I need the CFO to require an application which happens to be built on a SOA framework, or I need a burdensome and scary regulation and a prepped consultant to tell the CFO that I need an SOA solution.

    That's why I think that Oracle and SAP are poised to really win with SOA in SMB, and it's going to be much more difficult for those guys that are "just infrastructure providers." I've talked to a couple of Oracle customers that have unknowingly modified BPEL when they toyed with the JDeveloper that was included with Financial Management product. These guys are building a SOA infrastructure and don't realize it. And for all those Oracle and SAP wannabes, the technology is on their side. The openness and standardization of SOA should enable interoperability regardless if the underlying implementation is 11g, WebSphere Application Server, or ODE.

    Finally, I will say that there is the issue of SOA maturity. It's telling that a team of architects, engineers, and admins from IBM Global Services or Accenture is required to install the required middleware, let alone build applications and maintain the infrastructure. This is back to the cost and complexity, but again it's tough for a VP of IT to justify a DBA, let alone an SOA admin.

Continuing the Discussion

  1. […] was particularly interested in this part of a recent post from […]