In response to our post “What to expect” our former cohort Chris from the old days at a giant semiconductor company posed the question:
“Any thoughts on communicating just exactly what SOA is to mixed audience of technical and non-technical folks, and how it will help them?”
Yes Chris, yes we do have quite a bit to say on the subject. In a previous post we talked about SOA being a means to a end which implies that SOA is an architectural response to a bigger need or problem. The worst thing you can do as an architect is to attempt to sell SOA as SOA. The equivalent mistake would be to try to sell Model/View/Controller (MVC) or Event-Driven architecture (EDA) to a business analyst or end-user. Either they will not get it or they will not care or both.
A better approach is to present the problem at hand, describe how the problem can be solved in conceptual terms, and then and only then illustrate how SOA (assuming it does) provides the design to solve the problem.
Having said that, this is part 1 of 4 posts on how to explain SOA to an organization.
The short answer to how to explain SOA to business folks is to NOT explain SOA to business folks. Here are an analogy that hopefully makes the point. When you go to the dentist to get a painful tooth fixed, do you want to hear how he/she is going to drill a hole in your head? Or how this wonder epoxy is much better than mercury? Well I do, but that is just me. Generally speaking though, you do not want to hear the details, rather you want your problem solved and as a bonus how fixing that tooth allows for more dessert consumption. The same thing is true for the business side of the house. They want you to solve their problems, not tell you how you intend on using a SOAP envelope to carry information in support of content-based routing. We can distill two nuggets here:
- Never sell SOA to the business outside the context of a business problem that needs solving.
- If you have to do some selling of SOA in a business problem slide deck, the slide deck should be 90% business problem and 10% SOA. Less than 10% is better than more.
Rightfully so, business problems articulated by business people are in business speak. Furthermore, the problem is, more often than not, in the form of a solution. If I, as a business analyst, said that my problem is: I need to receive a phone call from the orders department whenever a left handed blue widget is sold, what would you do as a seasoned IT professional? Hopefully you would not offer a solution to have a direct phone line established between orders and my desk, would you? I am not going to bore you with a primer on analysis and design, but rest assured when probed further the real problem will come out. So ask me, why do I need to know when a left-handed blue widget is sold. Well I need to know because we do not keep inventory of left-handed widgets. Left-handed widgets are only stocked at our main warehouse and have to be shipped to our warehouse, then onto the customer. Consequently, I need to get a call from the Orders department so I can call the main warehouse to ship ASAP.
Are you smelling what I am cooking here? The problem has little to do with phone lines and the biz person in particular. A relatively simple answer would be to publish an event that a left-handed widget was sold such that me (the biz person) and the main warehouse get the event in near real-time. Widget gets shipped the same day and I am out of a job. More nuggets:
- Boil the problem down to its primitive parts, rarely will the problem be presented in a workable form. More likely, it will be presented as a half-baked solution.
- (Bonus Nugget) Never propose a solution that explicitly calls out staff reduction as a feature, let upper management figure that out on their own.
Moving on…Because you are a smart architect you go in search of similar problems that fit this pattern:
- Event Happen
- Event detected (Human intervention with latency)
- Event Received (Human intervention with latency)
- Re-Raise Event (Human intervention with latency)
- Event Received (Human intervention with latency)
- Event Processed (Human intervention with latency)
- Event Closed
So what is the problem? Fragile system riddled with human intervention and unnecessary latency. Aka “Human Glue”. If you are in a business of any size you will find instances of this pattern under every rock in the building. So what? Well once you have a problematic pattern with many representative instances you have something the business will understand, if presented in non technical terms. Notice I have not said SOA yet? Not even the ESB word! Here come some more nuggets:
- Boil the root problem down into a pattern that can be explained in simple terms.
- Find more examples of this problem pattern in the enterprise.
Without leading the witness too much, let’s say you have done your homework and came to the conclusion that a relatively primitive event-driven architecture can streamline this pattern through the use of a pub-sub pattern. That is:
- Event Happens
- Event detected (Automated)
- Event Received (Automated and simultaneously for as many receivers as necessary)
- Event Processed (Human intervention)
- Event Closed
This is all great, the business will love you because you found a solution pattern that can be reused over and over again for many different business cases. However, there is one problem, the Orders system is Microsoft .NET and the Fullfillment system is Java so they don’t speak to one another. Again you are smarter than the average bear and you propose implementing service facades on top of the middle tiers for the Orders and Fulfillment system such that each system will have an interoperable, standards-based interface from which messages can be sent/received. Finally, you recommend an intermediary of some sort to abstract services from one another and to thwart point to point communication. There you go, slap together a slide deck that extoles the virtues of SOA and you are a hero, right? Wrong!
Here is where propeller-heads like us go wrong. The slide deck should take the business through your thinking process good and bad. The first slide should present the problem as stated. Take the business through your distillation process, the underlying pattern in very simple terms. Show how the pattern repeats itself over and over again in the enterprise. Describe how the current architecture prevents disparate systems from communicating with one another but, for God’s sake, do it in one slide. Show them the pattern that solves their problem, and then and only then, give them a slide or two on SOA and/or message-based architectures.
As you are getting a standing ovation in your presentation, drop the hint that SOA is “A means to a end” for some other patterns that occur in a business such as theirs and you would be glad to develop a slide deck to present to the business and selected IT managers if they would so please.
The moral of the story here is the business doesn’t give a rip about SOA, never have, never will. You, the smart architect that you are, has to walk the business folks down the path that takes them from the problem as stated to the problem pattern, to a solution pattern, to the solution that solves the problem regardless of the technology at hand.
This is in contrast with how you sell SOA to developers, network administrators, DBAs and the like. More on these topics in future posts.
Does that help?
Print This Post
Tags: Enterprise Architecture, Service Oriented Architecture
Very insightful Bill, as usual. I’d like to say that I don’t need to pitch anything to the business in my case. However, given my failure to launch an SOA effort, that may well have been one of the factors that led to the eventual non-start.
I really like the idea of a presentation that walks people through the decision process rather than jumping to the conclusion and explaining why it’s the only way to go. I think that would be effective.