How to prevent doing 'wrong service' easier

A couple days ago, Steve Jones published his BLOG titled "Requirements Landfill - the challenge of central services". As usually, this is very thoughtful and forward-looking post where Steve notices that many IT prefer implementing new requirements by modifying existing centralised/shared services instead of doing this job properly and creating new business dedicated service. This is happening on the ground of "It would be easier if we just put all of this is the enterprise service". At the end, Steve asks: "have you got a decent policy to prevent requirements dumping? [into centralised services]"

I think I have. I have two major policies for this situation:

1) business ownership (co-ownership) of the business service
2) business service cost of ownership

Steve articulated significant part of the first policy: "One of the first steps in a solution therefore is to ensure that your enterprise services are clearly aligned to the business areas where they matter and thus ensure that they have an in-built desire to keep the services aligned to their area and not blurred across technical and organisational boundaries". I am going a step further and say that business has to own or share ownership with IT on each business service. This relates to the LOB/BU's business services as well as to the centralised/shared business services. This policy assumes that 'centrally provisioned IT' represents only a part of the corporate IT while the rest of IT is spread over and owned by the LOB/BU.

In this case, it would be not that simple to dump not necessary related requirement implementation into the shared services. Certainly, this model assumes that the BU that owns centralised/shared services does not support dedicated business services but serves them. This means that central BU has the same if not higher authority than specialised LOB/Bus. This is the authority and influence wrestling, which may have strong position against the service wrong doing or not that strong one (unfortunately)..

The second policy is carries an objective characteristic - the cost. I define the cost of service ownership as the sum of (parameterised representation):

a) cost of new development (CND)
b) cost of maintenance and support of new development (CMSN)
c) change of the cost of maintenance and support of existing products related to the introduction of new development (CMSE).

The rules (or policies) I follow are:

1) all new service development/modifications must be represented for the architectural review
2) all representations of the new service development/modifications must be accompanied with parameterised cost of ownership
3) if CND is less or equal than (CMSN + CMSE), it is a sign the service design and/or implementation incur some problems. The service realisation must be stopped until the problems resolved

The whole purpose of having service-oriented solution is flexibility in change adoption; if this adoption is more costly than the service itself, it is either a wrong service or it has been created with mistakes.
4) if CMSE is positive, service realisation must be stopped, the service must be re-defined and/or redesigned and its cost re-calculated.

New development may not increase complexity or cost of existing products. If this is happening, the CND has to be re-calculated because it must include related re-development of existing products.

Now, I join Steve's question: "have you got a decent policy to prevent requirements dumping?"