Eight ways to get developers on board with SOA governance

Does ramming SOA down the development organization help the cause of service orientation? Of course not. But, in a recent article, Robert Schneider observes that many companies have taken this tact, attempting to coax developers to adopt SOA practices with little or no input, guidance, or training.

Too many organizations, Schneider says, attempt to take "shortcuts" to SOA, and in the process, shortchange governance, which would help get developers on board with the effort. Plus, many developers are bogged down with routine maintenance tasks -- which still occupy a lion's share of time. (Though SOA can help cut down maintenance costs and make more funds available for business-growth projects.)

Efforts to force SOA on developers -- the top-down approach -- without their active input into the design-time aspects result in frustration and cynicism, Schneider says.

Developer disenchantment, of course, cuts into the benefits we want to see from SOA, such as increased ROI on software investments, augmented organizational agility, and diminished IT maintenance burdens. And as discussed frequently here at this blogsite, service-oriented methodologies can help organizations navigate through today's rough-and-tumble economy, and be well positioned to grow as things pick up. (And they will pick up... there are green shoots already forming...)

Of course, as companies miss the SOA boat, the finger-pointing starts -- and guess who gets the blame? As Schneider puts it: "far too many enterprises attribute any SOA disappointments as being exclusively caused by recalcitrant developers sabotaging well-intentioned governance efforts." The real blame, Schneider says, should be pinned on management, and a failure to actively involve developers in the governance process. (Or a failure to even have a governance process, period.)

Schneider makes some recommendations to bringing developers into the SOA process:

1. Don't compensate on the basis of volume. "Recognize that number of lines of code written isn't a valid productivity metric anymore."
2. Compensate for working smarter. "Reward developers for reusing others' work."
3. There are times when new code is needed, and recognize that. "Also reward developers for writing reusable services when no applicable services exist."
4. But don't let people go too far with rewarding reusable service creation. "Penalize developers who unnecessarily create new services (or otherwise violate governance standards)."
5. "But don't punish developers for the overhead (and inevitable schedule impacts) mandated by adherence to solid SOA design and governance methodologies."
6. Make runtime governance consistent across all teams -- even consultants or outsourced development teams.
7. "Recognize the need for new skill-sets (e.g. service and policy custodians, technical communications specialists, etc.) in support of SOA and related governance."
8. Educate development managers in cross-departmental support requirements.