When we talk to the business, should we sell SOA?

  • Article

There is an interesting logic argument in the SOA community that says: IT has lost the trust of the business, and in order to build SOA solutions, we need to discuss the value of SOA to get it back.  Loraine Lawson eloquently stated the case in a recent entry.  I'd like to dissect that argument a little, because I think there is a flaw in the thinking.

Let's see if I remember my logic class from college (it's been over 20 years... let's see how I do).

  • Assertion A : SOA substantially increases the cost of the first application to use it.
  • Assertion B : All expenses on a project must be shown to the business, who is paying for the project
  • In Logic: SOA implies COST.  All COST is visible.  Therefore SOA is a visible COST
  • Assertion C: Business questions every design item in a project, especially those that increase cost.
  • Assertion D: IT must respond to all questions about design to resassure the business.
  • In Logic: DESIGN COST implies CHALLENGE, CHALLENGE requires JUSTIFICATION.  Therefore, DESIGN COST requires JUSTIFICATION

Stitch it all together and you get the unavoidable conclusion: if you use SOA on your project, you must be prepared to respond to questions about the increase in cost that SOA requires.  To prevent SOA from being cut out of the project, you must be prepared to justify its use.

First off, I'd like to look at Assertion A.  The notion that we have to spend a lot of money for tools and retraining to create a SOA application.  I disagree with the assumption here. 

OK, I'm going to confess: I'm spoiled.  You see, I use Microsoft .Net tools to create services.  Windows Communications Foundation is an excellent platform for creating services and guess what... it's free.  OK, that's not so unusual.  After all, you can do a lot with the Java platform too.  In fact, I wonder where the idea came from that you have to spend a lot of money to write a SOA application.  I'll come back to this in a minute.

I also want to look at Assertion C: business questions every design item that increase cost.  This one is puzzling.  When I show the business my project plan, I don't have a seperate entry for SOA.  When I wrote Client/Server apps, I didn't have an entry for Client/Server either.  SOA is simply part of the core design.  I don't design the application twice: once with SOA and once without, but if I did, I would be hard pressed to show the SOA design costing one penny more for the total project.  SOA is cost-neutral.

Why is SOA cost-neutral?  That's easy.  The value of SOA is agility at two levels: agility for the business process enabled by the application, and agility for the business processes that, in the future, can be enabled by reuse of the services.  Clearly, when you are developing your application, the second benefit (composition of future apps) doesn't play a part in your cost discussions.  However, the first is immediately useful.  That is because REQUIREMENTS CHANGE.

The entire Agile development movement is based on this fact, and it is a fact.  Requirements change.  I've never delivered an application of anything more than a toy, where the requirements didn't change along the way.  What makes SOA compelling is that it enables change... at any time.  You don't have to wait until the application is delivered to benefit from this agility.  When requirements change 20% of the way through the project, you have a more agile design in place, reducing the cost of implementing the change. 

So, back to the logical argument:

Assertion A: SOA increases the cost of a project.  If you view the project end-to-end, SOA is a net benefit or a balance.  It is not a cost.  This statement is false.

Assertion B: All costs are shown to the business.  I would never wish to break out SOA as a line item on a project plan, any more than I would break out 'good design'.  It permeates the application.  There is no line item.  Therefore, nothing to question.  Assertion B is moot.

Therefore, the first conclusion is not a reasonable conclusion.

Now, let's look at Assertion C again: that the business will question every design element that adds cost to a project.  Let's look at it differently... even if SOA doesn't add cost, clearly the business will want to question it, right?  It is true, that in an environment of mistrust, the business will wish to question every element of the project.  However, at the end of the day, they don't want to know that you used widgets or whatsis to build the app.  SOA is meaningless to the business.  They will want some assurance that this project is more likely to succeed than the last four, because each of them failed in some way or another.  (Kind of worst case, really, but I'll go there).

Reality: SOA will not improve the odds of a successful project.   It will not decrease those odds either. 

The things that affect the ability to deliver a successful project have MUCH more to do with understanding the needs of the client and executing on those needs in a timely and cost effective manner than the elements of the design used.  In other words, if you are looking to improve the ability of the IT team to deliver ONE application, SOA will do nothing for you and nothing against you.  SOA is design.  As described, It is good design.  But a bad developer can screw it up.  SOA is not a silver bullet, but neither is it an albatross. 

What SOA gives you is payoff on the next project.  On the current one, there is no net cost and no net benefit.  It is simply good design.

Therefore, when the business questions every aspect of a project, you need to assure them that you have professional people doing professional work.  SOA is a side show.   Talking about SOA when the business wants reassurance is a smoke screen.  Doing this is a dangerous tactic.  You cannot pin your hopes, or your credibility, on SOA, because you are just as likely to screw it up as always.  Don't try.  Assertion C is a smoke-screen.

Without the implication of statement C, the logic of the final conclusion falls apart as well.

With all due respect to those folks who want to sell SOA...

SOA is a good thing, but you don't sell SOA.  The people who sell SOA are selling snake oil.  SOA is not a product or a package or a system in a box that you can buy and say "I have a SOA now."  Service Oriented Architecture is an approach and an attitude and a paradigm of good design that makes your apps (and ultimately your infrastructure) less expensive to own.

So when you are speaking to the business, sell the solution.  Sell the asthetics and the performance and the reliability and the scalability, but most of all, sell the features.  SOA comes along for the ride.