I want one of those SOA thingamajiggies

I wander the blogosphere on occasion looking for new articles on "selling SOA to executives" and I get the same-old story.  Tell them about the benefits of composing applications.

Then pray that they care.  Personally, I think that is bunk.

Briefly, before my father passed away, we entertained the idea of him moving to the Seattle area and living with me... but he had demands.  He wanted to have his own apartment with room to continue creating his art (my father was a prolific artist, especially acrylic on canvas, but he loved ceramics as well).  After explaining the costs of an apartment like that, we settled on the idea that we would expand my house and add an in-law apartment.  So we called an architect and he came over.

And you know what?  He didn't tell me about how easy it would be to construct my house.

Nope... not once.

We talked about the size of the apartment and the zoning restrictions and other opportunities like expanding the master bedroom to extend over the new addition.  We talked about design and asthetics and we looked at his portfolio of work.  Not once did we discuss standard parts or methods for extending a foundation.

I trusted him to help me find a competent Contractor who would take care of that.  I assumed that they would build the house out of commercially available parts (standard lumber, standard floor boards, standard electrical and plumbing fixtures, standard roofing materials).  I know enough to know that the standard stuff only gets you to a point and you have to customize from there... that craftsmanship still counts, but I also know enough to buy the off-the-shelf stuff for nearly everything from floorboards to outlet covers. 

I've decided that the best way to "Sell SOA" to the business is not to sell SOA to the business.  Let's talk about the asthetics, the features, the speed and reliability, the automation of their business processes to allow them to focus and innovate where it counts.  Let's not talk about standard parts.

When you remodel your house, the parts aren't just parts.  They are "options."  The architect had no intention of letting me pick the type of electrical wire that runs through the walls.  The choice is his (and the contractor's) to make, based on zoning standards and their professional preferences.  Not mine.  On the other hand, when it comes to picking the bathroom tile for the new bathroom, then I'm involved, because it is an option... part of the asthetic whole.

He was selling 'lifestyle' and 'functionality,' not walls and outlets.

The reality is that services are the parts.  Detailed, messy, noisy, wildly complicated parts.  I have no desire, nor intention, to make the business folks learn the details of how a part works.  I do want to be able to offer them options. 

The biggest challenge I can see to selling SOA is that we sell SOA.  We need to sell solutions.  We need that layer of abstraction on TOP of the services layer that is the abstract solution.  Highlight: abstract.  Like an interface definition, the abstract solution doesn't exist... it is a description of a solution.  Many different implementations are possible.  In other words, the customer doesn't buy the service.  He or She buys the iSolution Interface.

Important to note: the iSolution interface is not a single thing.  It is a very generic interface, like iObject.  Under there, you will find hundreds of other interfaces... other abstract solutions.  In our program, we've developed a hierarchy of these "level 2" abstract solutions, and I'm working on level 3. 

This is the stuff to sell.  Lifestyle, asthetics, functionality. 

Let me worry about the parts.

Comments

• Anonymous
  August 11, 2007
  PingBack from http://msdnrss.thecoderblogs.com/2007/08/11/i-want-one-of-those-soa-thingamajiggies/

• Anonymous
  August 11, 2007
  Hi Nick, How right you are! And so simple...! I - once again - totally agree with you: <a href=http://soa-eda.blogspot.com/2007/05/business-doesnt-ask-for-soa.html> We are not hired to deliver SOA's to the business, but solutions. That's what they ask for</a>. Jack

• Anonymous
  August 11, 2007
  The comment has been removed

• Anonymous
  August 12, 2007
  The comment has been removed

• Anonymous
  August 12, 2007
  Maybe I'm off-base here, but I think the reason everyone gets into the details of SOA is because IT has promised to deliver this stuff - agile enterprise, lower development costs, etc - under various guises before. So, when you're trying to convince business that it's worthwhile because it will lower overall costs and provide for a more agile enterprise, they end up asking questions like, "Well, yeah, but that's what you said when we invested in this system and that solution. We've already spent all this money on IT - what's different this time?" So, then you have to explain why SOA is different - because it uses open standards and so on. Imagine if your housing addition fell down or didn't met code or didn't meet your needs in some other way. When the architect came back and said, "We have to do it again. I thought this material would hold and it didn't." Wouldn't you ask more questions this time about his 'standards?' The problem is, housing standards and codes have been around for a long, long time. Your architect knows what works. With IT, that's just not so. IT practitioners are still trying to figure out what works and what doesn't work. And new 'materials' are constantly appearing. So, the solutions do get better - but you've got to convince the business. And, understandably, they have a lot of questions. You have to build a better, more in-depth case than your architect because, frankly, the results haven't been as promised.

• Anonymous
  August 12, 2007
  Indeed Nick - in my experience, SOA is too easy a buzzword to latch on to, and out of 6 or 7 major organisations I have worked for that claimed/believed they were doing SOA ... none of them were. More importanly (or worryingly), none of them really wanted to, they just wanted people with the financial purse strings to think it was all 'industry standard' stuff. I will be very happy the day bosses realise that SOA is pretty meaningless, it is just a good buzzword. Maintainable, flexible, independent and evolutionary solutions that talk to each other (which is essentially what SOA is trying to bottle into a single acronym) are something very different to what most consultancies sell as SOA ... which is in my experience, usually 'use web services'

• Anonymous
  August 13, 2007
  I think I disagree with your analogy Nick, if the executives are internal to the company then aren't youwe more like specialist building contractors trying to get buy-in from the architect to use a new material or building process, e.g if you were building an eco-house you might be trying to get the architect to use straw walls instead of concrete. If the executives are external and youwe are trying to sell a product then why would you expect them to need to know the details of SOA or any other implementation paradigm, e.g. I know vaguely how a car engine works but I don't need to much detail when purchasing a new car. Just my two pennies worth :)

• Anonymous
  August 13, 2007
  The comment has been removed

• Anonymous
  August 13, 2007
  @Casey, Yes... The real goal is to build maintainable, flexible, independent and evolutionary solutions.  I could not agree more. SOA is the gift wrap. --- Nick

• Anonymous
  August 13, 2007
  @Ollie, who has a better relationship with the customer: the external vendor or the internal IT department? Do I have to ask?

• Anonymous
  August 13, 2007
  There is an interesting logic argument in the SOA community that says: IT has lost the trust of the business,