Hard as it is to believe, some managers don't give a hoot about SOA

Go to any conference or read any white paper or any blog (including yours truly), and the message is clear: you need business buy-in to make SOA work. But suppose your management doesn't care or is oblivious, or just doesn't give a (fill in expletive) about SOA?  (I'm sure it happens occassionally here or there...)

Don't just hope for best practices -- act and measure

(Remember my theorem: those companies that could use SOA principles the most are the least likely to be implementing or supporting SOA.)

Loraine Lawson recently spoke to Dan Diephouse, chief software architect on the Mule Galaxy SOA governance platform and creator of Xfire, an open source SOAP framework, about this very issue.

Diephouse said that one of the mistakes SOA proponents make is "hoping for best practices," meaning an initiative is set into motion (or at least verbalized), but then managers don't check back or measure what took place. "Then they wonder why a year later, they didn’t manage to do this. Why didn’t this magically happen? Well, you didn’t really check and encourage people to do that and set some benchmark points along the way." It's not enough to set goals; it's important to put policies and metrics around SOA activities.

This measurement should also extend to the reuse of SOA-enabled services, he says.

So what happens if you are in an organization that doesn't support -- or even care -- about such efforts? Where your management may be say, less-than-forward thinking? Diephouse says many of these processes can be launched by SOA proponents under the radar, to help build such an effort from the ground up:

"You may not get the cross-project or cross-organizational funding that you’re looking for but you can still think about, okay, how can I enable reuse of this service? Maybe there are ways I can actually bring in another group. Even though there isn’t some top-down vision, I can say let’s collaborate on this and figure out funding. Let’s start thinking about how we can share schemas and gather requirements from other consumers. Let’s think about what the QA process of our service is going to be. What our end-to-end process is going to be from build to deployment to run time."

SOA often ends up being an initiative that springs from the network, versus any command-and-control scenario. As Diephouse also says, collaboration between groups is key.

"If you have six people or six services that use different schemas for the purchase order, you end up with this problem where you need to translate in between all of them and it’s a giant maintainability hassle. I think it is very important for people to come together and collaborate and say, 'Okay, who else is doing this type of thing? Can we share our requirements and come up with a shared definition for what a purchase order is across our organization?' The same thing at the service level - you don’t want to have all these different service definitions. You want to have a shared contract that is as universal as possible because it’s going to reduce maintenance for you. You aren’t going to have to maintain all of these different versions. You aren’t going to have to maintain all of these different services. You’re going to be able to create some shared funding and come up with a common service for everybody."

I have a feeling that the issues and approaches Diephouse talks about are very widespread, and probably more pervasive than enlightened enterprises that encourage and have embedded enterprise-wide innovation into their cultures. We've talked frequently at this blogsite about Guerilla SOA, making it work at the grassroots level and percolate upward. Ultimately, the end result of these efforts is to fuse them into a more holistic process, Diephouse points out. In some companies, executives may not be helping out that much, but teams can still collaborate to work these things through.