Trying to Sell SOA To The Business? Don’t Bother.

There is absolutely no point selling SOA to the business. They just don’t care. But if you think SOA is a good fit for your organisation there is a simple way to bring SOA in: sell a solution to a business problem that happens to use SOA as the solution’s architecture.

I.T. people are not salespeople. They are hopeless at writing persuasive proposals, worse at delivering compelling presentations and most haven’t even heard of the 30 second “elevator pitch”. I.T. people don’t speak the same language that business people speak, be it words or numbers. If you observe the often comical ways in which I.T. people try and sell SOA to the business you’ll see what I mean.There’s only one thing I.T folk need to know about selling SOA to the business:

Don’t bother. They don’t care.

Aside from the fact that I.T. has a credibility problem when it comes to promoting the latest and greatest idea, business people only care about things that are ‘visible’ to them. SOA is an architecture. It’s a mindset. It’s a design principle. It’s a lot of different things to a lot of different people. But it’s also an abstract concept – you can’t see it or touch it and it doesn’t ‘do’ anything. It means nothing to business people. SOA is a lot like Total Quality Management (TQM) and 6 Sigma of yesteryear. You can’t see or touch ‘quality’ – but in time you can see the results of implementing a quality programme.

So, if you think SOA is a good fit and you want to “do SOA”, how can you go about introducing it into your organisation? Here is five tips.

Tip 1: DO NOT sell the hype.
The “everyone is doing it so we should too” argument is absolutely the wrong way to go. Firstly, this statement is blatantly false – everyone is talking about it but very few are actually doing it, and even fewer are doing it in large scale production environments. Secondly, when things go wrong, it won’t be “everyone” that will be asked for a ‘please explain’ – it will be YOU.

By all means share industry success stories – but don’t ever commit to achieving the same results. Remember that for every publicly available success story there will be many privately hidden disaster stories.

Tip 2: DO NOT sell the technology.
You’d think this goes without saying, but my experience tells me otherwise. If your argument is “if you look beyond the hype, SOA technology is actually very cool” then you’re still missing the point. Techies may think its cool. No one in the business will. To business people ‘SOA’ is just another TLA (three letter acronym). Forget the jargon. Forget the technology. It only confuses people.

Even if business people did listen and understand the technology aspects of SOA, be aware that one man’s “cool” is another man’s “risky, bleeding edge, here today gone tomorrow fad.” Don’t expect everyone to instantly share your enthusiasm.

Tip 3: DO NOT sell features or benefits.
On the face of it this may sound a bit controversial but let me explain.

Proponents of SOA point out the many benefits that an organisation could gain by implementing SOA. The key word in that sentence is could. SOA allows you to do many things but so what? A salesman might point out all the great features of a new television set – but all those features are irrelevant if I’m looking for something to keep my food cold.

Going to the business and trumpeting all the great things we can achieve with SOA is like saying: “I’ve got this great gadget! It does this, this, this and that. Are any of those things of any use to you?” This is the proverbial solution in search of a problem. We’ve got to do better than that.

The business is not interested in all the great things you can do – they’re only interested in what you can do for them. You need to go beyond providing a checklist of features and benefits – you need to apply them to solving real problems in the business.

Tip 4: DO sell business outcomes.
Don’t expect business people to make the jump from features/benefits to business outcomes. That’s the job of the person writing the proposal. Let me illustrate.

The Solutions Architect in an organisation wants to propose a project for integrating the warehouse management and order processing systems. He’s done a proof of concept and has worked through the major technical issues. He’s ready to take it to the business. In his proposal he explains that he’s done a proof of concept. He explains that the project is relatively low risk and that it can be done relatively quickly and cheaply.

Then he pats himself on the back and waits for the inevitable approval. After all, why would anyone knock back a low risk, cheap and quick project? But the proposal is rejected. Like most I.T. people the Solutions Architect is not a good salesman. He expected the person reading the proposal to understand the implications of integrating the two systems. They didn’t. No matter how low risk, cheap and quick a project is, it will never be approved if the person reading the proposal is scratching their head trying to work out what’s in it for them.

A better proposal might say something like: “integrating the two systems will allow us to have a real-time view of our stock situation, which should prevent stock outs and reduce the number of customer complaints”. You need to stress the business outcomes: less stock outs and reduced complaints.

Tip 5: DO NOT mention SOA or bend over backwards to accommodate it.
When proposing your solution resist the urge to put the ‘SOA’ label on it. The business pays Architects to provide solutions using industry best practice – so do it. Whether the solution is SOA or something else – there’s no value in trying to label it.

It is well known that I.T. people like to tinker with the latest technology. Given the hype surrounding SOA, the business might think (not unreasonably) that you proposed SOA because it’s the “in thing” and you want to be a part of it. It’s that well worn phrase again: the business might think all you have is a hammer and you see all their problems as nails.

Finally, don’t get too carried away – SOA is not the solution to all problems. If you bend and contort your solution to try and make some tenuous link between the problem and SOA – savvy business people will see through you. And if they don’t – sooner or later you will have to explain why you chose to fix a leaking tap by replacing the entire plumbing – instead of spending few cents on a new washer.

So there’s five tips for getting a foot in the SOA door. Of course – the same tips apply irrespective of whether your proposed solution is SOA or something else.


2 Responses to Trying to Sell SOA To The Business? Don’t Bother.

  1. This seems to position SOA as a technology, which is certainly not effective to the business stakeholder. Where as if we position SOA as a business concept – understanding the enterprise as stakeholders working together using services, we can see the link to how a good manager understandings roles, responsibilities and delegation. This then provides the link to facilitating this “service oriented enterprise” with technologies that assist business services operate more effectively. This assumes, of course, the enterprise wants to work together more effectively! Given the basic motivation a more effective way for the enterprise to work together externally, with customers and suppliers and internally, between business units, is certainly of business interest.

  2. rafcammarano says:

    Thanks Cory. I agree with you 100%. Positioning “SOA as a technology” is exactly the opposite of what I was trying to do.

    The main point I was trying to make is: there’s no need to sell SOA. Instead, sell a solution to a defined business problem – and don’t bother sticking the “SOA Inside” label on it.

    As a concept “service orientation” provides a rallying point and is a step towards the goal of business and IT people speaking the same language. However, the broad principle of “engaging the business” when developing solutions is not new. SOA simply offers a new way of doing the ‘engaging’.

    No one would go to the business and say something like “I’m going to use object oriented analysis and design (OOAD) techniques on this project”. Yet some think that saying “I’m going to use SOA on this project” is somehow better. It’s not. Both are great concepts and important tools in our solution toolkit – but there’s no value in trying to sell a label – be it ‘SOA’ or ‘OOAD’.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: