Centralized Services in Software Development

Reading a blog post by Tripp Babbitt reminded me of Ackoffs discussion on internal market economies in Re-Creating the Corporation.

Babbitt’s blog post talks about how focusing on cost reductions often increases costs. One reason is that cost reductions are often approached by centralizing services in organizations. When this happens, a feedback loop is broken. Those who produce the services are no longer those who consume them. This means that they loose their understanding of how well the services work. When the consumer of the service sees the service degrade, they cannot easily improve the service, because they don’t control the production of it. Instead, the consumers work with what they can control, which sometimes means reproducing the service locally, thus increasing total costs.

How can we use this insight to improve software development?

In software development, we sometimes see this phenomenon with centralized platform teams. A platform team is formed to develop shared functionality, to be used by teams that develop actual product features. In reality however, platform teams often have a hard time living up to the expectations of the feature teams. Because of this, feature teams sometimes choose to locally develop functionality that was supposed to go in the shared platform.

Another example that comes to mind is when organizations set up project management offices, and these offices proceed by pushing out standardized methods of work, instead of listening to the needs of the different areas of the corporation. Again, the idea here is to save money by standardizing, but the result is often frustration, because there is no such thing as a one-size-fits-all way to manage projects.

One final example: the central database administration group. Created to gain control over database services, it soon becomes the bottleneck more than anything else, stopping projects dead in their tracks.

In Ackoff’s solution, departments within organizations should be free to procure the services they need from internal services and from anyone on the open market. If top management wants to override a department’s decision to procure externally they can do so, but will have to use their own budget to compensate for the losses the buying department suffers through this decision.

In other words, if a sales department is forced to procure their new IT support system from the internal IT department, even though they could have gotten the same solution for a cheaper price from an external provider, the overriding manager will have to compensate the sales department for the difference in cost.

Well, this is really a bit outside of my area of expertise, but interesting nonetheless. My learning goes on.

What are your experiences of centralized services? Good? Bad? Why?

Published by Tobias Fors

I'm a software management consultant. I help other people succeed with software development. In my work, I help teams and organizations be more effective and ship software.