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.
PingBack from http://msdnrss.thecoderblogs.com/2007/08/14/when-we-talk-to-the-business-should-we-sell-soa/
PingBack from http://msdnrss.thecoderblogs.com/2007/08/14/when-we-talk-to-the-business-should-we-sell-soa/
PingBack from http://msdnrss.thecoderblogs.com/2007/08/14/when-we-talk-to-the-business-should-we-sell-soa/
Well said … all too often people sell SOA as the next silver bullet hoping to solve every single problem with it. This is not the case and if people understood that SOA is nothing more than a good solid logical flexible design I think it would receive far greater acceptance.
Some people already have SOA, they might just not know it yet.
I fear SOA and ESB etc. are being branded with the same blood stained label as CRM, the other IT buzzword that has delivered nothing but high project costs and disappointments.
I disagree with the representation that this is my argument, particularly assertion A. My assertion would be more correctly stated as:
Assertion A. SOA will involved additional IT spending. This could be retraining. It could be middleware – yeah, I know, but it could be.
Assertion B: You will be talking about SOA to the business. (Proofs: You may be talking about money or project delays due to the change in development process. You may also be talking about SOA because, according to some statistics I’ve seen, the business is interested in SOA and may ask about it. You will also have vendors selling so-called SOA-based solutions.)
Assertion C: The business will have questions. Maybe not line-by-line questions, but if they are asked to spend more money or told about this change at all – see Assertion B – they will have questions.
Assertion D: IT will have to answer those questions, due to the hierarchical nature of business.
My Conclusion: It’s in IT’s best interest to be prepared to talk about the technical aspects of SOA.
Assertion B : All expenses on a project must be shown to the business, who is paying for the project
But after reading this post, I think I missed your broader point about how this isn’t a solution to sell, per se, but a internal change in how IT does it’s business. I agree – it should be that. However, it’s shaking out a bit differently and while the IT architect may not have to have these conversations, I think the CIO will.
I agree that in general the business doesn’t care about how a solution is put together, and therefore, that there is no need to sell SOA. However, SOA adds an some degree risk that does not exist in a two or three tiered, client-server solution wherein everything runs on machines owned and operated by the business, down the hall in the computer room if you will.
Where I work, a very small company with a very small IT shop, I can slap together an application that satisfies everybody’s requirements and where everything is all in one EXE. The customer is satisfied, and the project is over. Admittedly, the solution has none of the virtues SOA promises like scalability. So what happens if I, say, abstract the business layer into web services?
First, assuming the web services are hosted internally, I have to have the sysadmins create a space on a web server. Hopefully this web server will not go down or be renamed. Hopefully we won’t have DNS issues. Hopefully somebody won’t kick out the plug.
Second, assuming the web services are hosted externally or are provided by a third party, how do we negotiate firewalls? What happens if our host goes out of business?
Third, what about security? That has to be carefully considered.
I could go on, but I think my point is made that services, while they have many benefits, they come with risks. A good project manager would have to account for them in the risk planning of any project that used them. The business will have to be convinced that the risk is worth it, and while I would hesitate to use the word "salesmanship" [or some derivative], the project team would have to have a compelling case for chosing SOA over all the other possible architectures that may have other, *perhaps* less serious, risks.
Thanks for the interesting discussion.
@Loraine,
I hope you are not offended. I guessed at your argument from statements in your blog. If I guessed incorrectly, well… it was a guess! That said, you did pretty much reiterate most of the argument I made in your comment, so I wan’t too far off!
— N
@Edward,
If I were using SOA to access external services, then I’d be saving a boatload of money! I think I can afford the time to consider security… it is still an IT consideration.
As far as putting SOA on a web server… if you can solve the needs using a simple EXE that you don’t have to maintain, for one user to use, go for it. Do the minimum to meet the business need. (Agile).
On the other hand, if the minimum needed to meet the business need REQUIRES scalability and agility, or is part of an enterprise solution that could provide these elements to another app, finding room on a web server is the least of your worries.
If you decide to abstract the business layer into web services, you have created a client server app. Welcome to 1992. All the issues (server goes down, plug not pulled) are client server problems. SOA does not add that risk. These are red herrings.
SOA is net neutral on cost. Loraine assumes that retraining is an expense, but honestly, I’ve never spent a dime on retraining a dev team on SOA. Although I do think I will spend some money this year to cover my travel… one person in a 6,000 person IT org, four years in to a SOA rollout. That’s what… 25 cents per developer per year? Compared to a potential savings of 10-15M this year alone. Gosh… how can anyone afford that?
I live this every day. I don’t need to sell SOA to anyone on the business side. I DO need to create a consistent SOA message for IT. In a large place like Microsoft, that’s a full time job… mine.
Here’s my opinion on this much debated topic.
http://blogs.ittoolbox.com/eai/madgreek/archives/selling-soa-a-true-story-18349
I’ve been having a really fun discussion these past few days with some folks on how (or what) to sell
Lately, there seems to be more census of agreement on SOA when it comes to business and IT then I’ve seen in a long time. Thank the Lord.
SOA is a re-architechture, plain and simple. No different a set of problems then if you’d embarked on this last year or 20 years ago.
Reality is, there’s a bucket load (100’s of thousands) of older applications that are NOT going away any time soon. SOA does not fix that this for most, this side of 2015… SOA for the RICH – see my blog… Great debates.
I enjoy your thoughts SOA and how it’s related to the business side of things. As you alluded to, it is a level of trust from the business that they are dealing with professionals, and that “we” know how to solve their needs (much like we trust the accounting department). It is as simple as sell the solution.
I would like to add one more dimension to your thought. From the outside looking in (consulting world), many times you not only sell to the business, but IT as well. One underlying assumption you made was that IT believes that SOA is the right way to go. Not everyone is there yet. So that said, I think the real key is knowing when to sell SOA. Many IT folks do need to be sold on SOA. The existence of FUD (fear, uncertainty, doubt) forces many technical folks down the wrong path. They have a system that is working, but fear to look for improvements, or just do not believe they exist.
I also believe that “What SOA gives you is payoff on the next project”. I need to follow that up with I do believe that for the first time implementers, there is an upfront cost (SOA learning curve). But that is no different than the first time we created our client server app, or our n-tiered app. The cost does disappear on the next project; the difference is those did not provide the payoff on the next project.
There is not a lot of help for them (the non-SOA believers) today. The fact that “SOA is not a product or a package or a system in a box” scares people to death (alternative: believing that your IT providers can do it for you). What if there was such a thing? www.gridgistics.net believes it does exist. Now that sure does change the landscape. Something tangible that provides “good design that makes your apps (and ultimately your infrastructure) less expensive to own”.
@Darrell,
I completely agree… when you are speaking to IT, you will have to discuss SOA and, if the person you are speaking with does not understand or support the notion, then some selling is involved. From your (consulting) point of view, this is an important element.
Our own consulting services faces this problem daily. When selling to the development manager, we are good at selling tools. When selling to the CIO, we can talk about solutions. In the middle of IT management, and at the developer/tester level, we do need to have a compelling reason why the customer would consider SOA. That said, we should ‘sell SOA to IT’ only when SOA is the right answer for IT. That is not always the case. SOA is not a silver bullet.
If SOA is the right answer for the client’s IT department, and they have no one in the department who knows SOA, then I can see, from a consulting POV, that you would want to account for training expense. Recognize that I’m writing from the viewpoint of an IT department speaking to my own business.
That said, the fact that SOA is not a product or package remains a fact, regardless of whether it scares someone or not. Client Server is not a box or package either. That a vendor, any vendor, wants to sell "SOA-in-a-box" is simply typical.
Don’t fall for it. I’ve seen literally hundreds of those presentations. I have not heard of the company you mention, so I cannot comment on their message. The presentations that I have seen have all been nonsense motivated by the desire to seperate the fearful, the ignorant and the foolish from their hard-earned cash.
— Nick