PurchasingStrategy

A short article in the in-flight magazine on the plane from Argentina to Brazil suggested that improving a company's purchasing strategy could lead to large savings. However, such a strategy couldn't be left to the purchasing department alone, but needed co-ordinated support throughout the organization. The solution, centralize the responsibility for purchasing strategy in a central department.

I suppose every time you need a strategy which covers a number of departments, you remove responsibility from those departments into a separate strategy control centre. Much like using the strategy DesignPattern as a way of re-using code between objects.

How far can this go? Every time you need responsibilities which cut across modules, you pull them out into new modules, but does this create more modules for further cutting across? This is the classic problem of going from ConcreteToAbstract. Does it lead to too many modules? AspectOrientation really needs ReWriting to weave multiple functionality between modules. Is this better than a strategy pattern. When is each appropriate? And can we imagine a similar re-writing in the context of companies? ( RefactoringTheOrganization ?)

Contrast SubsumptionArchitecture

See also SystemsThinking

Note that the article also suggests you need to decentralize "orders to internal users". What does this mean exactly?