The Economics of SOA
No, this isn’t another post on ROI, but rather, a comment to Jeff Schneider’s post on Supply and Demand Side SOA. Jeff states:
Most of the companies that I’ve consulted to start with a ‘supply side SOA strategy’. That is, they create a strategy to create a supply of services. As everyone in the manufacturing world knows, creating supply without demand is a really bad thing…Most manufacturing companies have moved to some variation of just-in-time production. They wait for customer demand before they build the products. You’d think that this would work for SOA but in many companies it isn’t. The reason is simple. These companies do not have a demand-side generator (the sales and marketing engines). Demand-side SOA is a discipline that doesn’t exist in many corporations.
Jeff is absolutely right on here, on several fronts. First off, I’m sure no one would argue that many companies simply start by creating services. Odds are that these services are specific to the project that thought them up, but even if they weren’t, what prevents them from being used by projects down the road? Is it because the developers wrote lousy code? Probably not. The most likely cause is poor communications. Jeff’s demand-side generator is defined as sales and marketing. In other words, getting the word out about what is available! The current registry-based approach for publicizing services is akin to phone book marketing. Do you pick the provider who only lists a phone number, or do you pick the provider with the full page advertisement including hours of operation, customer service philosophies, and the owner’s name? Odds are, that’s not the only place you’ve seen them, either.
The need for sales and marketing efforts is especially important where natural barriers exist to communication. If your IT department is spread out across multiple states and even countries due to mergers and acquisitions, getting the word out about the services that are available is not easy. Even within a highly centralized group, there can still be barriers between the infrastructure teams and the application teams. If the infrastructure teams have provided an excellent mapping and transformation service, they need to create the demand from the application teams by getting out and marketing the service to them. If they don’t know about it, they won’t use it. Furthermore, communications is never one way. Odds are, by communicated about services that are available, opportunities for other services will be unearthed. Get out there and start creating demand for your services.
So, I’m thinking (as Patty Seybold would advise) that “service customers” would be great marketers. Think about the community led “get firefox” campaign. Repositories (or whatever you renamed them) need to include social networking features (ratings, testimonials, tagging) to encourage (or if warranted) discourage service use. I’m thinking grassroots, word of mouth marketing, would be best. [While I’d like to take credit for the social networking and repository tie, I believe it was a (to be published) paper of Annie Shum’s that made that connection for me.]
And now, I must go write something for my own blogs! -brenda
For the record, I agree with you Brenda. The challenge is that social networking features work very well in general society, but are far more difficult in corporate cultures. In the case of service adoption, there are case studies on companies like Verizon that show that it can be done. I’m sureFlashline BEA has numerous others, as their product is based around this community concept. I’d love to be a fly on the wall in those companies, however, and see how the adoption really has gone. Regardless of how rough the road was, I’m still a proponent. I think open communications handled in a mature, constructive manner can only improve things, even if it means a few bumps and bruises along the way.