CHANNELS
 
 
 
 
 
 
 
 
ON THE WEB
 
 
 
 
PRINT EDITION
 
 
 
 
BZ MEDIA
 
 
 
 
ADVERTISER LINKS
 
 
 
 
 
 
 
AS OF 11/21/2008 4:53PM EST
Selling SOA requires big-picture view
Stories Columns Opinions Resources

By David S. Linthicum

August 1, 2008 — 

Many organizations don't really have to sell SOA. They understand that the hype is the driver, so they leverage the thousands of articles and books on the topic to sell this architectural pattern. SOA is easy to sell if everyone else seems to be doing it, and there are plenty of smart people espousing its benefits.

However, in most cases, SOA must be sold within the enterprise; it’s not a slam-dunk. Indeed, if you were doing SOA right, you'd find that the cost quickly reaches well into the millions. As a result, you'd need executive approval for that kind of jump in spending. But the benefits are there as well, including agility, which could save the company many times the cost of building a SOA. At least that's the idea.

Truth be told, technical folks are not good at selling the value of a single technology or, in this case, a grouping of technologies into the enterprise. Those people rely on the assumption that everyone sees the benefit without their having to explain it, but that is not always the case. Moreover, while the advantage often is clear, in the majority of cases it’s not. Also, there is a chance that SOA may not be a fit, and you better figure that out upfront.

So, how do you sell SOA? Let's explore a few key concepts:

»    Shining a light on existing limitations
»    Building the business case
»    Creating the execution plan
»    Delivering the goods

Shining a light on existing limitations is translated simply: Admit how bad things are. For most architects, that is difficult to do, because they expose themselves to criticism. In many instances, you're the person in charge of keeping things working correctly. The architecture within most Global 2000 companies, however, is in need of fixing. You can't change the architectures; they are too complex and ill-planned. If your architecture has issues—and they all do—now is the time to list them.

This is analogous to admitting that you're 20 pounds overweight before going on a diet, or owning up to a substance abuse problem before taking the famous 12 steps. In essence, you're defining your issues and, thus, have a clear understanding of the problem before trying to solve it.

As you list the limitations, note also the impact on the business in both lost productivity and the concomitant money wasted. That will feed into the business case.

Building the business case refers to the process of writing down numbers that attach a value of the SOA to the enterprise or business. This requires examining the existing issues (from the previous step) and putting dollar figures next to them. For instance, how much are those limitations costing the business and how does that influence the bottom line? Then, how will the addition of SOA affect the business, positively or negatively?

Attach numbers to the core values of reuse and agility. You'd find that agility is the most difficult concept to define, but it has the most value for those who are building a SOA. Then, if the ROI for the SOA is worth the money and the effort, you move forward. This tactic communicates a clear set of objectives for the effort and links the technical notion of SOA with the business.

The deliverable for this business case should be a spreadsheet of figures, a presentation for the executives and a report for anyone who could not attend those meetings. Keep in mind you’ll see this business case again, so be conservative but accurate.

Creating the execution plan refers to the detailed plan that defines what will be done, when it will be started, what resources will be used and for how long. At its core, this is a project plan, but most people would find that the systemic nature of SOA requires that a great deal of resources work together to drive toward the result. Leveraging and managing those resources is complex, as is the project management aspect of SOA.

Delivering the goods means just doing what you said you would do. Execution is where most SOA projects fall down. However, if you fail to deliver on time and on budget, chances are your SOA efforts won't continue to have credibility within the enterprise and future selling would be impossible. So, say what you'll do, and do what you say.

Selling SOA is more of an art form than a well-defined process. It requires understanding the big picture, including the technology, the business and the culture of the enterprise. More importantly, the sale needs to be followed up with delivering the value of the SOA. That's the tough part. What works so well in PowerPoint is a bit more difficult in real life.

Reach analyst David S. Linthicum at david@linthicumgroup.com.


Related Search Term(s): SOA & SaaS


Share this link: http://www.sdtimes.com/link/32549
 


 
 
 
 
 
 
 
 
 
 
SUBSCRIBE TODAY!
 E-Newsletters:
  News on Mon/Thurs.  More info
  Test & QA Report  More info
  EclipseNews  
  SPTech Report  More info
 
 
 
PDF & PRINT EDITION
* Requires Resource Account!  LOGIN or SIGN UP

Download Current Issue!
ISSUE 11/15/2008 PDF

Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE
 
REGISTER
 
GET NOTIFIED!
About all of the latest Resources
 
 
SD TIMES 100
It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.