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.
PingBack from http://msdnrss.thecoderblogs.com/2007/08/11/i-want-one-of-those-soa-thingamajiggies/
PingBack from http://msdnrss.thecoderblogs.com/2007/08/11/i-want-one-of-those-soa-thingamajiggies/
PingBack from http://msdnrss.thecoderblogs.com/2007/08/11/i-want-one-of-those-soa-thingamajiggies/
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
Funnily enough – I’ve usually found the opposite, it is easy to sell SOA, but damn hard to sell solutions.
SOA is a buzzword that executives and managers love, because it says "we are doing things in a big expensive and proper way", where as you try and talk about a solution that abstracts the mechanisms and deals with the messages and suddenly they get all scared.
I even had a senior Head of Information Services recently explain to me that he wanted me to stop talking about "services", they had to be "web services" and he would allow nobody to use the term "services" as he had established that SOAP was the only shared protocol in the environment, and that "web services" meant SOA.
He was deadly serious, because he had read, and completly misunderstood, some sales documents a major vendor had been selling to him.
He had sold "SOA and Web Services" to the executive, and he didn’t want anyone coming along and implementing "services" that didn’t care about their delivery mechanisms, as far as he was concerned the key to the whole SOA thing was SOAP and the "web".
Buzzwords are easy to sell, abstraction is hard to sell.
Hi Casey,
Wow. Fascinating. But not better.
Your VP has given the executives a false sense of security. They want to insure that their company is doing things the right way. So the VP has told them "yes because we use web services."
But it is meaningless. A developer can screw up a SOBA just as easily as he or she can screw up a client-server app… perhaps easier.
This is dangerous territory, my friend. One serious failure that stems from poor use of SOA and the executives will just as quickly turn against it as they are now for it.
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.
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’
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 🙂
@Lorraine,
Best answer I’ve had to a blog post in ages.
You are right. We have lost the trust of the business by promising bunk for so long.
This is part of the ‘monopoly relationship in customer-focused clothing.’ If we WANT to meet the needs of the customer, but the customer has no choice but to use us, no matter how crappy our results are, then we will keep promising "we will do better next time" without any real incentive to invest in figuring out how.
That said, two wrongs do not make a right. We cannot increase the trust of the business by talking about SOA when they don’t fund SOA and we don’t build what they don’t fund.
@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
@Ollie,
who has a better relationship with the customer: the external vendor or the internal IT department?
Do I have to ask?
There is an interesting logic argument in the SOA community that says: IT has lost the trust of the business,