What's your strategy for systems?

Another little gem from the world of Enterprise Architecture, this time I'm trying to figure out, during an Architecture Review, whether the team in front of me are on the right track...
Have we got to have a Strategy for Systems then? Well I guess if you have only one System doing Order Processing then I guess that you've already reached your nirvana as far as that functionality is concerned. The rest of us out here in the big corporations are having to cope with having 6 different Order Processing Systems, and to cap it all, none of them are "desired state".
How do we know where we are with our Systems and their functionality? Well we've put all our Applications into an Inventory like everyone else. Well you have haven't you? Then we've entered all the top Business Functions or Processes (Processes are best) and mapped those to our Applications. A nice little heat map shows where you've got trouble.
There's no doubt about it, one System doing Order Processing is a heck of a lot better than six. It's better on economy, it's better on risk and it's easier to manage, oh, and needs fewer people. There's only one state a little better, that's having two according to some people; two breeds healthy competition, and is safer for your corporation. Well go for one or two but not six.
To find out your "desired state" you're going to have to get all your users to decide on which system offers them the best deal, that is, the best functionality with the best non-functional qualities (There I've got that in again), at optimum cost.
Better here that you find one of the six Systems to base Desired state on since if you do what I've seen sooooo many corporations go and do, and built a brand-spanking new number seven system, I don't think you're getting the idea, the light at the end of the tunnels getting dimmer.
When you've got your desired state System highlighted, figure out how you're going to get onto it from where you are now. In we come with EAI tools to switch out the data flows from old to new and back to old again for reconciliation, and bit by bit we get onto the new one.
Now, don't forget to turn off the old System; make it a success factor of your new system project, that way you haven't succeeded until the old system has been completely replaced by the new system.
And please don't forget that if you aren't going to convert all the transaction history to the new system, then make sure that all the retained data is accessible and readable using common, everyday tools. You don't want to have rejuventate the old system to read the old data, since all the old system people have long since gone......
There is a school of thought that says that we shouldn't create any systems without turning off at least one old system, try pondering that one..