Learning to love software reuse

Let's face it: developers love reinventing the wheel. Anyone who believes someone else has built as good a wheel as they could build themselves isn't worthy to call themselves a geek.

Object-oriented development and component-based developmentThe second obstacle is developer jealousy have both failed to realize the promises of software reuse because they let developers touch the code. What self-respecting geek is going to leave well alone?

Only when you move to a truly loosely coupled services architecture do you get to reuse software without the temptation of making changes. Properly implemented, a services architecture doesn't allow you to look inside the service and see how it works. You only get to reuse the service just as it is.

Well, that's the theory, anyway. In practice, you come up against all sort of obstacles. The other day I finally got around to reading an article about Verizon's service-oriented architecture. It perfectly illustrates the two main obstacles. The first is trust. here's what Shadman Zafar, Verizon's SVP of architecture and e-services, told InfoWorld's Leon Erlanger:

"There was a lot of resistance to using the services because of the lack of standards around four essential operational pieces: SLAs, accounting, billing, and capacity management. People weren't willing to entrust their mission-critical applications to each other."

The second obstacle is simple jealousy, with developers unwilling to expose the fruits of their efforts. Verizon has turned that around with a searchable directory that positively rewards service reuse:

According to Zafar, developers are now competing to get others to use their services, as a way of gaining recognition within the company.The most-used services are listed on the IT Workbench portal with the author's name and photo. "Before, people would say, 'This is my code, use your own,' " Zafar says. "Now they're reaching out to each other over the weekends, saying, 'Why don't you use this service I built,' so they can be more popular ..."

Verizon's experience shows that successfully encouraging service reuse in an SOA means creating an environment that's very similar to an on-demand applications marketplace. Services need to have credible contracts attached to them so that people can use them with confidence, and they need to be marketed to potential consumers. And as I described in a posting to my Loosely Coupled blog this week (already picked up by ZDNet's resident SOA blogger Joe McKendrick), people who've been exploring the best way to store and share services in an SOA have ended up implementing services registries and repositories that have exactly the same attributes as an on-demand catalog like Salesforce.com's newly launched AppExchange. Which kind of suggests that on-demand and SOA are but two sides of the same coin.