If you're having trouble writing the first paragraph of your business case for implementing service-oriented architecture...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
(SOA) in your organization, maybe it's time to try a new approach.
"If the executive summary is hard to write, then the relationship of the proposal to the current situation or the benefits of the project may not be clear," writes Lewis Cardin, analyst for Forrester Research Inc., author of a guide to writing an IT business case. Starting with a clearly written executive summary, he covered the basics elements required in his report, "The Components of a Quality Business Case: Don't Let Your Business Cases Tell Only Part Of The Story."
While that report covers a general IT business case, in an interview with SearchWebServices.com, Cardin said there are specifics that need to be thought through before starting work on a business case for SOA. The first specific is to communicate what SOA means to the business, keeping in mind that at least some of the business case readers may know little if anything about SOA.
"Although SOA is a widely accepted practice and creates significant value," Cardin said, "in terms of an executive summary it can be a difficult thing to articulate. An executive summary is so important because the value of SOA needs to be clearly understood, not only in terms of people who are familiar with SOA, but also business folks who may not have a clear idea of what SOA is and what it does."
Other analysts interviewed for this article also stressed keeping a business focus in the SOA business case.
"First, the best way to sell SOA is not to call it SOA," says analyst Joe McKendrick of Evans Data Corp., expressing the consensus among the analysts interviewed for this article. "A good business case is no different than a sales proposal pitched to a prospective client company," McKendrick said. "And the nature of the game is that all a client wants to know is 'What's in it for me?' More specifically, they want to know, 'Can you help me increase revenues for this product line?' 'Can you take away my pain point in this area of the business?' No one is going to ask you, 'Can you set up an SOA for us?'"
Jason Bloomberg, senior analyst with ZapThink LLC., said the need to focus on business problems more than SOA specifics make the SOA business case something of a paradox.
"The most important thing to keep in mind about a SOA business case is paradoxically that it might not look like an 'SOA' business case at all," Bloomberg said. "It must have a clear description of one or more specific business problems, along with the proposed solutions to those problems, along with their costs and risks -- just like any business case."
While three-letter acronyms surrounding SOA may be constantly on the lips of architects and developers, several analysts interviewed for this article said they would avoid putting technology up front in the business case.
"The proposed solutions leverage SOA best practices, but depending upon the problems being addressed and the audience," Bloomberg said, "they may not be identified as SOA. It's often a better idea to identify them with the problem space. 'Customer satisfaction business case' or 'integration cost reduction business case' will go over in the boardroom much better than 'SOA business case.'" Bradley F. Shimmin, principal analyst of application infrastructure at Current Analysis LLC, also advises staying away from SOA and the related acronyms as much as possible.
"If I'm writing a business case, the first thing I want to understand is my environment and what's wrong with my environment, and what fixing it is going to do to make my environment better," Shimmin said. "I would never even mention SOA. I would build my business case without SOA. I'd build it simply as a business case for the IT infrastructure that will either make us money or save us money. I wouldn't make a business case that listed thousands of acronyms, ESBs, WSDLs and things like that."
Shimmin said such tech talk will not appeal to the business people who read the business case and will have a say in whether any project moves forward.
Offering an example of that business focus, he said, "What's going to appeal to business people is it takes us four days to provision a new supply chain partner and we can bring that down to 30 minutes. To do that I need x amount of money and it's going to take x amount of time."
The money issues can be tricky, and McKendrick points out that on the issue of return on investment (ROI), the business case writer can be flexible.
"Of course, the first thing that comes to mind when planning a business case is ROI, those often-elusive numbers that form the core of any business case," he said. "But estimating ROI for an SOA effort beyond what you'll get in terms of IT department productivity is still an inexact science. But, at the same time, ROI calculations don't have to be an exact science either. I recently heard Ed Kourany of BEA put it this way: 'It's important to be able to calculate a return on investment on SOA, but you don't need to provide exact numbers down to the penny.' In most cases, a just-good-enough estimate of potential ROI will do the trick."
On the issue of technical details, while a lengthy discussion of architecture might cause the average business reader to drift off, there is a place for architecture, Shimmin suggests. After making the basic business case, he advises telling the reader that they will be provided with a detailed architecture document that will then show the elements of SOA that will be implemented.
An important thing to keep in mind is that SOA is not a product as a business process management (BPM) suite might be, so a business case for buying a BPM product from a vendor would stress BPM. But Shimmin said, the days when people could say they were going to do SOA and get funded are over, and the business benefits have to be the focus.
McKendrick also noted that SOA is not a one size fits all kind of sell and the business case needs to reflect that.
"Every organization has its own unique pain points," McKendrick said. "An organization may have recurrent bottlenecks in its supply chain, for example. Or may need to decrease the number of days in its product development cycle. A good proposal should tackle these points, one project at a time."
Different business problems also require different SOA approaches, concludes Bloomberg.
"Two SOA business cases for two organizations may recommend very different approaches," Bloomberg said. "It's important to keep in mind that SOA represents a rather loosely defined collection of best practices and it's up to the architect to know which ones are appropriate for which situation, a clear case of the right tool for the job."