Consider: are there Patterns of IT Simplification?

Are there patterns to the IT Simplification Process?  I think there are.  To quote Christopher Alexander, father of the patterns movement:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.

As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

I believe that not only is it possible to describe the context of IT Simplification scenarios, that it would not be all that difficult to do. The axes of data would not be "how much do your objects vary in relation to one another," or "how do you isolate the issuing of a command from the implementation of it," but rather something more reflective of the business environment of IT: "how do the politics and relationships of the people involved play in the decision-making process."

You see, at the end of the day, the reason that some IT portfolios are not controlled has more to do with people than technology. So the patterns have to reflect the array of situations that people find themselves in.

I'll see if I can come up with a pattern language soon. I'll publish here first.