Carrot and Stick

Motivating Reuse

From a software perspective, one of the possible benefits of SOA is reuse.

The notion of "reuse" is inherited from previous waves of software technology: module, object, component. Over the years, we have been told many times of the substantial economic benefits to be gained from reuse (greater development productivity, substantially reduced cost, faster delivery, and so on).

And when the actual scale of reuse turns out much lower than the apparent potential, we are given a range of explanations (excuses). Perhaps that technology wasn't quite powerful enough, but this new technology will release floods of reuse. Perhaps the technology was fine, but the people weren't properly trained or managed. And perhaps this additional technology will force the people to deliver reuse.

If we want people to do things differently, we have to consider the three Es.

Enabling	Do the people have what they need to do things differently? Skills, resources, tools, infrastructure, support?	For example, if the technology supporting a different way of working is clumsy and immature, it may be impossible to adopt this way of working without compromising speed or quality.
Encouraging	Do the people (and their managers and supervisors) have a reason to do things differently? Motivation, reward (or sanction),	For example, if a project manager's status depends on having a large project team, this conflicts with any incentive to improve productivity.
Empowering	Do the people have the power to do things differently?	For example, if people are forced to work on narrow, short-term projects, under strong design constraints, they may not have the opportunity to produce reusable artefacts.

According to Jon Udell, Verizon paid particular attention to questions of motivation in implementing its IT Workbench.

Stick	Project funding is contingent on the contribution of sharable services to the repository.
Carrot	Developers required to use the repository -- like all employees required to use centralized corporate services -- are effectively paying a tax. And like all taxpayers, they want to see their tax dollars put to good use. Verizon says that its IT Workbench rewards developers by wrapping useful capabilities -- auditing, debug tracing, security -- around the services they develop.

source: SOA heroes

Udell also refers to the public recognition and praise accorded to those developers who adopt the desired practices, and quotes Blue Titan's Frank Martinez "Make them heroes". However, I have a slight qualm about this, to the extent that reliance on heroes is a sign of an immature software practice.

Motivating Sharing

But I no longer think that reuse is quite the right concept for SOA. It raises all sorts of technical issues about deployment and instantiation of a service, which are not directly related to the grand economic benefits of software reuse. People are starting to talk more about sharing services rather than reusing software.

Many of the enabling / encouraging / empowering questions are still valid. Of course we must look at the transaction costs of sharing, including both the costs to the individual (effort, learning, moving outside comfort zone) and the costs to the organization (trust, complexity). Sharing potentially exposes us to additional interoperability risks, which need to be properly understood and managed.

The main advantage of sharing over reuse is that it is much more meaningful to the business. Software reuse is fine as an abstract idea; but sharing services has much more concrete implications for business users, whose support can be mobilized to help encourage and empower SOA developers.

Technorati Tags: interoperability reuse SOA service-oriented