My point is that the public sector — especially local gov — can go a step further. They aren’t in competition with each other so they can share the information that they put into the shared infrastructure. By also sharing information, they can look for trends, understand what’s working and not working, and jointly come up with new practices. Because this is now a collaborative effort, these practices are likely to be better than what they would do by themselves. So, they may not be best practices but perhaps we could call them “collaborative practices”.

Sharing infrastructure is a great advancement. It’s just not everything that can be done.

When using a service from a massive service provider like Yahoo/Google/Microsoft, there are significant challenges. These organizations may have the “best infrastructure”, but they do NOT have the “best service (support)”. They figured out how to scale their infrastructure to serve millions but they do have not figured out (at least yet) how to scale their service, which turns out to be more difficult, and resource intensive.
If you work with a massive service provider, things look great when everything is working, but when something goes wrong, your options are limited. There is typically no SLA, and support is minimal. It is hard to get someone to talk to and problem resolution times can be unacceptable.
Even as a small company, when we have experienced problems with email, it’s a big deal! We’re dependent on it. And as a customer, you’ve much less leverage, as the revenue from your business is a drop in the ocean for these providers.

I am also not sure that the best infrastructure is a replacement for best practices. If you use services from a best infrastructure providers, you may no longer need best practices for providing these services, but you’ll need new ones. What should be the criteria for service provider selection? How do you measure the quality of the service? How do you diagnose/locate problems? Where does the problem originate from, your network? which service provider (application, WAN)?
The challenges organizations will face when using services from different service providers in conjunction with inhouse services are significant to say the least. So we need best practices to deal with them I want to know how others deal with the problems I’m facing with, what the best way to handle them, what are the gotchas. Best practices is about learning from the experiences of others instead of repeating them.

The reality is there is no such thing as competitive advantage in ‘what we did’ because even assuming I get it – what are the chances of me replicating that. I’m not Dolly the Frigging Sheep and neither are businesses.

For most of what companies do emulating others makes a whole lot of sense. The skill of copying is very undervalued. The trick is to know when to copy and when to innovate.

Last week I listened to a major reinsurance company explain how they managed their SOX project. For the other companies in the room, this exposure to “best” practice, or “a damn good” practice has significant value. So copy it, and spend your “innovation quotient” elsewhere.

Best infrastructure is part of the story. If the infrastructure isnt upto the job,then the process is damned from the outset.

Great post. Some interesting thoughts. I like how you are abstracting it out. My additional thoughts are around the fact that software, hardware, infrastructure and services are usually what are used to build a solution to a business process, function, etc.

In a shared services or in any organization you should be looking to leverage the best solution to solve that problem. In web 2.0 that is often the service itself and you rely upon the provider to be leveraging best in class components.

I think that this is one of the reason that SaaS has some legs going into the future as today’s effort at being a best in class service leveraging the best in class components underneath without the customer paying for the mashup of these components from scratch.

Your email example is a perfect one.